Issues for Canonical XMI Finalization Task Force 2

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 16575: xmi:uuid in Canonical XMI Jira Issue ZZCXMI-1
Issue 17489: Section B2 (Point 8) Jira Issue ZZCXMI-2
Issue 17492: Section B5.2 Jira Issue ZZCXMI-3
Issue 18970: Canonical XMI needs to ensure predictable XMI:ID for all instances of EMOF and CMOF metaclasses Jira Issue ZZCXMI-4
Issue 19808: Identification rules are too weak and too unpredictable Jira Issue ZZCXMI-24

Issue 16575: xmi:uuid in Canonical XMI (canonical-xmi-ftf)

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.    

How do you serialise a null value where there is a default?  This is probably a general issue with the XMI specification  rather than canonical

This imposes an alphabetic order on the superclasses that isn't  mentioned in the main specification for the superClassFirst option.  It isn't clear to me what this is ordered on. It can't just be  the name of the superclass, because there could be multiple  superclasses with the same name. It's also a very complicated  way to order the properties that will almost certainly be  inconsistent with the way the metamodel is defined. Why not  just sort the properties alphabetically by name?    

Canonical XMI B.6 Identification needs to be strengthened to guarantee predictable XMI:ID for all metaclasses in the scope of an EMOF/CMOF metamodel except for Comments.  Comments in EMOF/CMOF metamodels must be restricted to annotate elements in the same EMOF/CMOF metamodel as the Comment.      The XMI:IDs for UML 2.4 and 2.5 come from the Eclipse UMLUtil class (see http://download.eclipse.org/modeling/mdt/uml2/javadoc/4.1.0/org/eclipse/uml2/uml/util/UMLUtil.html)  This utility class provides the functionality of the Canonical XMI identification scheme in section B.6      However, for UML 2.5, this scheme had to be overridden for the generation of XMI:ID of Generalization relationships.  Since UML's Generalizations are not ordered (UML's Classifier::generalization : Generalization[*] is not ordered),  their XMI:ID is not predictable.      The workaround involved extracting from the OMG UML 2.4 XMI a table mapping each Generalization's XMI:ID to the pair of XMI:ID for its general and specific Classifiers.  The XMI:ID for Generalizations in UML 2.5 was set by looking up in this table the XMI:ID of the Generalization general & specific Classifiers. If there was an entry in that table, the table's XMI:ID was used; otherwise the XMI:ID was generated using the Eclipse UMLUtil.      The problem is not unique to Generalizations; it affects several metaclasses allowed in CMOF.  To ensure predictable XMI:ID for ALL allowed EMOF/CMOF metaclasses, the algorithm in B.6 must be modified to produce XMI:IDs in several phases:      Phase 1 = Apply B6 to all allowed metaclasses except for any of the following kind:  DirectedRelationship   BehavioralFeature  ValueSpecification  InstanceSpecification  UMLDiagramElement (for UML2.5's UMLDI)  This allows generating XMI:ID for metaclasses that have an intrinsic ID due to their qualified name only; i.e: Package and Classifier (Class, Association, DataType, PrimitiveType)      Phase2 = Phase1 + BehavioralFeature; i.e., Operation, Parameter      Phase3 = Phase2 + DirectedRelationship; I.e: ElementImport, Generalization, PackageImport, PackageMerge      Phase4 = Phase3 + InstanceSpecification + ValueSpecification; I.e.: EnumerationLiteral; InstanceValue, InstanceSpecification (for models of EMOF/CMOF metamodels), LiteralBoolean, LiteralInteger, LiteralNull, LiteralReal, LiteralString, LiteralUnlimitedNatural, OpaqueExpression      Phase5 = Phase4 + UMLDiagramElement; I.e. All concrete subclasses of UMLDiagramElement; see UML2.5, Annex B      This 5-phase approach has been used for generating the official XMI for OMG's UML 2.5 and DD 1.0.1 � see https://dev.enterprisecomponent.com/repository/repos/UML-Spec-Simplification/trunk/pluglets/Normalize.java  

The Canonical XMI rules for generating xmi:ids (section B6) are too weak to ensure reproducible results.      Consider the following procedure:      - Start a tool that supports Canonical XMI xmi:id generation  - Load an input model  - Compute the xmi:ids for all elements in the model      Repeated executions of this procedure with the same tool, same input model should always result in the same xmi:ids.  Reproducibility depends on the model. For example, the xmi:ids of comments owned by an element result are ordered by the "_n" unique suffix according to the order of their xmi:uuids. However, if modeling do not support xmi:uuids or do not preserve them, then the results can vary.      The Canonical XMI rules for generating xmi:ids (section B6) are too unpredictable because of the dependency on XMI serialization.      There are several cases where the xmi:id of an element depends on its serialization:      - multiple named elements that have the same name, the same owner and the same containing property.   - multiple named elements that have the same owner and the same containing property but whose names differ only in characters that indistinguishably map to "_"  - multiple non-named elements that have the same owner and the same containing property      In all such cases, rule (4) appends a unique "_n" suffix according to the "export order"; which ultimately reduces to the ordering of xmi:uuids of an element amongst its siblings that have the same "base name". This means that changes somewhere in a model can result in unmodified elements elsewhere to have different xmi:ids than before the changes were made.       If a tool implements Canonical XMI when saving/exporting models, then the xmi:id rules behavior effectively injects changes into a user's model (on save/export). There could be pathological cases where adding/removing a single element in a model with N (very large) elements could result in changing most of the model! (this is because a change in an xmi:id then propagates into changes to xmi:idrefs that refer to that changed xmi:id).    In practice, weaknesses and unpredictability severely undermine the utility of Canonical XMI identification rules.