Issue 16573: Please provide a complete set of production rules
Issue 16574: XMI schema and document production rules in both XMI2.4 and in Canonical XMI are particularly difficult to follow
Issue 16575: xmi:uuid in Canonical XMI
Issue 16576: B.6 Identification
Issue 16888: Grammar for XML Schema - XMI Canonical
Issue 17260: Section B5.1
Issue 17261: The clause in B5.2 is a bit opaque
Issue 17262: In B5.2 should clarify that redefining a property does not affect its order within its class
Issue 16573: Please provide a complete set of production rules (canonical-xmi-ftf)
Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:
In B.3.2 and B.4, it would be easier to see the complete set of rules instead of just those that Canonical XMI supersedes from XMI 2.4. Perhaps the rules that are modified in Canonical XMI could be highlighted in boldface. Their organization is already non-trivial, jumping back & forth makes reading the rules a lot more difficult.
2) The XMI schema and document production rules in both XMI2.4 and in Canonical XMI are particularly difficult to follow because it is unclear at which level one should interpret references to "Class", "DataType" and "Property". For example, B3.2 in Canonical XMI reads: 4. ClassTypeDef ::= "<xsd:complexType name=’" //Name of Class// "’>" ... 4a. ClassTypeName ::= 1h:Namespace //Name of Class// 4d. ClassAttributes ::= ( "<xsd:element name=’" //Name of DataType-typed Property// "’" Does "Class" here refer to a Class in a user model (sometimes called an M1 model) or a metaclass (i.e., sometimes called an M2 model) or something else? The fact that the rules only mention "Class", "DataType" and "Property" is rather perplexing because there is no reference as to where these concepts are defined. Are these terms references to instances of MOF metaclasses or something else? It would help to provide a fully worked out example of a CMOF metamodel, produce the XSD for that metamodel from the rules (assuming that one can follow how the rules are applied to produce the resulting schema) and apply the document production rules to an instance of that CMOF metamodel to obtain the corresponding XML document that should be valid w.r.t. the XSD.
This attribute is used for ordering elements as described in B.5 Since Canonical XMI makes xmi:uuid mandatory, it seems reasonable to expect that some tools may change the value of xmi:ids on import/export. It seems that Canonical XMI should require a scheme such as option 3 in XMI 2.4, section 7.10.2.2 for linking across XMI documents. Currently, Canonical XMI does not make such restriction on the scheme for linking across documents. Since the xmi:id based scheme (option 1 in XMI 2.4, section 7.10.2.2) is the most common, it means that Canonical XMI serialization implicitly requires tools to preserve xmi:id values on import/export. If the requirement on preserving xmi:id values is too strong, then Canonical XMI needs to require a cross-document linking scheme that is based on xmi:uuid values and that specifically prohibits using xmi:id values except for references within the same document.
The rule in the second bullet is insufficient to guarantee stable generation of xmi:id values.
Consider the following excerpt from UML2.4.1's XMI (http://www.omg.org/spec/UML/20101101/UML.xmi)
<packagedElement xmi:type="uml:Class" xmi:id="Namespace" name="Namespace" isAbstract="true">
...
<ownedAttribute xmi:type="uml:Property" xmi:id="Namespace-importedMember" name="importedMember" visibility="public" type="PackageableElement" isReadOnly="true" isDerived="true" subsettedProperty="Namespace-member" association="A_importedMember_namespace">
<ownedComment xmi:type="uml:Comment" xmi:id="Namespace-importedMember-_ownedComment.0" annotatedElement="Namespace-importedMember">
<body>References the PackageableElements that are members of this Namespace as a result of either PackageImports or ElementImports.</body>
</ownedComment>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="Namespace-importedMember-_upperValue" value="*"/>
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="Namespace-importedMember-_lowerValue"/>
</ownedAttribute>
...
<ownedAttribute xmi:type="uml:Property" xmi:id="Namespace-ownedMember" name="ownedMember" visibility="public" type="NamedElement" isReadOnly="true" isDerived="true" isDerivedUnion="true" aggregation="composite" subsettedProperty="Namespace-member Element-ownedElement" association="A_ownedMember_namespace">
<ownedComment xmi:type="uml:Comment" xmi:id="Namespace-ownedMember-_ownedComment.0" annotatedElement="Namespace-ownedMember">
<body>A collection of NamedElements owned by the Namespace.</body>
</ownedComment>
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="Namespace-ownedMember-_upperValue" value="*"/>
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="Namespace-ownedMember-_lowerValue"/>
</ownedAttribute>
...
<ownedOperation xmi:type="uml:Operation" xmi:id="Namespace-importedMember.1" name="importedMember" visibility="public" isQuery="true" bodyCondition="Namespace-importedMember.1-spec">
<ownedComment xmi:type="uml:Comment" xmi:id="Namespace-importedMember.1-_ownedComment.0" annotatedElement="Namespace-importedMember.1">
<body>The importedMember property is derived from the ElementImports and the PackageImports. References the PackageableElements that are members of this Namespace as a result of either PackageImports or ElementImports.</body>
</ownedComment>
<ownedRule xmi:type="uml:Constraint" xmi:id="Namespace-importedMember.1-spec" name="spec" constrainedElement="Namespace-importedMember.1 Namespace-importedMember">
<specification xmi:type="uml:OpaqueExpression" xmi:id="Namespace-importedMember.1-spec-_specification">
<language>OCL</language>
<body>result = self.importMembers(self.elementImport.importedElement.asSet()-
>union(self.packageImport.importedPackage->collect(p | p.visibleMembers())))</body>
</specification>
</ownedRule>
<ownedParameter xmi:type="uml:Parameter" xmi:id="Namespace-importedMember.1-result" name="result" visibility="public" type="PackageableElement" direction="return">
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="Namespace-importedMember.1-result-_upperValue" value="*"/>
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="Namespace-importedMember.1-result-_lowerValue"/>
</ownedParameter>
</ownedOperation>
...
<ownedOperation xmi:type="uml:Operation" xmi:id="Namespace-ownedMember.1" name="ownedMember" visibility="public" isQuery="true" bodyCondition="Namespace-ownedMember.1-spec">
<ownedComment xmi:type="uml:Comment" xmi:id="Namespace-ownedMember.1-_ownedComment.0" annotatedElement="Namespace-ownedMember.1">
<body>Missing derivation for Namespace::/ownedMember : NamedElement</body>
</ownedComment>
<ownedRule xmi:type="uml:Constraint" xmi:id="Namespace-ownedMember.1-spec" name="spec" constrainedElement="Namespace-ownedMember.1 Namespace-ownedMember">
<specification xmi:type="uml:OpaqueExpression" xmi:id="Namespace-ownedMember.1-spec-_specification">
<language>OCL</language>
<body>true</body>
</specification>
</ownedRule>
<ownedParameter xmi:type="uml:Parameter" xmi:id="Namespace-ownedMember.1-result" name="result" visibility="public" type="NamedElement" direction="return">
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="Namespace-ownedMember.1-result-_upperValue" value="*"/>
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="Namespace-ownedMember.1-result-_lowerValue"/>
</ownedParameter>
</ownedOperation>
</packagedElement>
UML::Operation is an instance of the metaclass: UML::Class, which has several properties including:
- ownedAttribute: importedMember, ownedMember
- ownedOperation: importedMember, ownedMember
The rule in B5.1 seems incomplete.
It should specify that for a given element (e.g., UML::Operation as above), then nested elements are ordered alphabetically by the name of the meta-property.
In the above example, UML::Operation has metaclass UML::Class; whose meta-properties include, in alphabetical order, UML::Class::ownedAttribute and UML::Class::ownedOperation.
The alphabetical ordering of these meta-properties is used for serializing the values of these metaproperties but also for generating their xmi:ids as well.
That's why the ownedAttribute UML::Operation::importedMember has xmi:id="Namespace-importedMember" whereas the ownedOperation UML::Operation::importedMember has xmi:id="Namespace-importedMember.1"
In particular, the last sentence in the 2nd bullet of B6 is incorrect:
Note that named elements (which satisfy the first rule) are still included in this count.
That is, the "-<N>" suffix starts with N=1 when the generated xmi:id would otherwise conflict with a previously generated xmi:id;
that is, N=2 corresponds to the second element that has the same qualified name; N=3 corresponds to the third, etc...
As part of our UML work for the National Information Exchange Model (NIEM) we have encountered what appear to be errors in the grammars for XML Schema in several XMI specs. Please let us know if we have misinterpreted these issues
Section B5.1 should reference the section in the main XMI spec that determines the element name rather than vaguely saying “based on the metamodel classifier”.
The clause in B5.2 is a bit opaque – it could usefully be spelled out a bit more e.g. “Properties of an element are ordered by the class in which they are defined. Properties defined by a superclass appear before those of its subclasses. Where a class inherits from more than one direct superclass, properties from the class with the alphabetically earlier class name appear before those of an alphabetically later class name.”
In B5.2 should clarify that redefining a property does not affect its order within its class