EXPRESS11 — The two generalization sets for NamedType are inconsistent

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.