MOF24 — Because MOF merges UML, UML as an instance of MOF is ill-formed

In MOF 2.4, Reflection::Element merges UML::Element. Then it is stated that Reflection::Element is an implicit superclass of all metaclasses defined using MOF. Hence UML::Element is a subclass of Reflection::Element which merges UML::Element. Reflection::Element has all of the properties of UML::Element (e.g. ownedComment) and so UML::Element may not validly have these properties.

The solution is for MOF not to merge any part of UML, because there is no need to do so. MOF should simply refer to UML for its definitions.

The fact that MOF merges UML is actually correct, and requires no changes. The
important “fine print” detail is that PackageMerge is not inheritance. With
PackageMerge, matching elements in the mergingPackage and the
receivingPackage are merged into a single element without changing the position of
that resulting element in the type hierarchy. This means in case of UML::Element
versus Reflection::Element that UML::Element is augmented with the reflective
capabilities defined in Reflection::Element without changing its position in the type
hierarchy of the UML metamodel. In particular, UML::Element is not a subclass of
Reflection::Element. If seen in the context of MOF, it remains unchanged the
superclass of all UML metaclasses, but augmented with the MOF capabilities.
Since version 2.4, MOF is based on a constrained-down UML metamodel. The only
way to add the additional capabilities of MOF without altering the type hierarchy is
PackageMerge, therefore MOF needs to merge UML.
To provide absolute clarity, the clause describing the Package composition of MOF
shall be improved.