For XMI exchange of an EXPRESS model using the EXPRESS Metamodel, the master container, equivalent to UML:model is a Schema. But Schema has no URI attribute to label the model as a resource. ISO 10303-11 suggests that the ‘version’ attribute be used to carry an ASN.1 identifier for the Schema, but says nothing about URIs. It may be appropriate to use ‘version’ to contain the URI, but it is not clear that MOF supports that interpretation.

Add an optional URI attribute to Schema.

The EXPRESS concept ‘specialization’ can relate many different kinds of types per ISO 10303-11 clause 9.2.7. In particular, it extends to AnonymousTypes, GeneralizedTypes, EntityTypes, and SelectTypes. Except for a handful of explicit relationships among SimpleTypes, it is nominally a derived property that is used when it relates to the validity of expressions, actual parameters, actual types, etc. The ‘specializes’ attribute of AnonymousType is too general for the explicit relationships, and too narrow for the general concept in the ISO clause. If it is the intent to capture the specialization relationship between types per the ISO clause where needed, the ‘specializes’ attribute should be an attribute of ParameterType (the supertype of AnonymousType that covers all the EXPRESS cases).

It is not clear that the property is used at all, except for the instance diagrams in clause 8.17. But the generalization to ParameterType will not affect any existing uses, and it is optional. ‘specializes’ will be generalized to ParameterType specializes ParameterType.

AnonymousTypes, GeneralizedTypes and Expressions are not “contained in” any EXPRESS Scope element (or any other element).

This makes it impossible for them to be conveyed in any EXPRESS XMI file. This is a particularly serious problem for AggregationTypes, which are the data types of many attributes and are rarely named. (This problem has been fixed in implementations, but it should be fixed in the specification.)

Note: The problem was discovered in resolving Issue 18815, but it should be addressed clearly and separately.

This is effectively a duplicate of Issue 19074, and is resolved by the resolution to Issue 19074.
Revised Text:
See Issue 19074.

Disposition: Duplicate (of Issue 19074)

The metamodel defines a number of high-level common properties that are (or should be) constrained to subclass-subclass relationships in practice. Unfortunately many of these relationships are described as ‘subsets’ of the properties, while the EXPRESS specification is clear that they are constraints and therefore should be redefinitions. (Alternatively, some the high-level relationships could just be derived unions.)

The RTF agrees that almost all of the ‘subsets’ relationships to namespace or ‘of-type’ should be ‘redefines’. Similarly, the redefinitions of Expression.evaluation should be properly modeled by ‘redefines’.
The namespace relationships are repaired in the resolution to Issue 19031. The remaining ones – Instance ‘of-type’ and typed Expressions – are corrected here. The relationship between the IndeterminateRef expression and the Indeterminate Instance class is added.
These changes have no real affect on implementations, but they improve automatically generated code.

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.

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.

The model of Relationships in clause 8.12 requires the explicit construction of a RangeRole object when the ExplicitAttribute is created, and the creation of a DomainRole object and a Relationship object when an INVERSE attribute is created (and possibly when a UsedIn construct requires them). As modeled, the association from ExplicitAttribute to Relationship is 1-to-many, and it is derived from ExplicitAttribute.RangeRole.in-relationship. But both of those associations are 1-to-1. So it is not clear how a 1-to-many association can be derived from them. On the Inverse side, the InverseAttribute creates a unique DomainRole and a unique Relationship. There is one Relationship per InverseAttribute. So, either the same RangeRole must participate in all of the Relationships, or the ExplicitAttribute relates to one RangeRole per Relationship.

Also, for Eclipse EMF purposes, it would be good if one of the associations to each Role is composite.

EXPRESS allows a subtype of the range of an ExplicitAttribute to declare an InverseAttribute whose range is subtype of the EntityType that declares the ExplicitAttribute. Consequently, an ExplicitAttribute can correspond to several technically different Relationships, each of which specifies a specific domain and range. The model in clause 8.12 must be revised to reflect this, while correcting the noted error.
As a consequence, the relationship between a Role and the EntityType that plays it is not derived (contradicting the v1.0 model) – it is part of the definition of the specific modeled Relationship, and the derivation of the inverse relationships involves filtering functions. Conversely, the relationship between the ExplicitAttribute and the RangeRoles it defines is derivable from the Relationships it creates (1-to-1).
Given this structure of multiple Relationship objects, each Relationship object is the appropriate container for its Roles.
This change affects implementations. It properly enables the capture of all allowable EXPRESS language constructs. Existing implementations either ignore Relationships, or assume that they are 1-to-1 with ExplicitAttributes (which is probably the case for most published EXPRESS models).
Issue 13870 revises the text to move the Relationships associations from InvertibleAttribute to ExplicitAttribute, and the necessary changes overlap. The changes associated with Issue 19061are therefore merged with the changes in Issue 13870.
Revised Text:
see Issue 13870

