The Theory of Marking Models

Today, there's no "theory" of marking models that states exactly what should go into a marking model or how to create one. Indeed, it's not completely cut-and-dried what should be thought of as a mapping, a mark, or a mapping function.

None of this should be a surprise. When we build a program, there are many ways of defining the same behavior, depending on exactly what the developer chooses to parameterize. The same situation obtains here, with the added entertainment that there are several ways to implement marks, marking models, and mapping functions.

As you can see, marks cover a multitude of sins. There is not yet a taxonomy of marks from which we can derive all kinds of marks and know that we are complete. This is as it should be: It's still early in the evolution of MDA. As experience in fully model-driven development grows, the complete range of marks will become clearer, and approaches for when and how to use them (and when and how not to use them) will drive us to the next level of understanding and standards. In the meantime, we've described some common or garden varieties.

MDA is utterly relaxed about how marks and marking models will be used, but a good long-term strategy involves making the marks as free of potential implementations as possible. In other words, it's better to describe the instance count for a class, say, than to demand a specific implementation.