Issue 16573: Please provide a complete set of production rules Jira Issue ZZCXMI-5
Issue 16574: XMI schema and document production rules in both XMI2.4 and in Canonical XMI are particularly difficult to follow Jira Issue ZZCXMI-6
Issue 16576: B.6 Identification Jira Issue ZZCXMI-7
Issue 16888: Grammar for XML Schema - XMI Canonical Jira Issue ZZCXMI-8
Issue 17260: Section B5.1 Jira Issue ZZCXMI-9
Issue 17261: The clause in B5.2 is a bit opaque Jira Issue ZZCXMI-10
Issue 17262: In B5.2 should clarify that redefining a property does not affect its order within its class Jira Issue ZZCXMI-11
Issue 17487: What order should be used for the namespaces? Jira Issue ZZCXMI-12
Issue 17488: Section B2 (Point 5) Jira Issue ZZCXMI-13
Issue 17490: Section B2 Jira Issue ZZCXMI-14
Issue 17491: Section B5.1 Jira Issue ZZCXMI-15
Issue 17493: Section B5.3 Jira Issue ZZCXMI-16
Issue 17495: Section B6 - identification algorithm isn't terribly clear Jira Issue ZZCXMI-17
Issue 17496: Section B7 - The example has a number of constraints that are exported as top level elements Jira Issue ZZCXMI-18
Issue 17497: Section B7 - href="#xpointer(...)" is wrong Jira Issue ZZCXMI-19
Issue 17552: opposite properties need to be serialized Jira Issue ZZCXMI-20
Issue 18288: Canonical XMI: Problems with B6 Identification rules - better startefy for handling speciel characters needed Jira Issue ZZCXMI-21
Issue 18289: DDTV spec had named element whose qualified name matched name generated by procedure described in section B6 Jira Issue ZZCXMI-22
Issue 18786: Canonical XMI should mandate use of Canonical Lexical Representation for XML Jira Issue ZZCXMI-23
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.
Duplicating the rules would result in problems in maintenance. Once Canonical XMI is complete both sets of rules will be in the same document. Disposition: Closed, no change
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 is an issue with the XMI spec generally Canonical XMI which uses the same terminology. The whole specification is related to MOF models and is independent of any specific metamodels such as UML (except where it appears in examples) so the terms Class, Property etc clearly apply to elements in the metamodel Disposition: Closed, no change
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 (https://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...
Rules B5.1 is only about "top level elements in the XMI file (direct descendants of the XMI element)". For the example in the issue "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." that is covered by rule B5.2 which states that "The order of the XML elements for Properties is order of the properties for the class in the metamodel." Disposition: Closed, no change
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
Section B2 (Point 3) What order should be used for the namespaces?
The ordering is slightly inconsistent with the way root objects are serialised, eg <uml:Class .../>, with the type first. This has made exporting from our tool more complex than would be necessary if xmi:type was first.
While the ordering with xmi:type first might have been a better choice originally, the benefit of changing it at this stage is outweighed by the backward compatibility issues that would arise. Disposition: Closed, no change
Bullet org.omg.xmi.ordered = true (forces ordering of properties) should probably be described as (forces ordering of values), particularly given that org.omg.xmi.superClassFirst is described in an identical manner, but means something completely different.
Why does this use a different order to nested elements as given in section B5.3?
B5.1 states to order elements by XML element name then uuid. B5.3 refers to elements within a single class-typed property � so they will all have the same XML element name � hence the rule to sort by uuid within that is actually the same. Disposition: Closed, no change
Nested elements are ordered by uuid. While there's nothing wrong with that it seems a shame to lose alphabetic ordering by name, which makes the XMI easier to read. Perhaps sorting could be by name if there is one and then by uuid?
Human readability is not really a prime concern of XMI. The big disadvantage of sorting in name is that names can change (unlike uuids) so that the same object would appear in a different position. Disposition: Closed, no change
The identification algorithm isn't terribly clear and has several variants that could be simplified into a single approach. It references UML qualified names, which doesn't make sense as this algorithm should work for a general MOF metamodel. Overloading '-' for separating objects and numeric discriminators is unwise as it means uniqueness checks must go beyond the peer elements. Alternative algorithm 1) The base name for an object is its name*. If there is no name, the base name is the name of the owning property or "_" for a top level object. 2) Any base name characters that are not (NCNameChar - '-') should be replaced with '_'. If a top level object does not start with (Letter | '_') a '_' should be prefixed. 3) If the object has no name or the base name is a duplicate of an earlier (by export order) peer base name append a numeric qualifier: a) append '_' if the last character is not already one b) append a sequence number, starting with 1 when the object has no name and 2 if it does. It is possible that an earlier peer name contains an '_n' suffix that creates a name collision. In this case increment the sequence number until no collision exists. 4) The id for a root object is the base name. The id for a nested object is parent id + '-' + base name. *There is no universal name property. So a tag should be introduced to identify valid name properties.
The example has a number of constraints that are exported as top level elements. Why is this the case? The canonical form needs to choose a single representation. Composite objects should always be exported as nested elements if possible
href="#xpointer(...)" is wrong. xmi:label is excluded from canonical form, in particular from the example. External references should use a canonical form that doesn't use xpointer. They should probably always use the uuid, assuming that it is a URI.
In XMI generally it�s fine and valid to serialize either end of a pair of opposite properties: it�s not required to serialize both. However for Canonical XMI this must be predictable and consistent so I guess both would need to be serialized. This needs to be made clear in the spec
The spec says "Where the above rules result in characters not permitted for identifiers in XML documents (for example space, �/� or �:� these must be replaced by �_�." DTV had elements named like this: "DateTime-Time_Infrastructure-duration1_<_duration2" "DateTime-Time_Infrastructure-duration1_=_duration2" Obviously, if I change < and = to _, two elements will have the same name. We need a better strategy for handling special characters.
The DTV spec had a named element whose qualified name matched a name generated by a procedure described in the spec section B6: In other cases the xmi:id is the xmi:id of the parent XML element (or �_� for top level elements), followed by the separator �-�, followed by the name of the property (XML element. If there is more than one value for the property this is further followed by �-� followed by the sequence number (from 1) within the parent element and the property. Note that named elements (which satisfy the first rule) are still included in this count. The named element was not a sibling, so the part "Note that named elements...are still included in this count" did not apply. One quasi-solution is to use numbering whenever there is not a qualified name. Simply strike the phrase "If there is more than one value of the property this is further" in the above. The problem with this is that there could still be a element with a qualified name that matches the generated xmi:id (it could end with a number)! Perhaps we need to add "If the resulting name is a duplicate of a name generated using the procedure for qualified names described above, the first sequence number where duplication does not occur is used." I realize that these are pretty complicated rules.
Detail: XML allows a number of serialization options ? for example xs:booleann may be serialized as �0� and �1� in addition to �false� and �true�. However the XSD spec does define a Canonical Lexical Representation that removes this variability: see http://www.w3.org/TR/xmlschema-2/#canonical-lexical-representation This should be mandated by the Canonical XMI Spec.