Disposition: Merged

In clause 8.14, diagram 8.15, ParametricElement is shown as being contained in two composite associations – the inherited NamedElement.namespace and ParametricElement.source. Further the possible actual Classes that can be ElementSources are not Scopes, so the .source relationship cannot be a redefinition of NamedElement.namespace. ElementSource.type-parameters should not be a composite relationship. In EXPRESS terms, the Scope of the ParametricElement tag is the Scope of the ElementSource, and not the ElementSource itself; the ElementSource is just the definition point. The derived relationship .namespace in the diagram really is the containment relationship.

The relationship to ElementSource is erroneously shown as composite. The diagram will be corrected, and the text is clarified.

It is not possible in most implementations to specify the object-identifier for an object. In clause 10.2, Figure 10.1, “INDETERMINATE” is used as the object-identifier for an Object/Instance that has no distinguishing properties. The only modeled property of the Indeterminate metaclass (inherited from Instance) is the type(s) that the object instantiates. Clause 10.2.7 says the EXPRESS INDETERMINATE instance is not an instance of any type, but it can be treated as an instance of the required data type of the Expression, if any. That is the semantic rule, but it cannot possibly work in an implementation if the INDETERMINATE value is unique: It assumes that each use of it is a different Instance with different values for ‘of-type’. It must be a requirement that the ‘of-type’ property is always empty. In that way, the INDETERMINATE object can be identified as such. And, using MOF reflection, it is the only object that identifies its Class as “Indeterminate”.

The INDETERMINATE value is deleted by the resolution to Issue 18815, precisely because it has no modeled properties. It should be a property of the Indeterminate class that SELF.of-type is always empty.
At the same time, the existing ‘is-singleton’ constraint should be rephrased in MOF terms.

The Class GenericType has two named instances: GENERIC and GENERIC_ENTITY. But there is no attribute in the metamodel that distinguishes these instances.

In the GenericTypes package, the two instances are distinguished only by their object-ids. It is inappropriate to assume that the Object-ids can be easily specified in an implementation.

The GenericType metaclass should have a ‘keyword’ attribute, to capture “GENERIC” and “GENERIC_ENTITY”.

Some addition to GenericType is needed for successful model exchange.
Note that the derived ParametricType has the ‘isEntity’ property for this purpose, while SimpleTypes have an ’id’ property (of type Keyword). Since the GenericType objects are parsed from EXPRESS source, it is probably best to use the ‘id: Keyword’ pattern.
This change also necessitates creating the slot values in the GenericTypes Instance package. Because the GenericTypes instance package is significantly revised by Issue 18815, the changes that resolve this Issue are incorporated into the Revised text of Issue 18815.
Revised Text:
The text changes are incorporated in Issue 18815.
Disposition: Merged

The two generalization sets for NamedElement (in Figures 8.2 and 15.2), both of which are said to be complete (“total”), are not the same.

There are three different categorizations of NamedElement – required Scope, actual Scope, and admissible in Scope.

For required scope, there are subclasses of NamedElement that can only be defined in a Schema, or only in a LocalScope or only in a NamedType scope, and there are subclasses that can be defined in more than one kind of Scope – CommonElements and ParametricElements. Neither diagram shows CommonElement in this way, and Figure 8.2 says its categorization is “total” (complete) but it does not include ParametricElement at all.

For admissibility, there are NamedElements that a Schema can define, NamedElements that a LocalScope can define, and NamedElements that a NamedType can define. This seems to be the intent of the categorization in Figure 8.2, given the definitions of CommonElement and SchemaElement. But LocalScope is an abstraction, and different kinds of LocalScopes have different admissibility rules. CommonElement is also a subtype of LocalElement, but such elements are admissible in AlgorithmScopes and not in other LocalScopes.

On the other hand, the definitions of TypeElement and LocalElement are about the actual scope of the Named Element, which is the inverse of the admissibility relationship (it can only be what is admissible). One would expect that CommonElement and ParametricElement would be subclasses of LocalElement, but the LocalScope.namespace would have to be 0..1.

Finally, CommonElement, LocalElement and TypeElement are all abstractions that simply NARROW the NamedElement abstraction and the NamedElement.namespace relationship in no clearly useful way. They have no other properties. If the intent is to narrow Scope.named-elements, then the model can omit LocalElement and TypeElement without loss, because the real rules are more constrained, and the purpose of LocalScope is to be what the Core defines it to be – “all other”. Whether CommonElement is more than a packaging convenience (a subset of the categorizations of SchemaElement and “AlgorithmElement”) is not clear.

CommonElement has the property it is defined to have: a choice of namespace Scopes. The RTF agrees that LocalElement and TypeElement are worthless abstractions – every subclass further redefines namespace. They will be deleted and their subclasses will inherit directly from NamedElement. Figure 8.2 is simplified. The complete generalization set for NamedElement is shown in Figure 15.2.
These changes are only to abstractions in the metamodel – they should have no affect on implementations.

