-
Key: EXPRESS11-13
-
Legacy Issue Number: 19074
-
Status: closed
-
Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
-
Summary:
MOF/XMI (and the Eclipse EMF implementation) requires that every model element have a containment trace up to a root (model) object. In the EXPRESS metamodel, Anonymous Types, Generalized Types, and Expressions have no such trace. (There may be others.) It appears that the intent is to allow these objects to be shared, rather than to treat each occurrence as unique. With respect to the Anonymous and Generalized Types, the sharing is consistent with EXPRESS requirements for recognizing these types as the same, or as specializations of one another. The problem is then that there is a need for these objects to have a container that is consistent with the scope of their common interpretation. Expressions (which could be unique) have such a feature; it should be the container. The un-Named Type objects also need one.
-
Reported: EXPRESS 1.0 — Thu, 7 Nov 2013 05:00 GMT
-
Disposition: Resolved — EXPRESS 1.1
-
Disposition Summary:
It is not possible in general to have Attributes and Parameters “contain” their types, because the containers for NamedTypes are their namespaces. So AnonymousTypes and GeneralizedTypes need some other container. Since such types may have members whose interpretation is defined within a Scope, it is appropriate that the same Scope apply to these types.
Expressions have a required property (interpretation-context) that is the appropriate container. The association, however must be made bi-directional and composite.
The separate container associations are introduced here, and the expression-has-context association is modified in the MOF model.
Remark.appears-in should be a containment, but is not so marked. This is also corrected.
PartialEntityType also has no container. Its container should be an EntityType. A composite relationship for this is added.
Finally, Attribute is shown as having two containers: .of-entity and (the inherited) .namespace. Only the latter should be the container; the inverse of the former (SingleEntityType.declares) should be derived from it, and there is no longer a reason for it to be a bi-directional association. This has a minor impact on implementations because these associations already exist, but the composition structure is modified. -
Updated: Mon, 9 Mar 2015 14:34 GMT
EXPRESS11 — Constructs that have no containers
- Key: EXPRESS11-13
- OMG Task Force: EXPRESS Metamodel 1.1 RTF