At the beginning of the documentation of each of the packages in the EXPRESS metamodel, there is a section that refers to “dependencies”. The UML diagrams correctly show these relationships as package import and package merge. The text should be modified to use the correct UML/MOF terminology.

The text ‘dependency on’ will be changed to ‘imports package’ or ‘merges package’ as required.
Note: The resolution to Issue 19027 caused several of the Imported Packages to become package merges. This text reflects those changes.
Note: The resolution to Issue 18745 created similar text in Clause 8.1, which was also revised by this issue resolution.

Several UML diagrams in the EXPRESS metamodel bear the markup

over class-subclass decompositions. This markup is not documented in the text of the specification, and the implied generalization sets are not present in the MOF metamodel. The preferable solution is to create the generalization sets with the isDisjoint and isCovering features of MOF2.4. An alternative solution is to remove the text from the diagrams.

To improve the quality of the model, the RTF determined to create the GeneralizationSets that carry the intent of the markup, which was the default interpretation in UML v1.4 (the original source of the model). This requires changing many diagrams in only this way, and properly documenting the GeneralizationSets.
None of the generalization sets introduced in this revision are conceptually new – they all reflect restrictions defined by ISO 10303-11. Therefore the formalization should not affect implementations. The RTF regards these changes as improvements in the quality of the MOF model, not in its content.
There is an error in Figure 10.1, which says that the Instance categories are disjoint, although the diagram shows an overlapping subclass. This error is corrected in the metamodel (below), but the diagram is substantively modified by another Issue resolution.
The creation of certain generalization sets combines generalizations from different packages, and thus causes some package imports to become merges. The text of those sections is modified by Issue 19028, and is not corrected here.

The EXPRESS MM specification defines three Packages – BuiltInTypes, BuiltInConstants, and GenericTypes – that contain UML InstanceSpecifications. It also contains the Instance INDETERMINATE in the Instances package. These InstanceSpecifications represent predefined elements of the EXPRESS language that are instances of more general classes (of types and values) defined in the language. Because MOF does not support InstanceSpecification, the v1.0 MOF model does not contain any representation of these model elements. Standard representation of these model elements is critical to interoperable interchange of EXPRESS models. Some MOF-compatible representation of these model elements must be included in the specification and/or the normative artifacts.

The InstanceSpecifications are maintained in the (informative) UML model and in the text. The MOF model is accompanied by a “module” in the EXPRESS (M1) XMI form. For simplicity, the EXPRESSElements module combines all the UML packages. This is described in a new section (16) of the text. To properly construct the module, it is necessary to add the formal properties (slots) to the InstanceSpecifications.
It was noted in creating the EXPRESS modules that, although ISO 10303-11 refers to the elements in the BuiltInConstants module as “constants”, they are really just reserved words that are treated as Literals when they appear in expressions. Accordingly, the BuiltInConstants package is renamed BuiltInConstants and moved to the Expressions package, and the module is named accordingly. This has the advantage of allowing them to be formally included in a Scope as ‘Scope.expression’.
Note that moving the package does not affect conformance to the Expressions compliance point, because Expressions imports Instances. Technically it reduces requirements for the Instances compliance point, but Instances package support for the values that these Literals refer to is still required.
In a similar way, the INDETERMINATE object is already represented as a separate Expression (Primary) subclass: IndeterminateRef, and serves no purpose. It is deleted from the model.
Because Issue 19037 adds an attribute to the GenericType instances, the corresponding text changes are incorporated into the revised text below.

UML::Boolean (or PrimitiveTypes::Boolean) would be correct throughout the document (and MOF::Boolean strictly-speaking incorrect); and if the Express metamodel were to import the PrimitiveTypes model, then unadorned Boolean would do the trick nicely.

Make the Core Package explicitly import the UML PrimitiveTypes package, thus properly documenting the datatypes previously called “MOF datatypes”..
Modify section 8.2 to refer to UML Primitive Types.
Change all occurrences of MOF:Boolean, MOF:Integer, MOF:String to the corresponding UML primitive type.

I am puzzled by the use of the cmof: namespace in the cmof file. At version 2.4.1 it is normal to use UML XMI files for metamodels – see, for example, the UML 2.4.1 metamodel itself (http://www.omg.org/spec/UML/20110701/UML.xmi). I believe there is a fundamental misunderstanding here – from 2.4 onwards there is no longer any special cmof format. I think that simply deleting all of the MagicDraw-specific content from 13-05-34 would give almost all of what you want; you would perhaps then need a mof:Tag for nsPrefix to make it a correct metamodel.

For version 1.1, create a proper CMOF v2.4.1 XMI file.