Issues for XMI 2.5 Revision Task Force

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

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

Issue 9637: metamodel for XML Schema
Issue 9698: Section 8
Issue 15452: XMI issue - root elements for XMI Schemas
Issue 15887: Name transformation
Issue 16257: XMI should include a name transformation algorithm to convert names e.g. replace spaces by ‘_’
Issue 16272: attributes which apply to model elements and do not make sense at the XMI element level:
Issue 16273: In the XML Schema production rules the following in rule 4 is missing the option separator |:
Issue 16274: Rule 4f still uses the word “Reference” instead of Class-typed Property
Issue 16275: Rule 4f has an extraneous “>”
Issue 16276: The rule for 6f has become corrupted
Issue 16277: The production rule for Associations should use sequence if the tag order is set to true
Issue 16330: No unambiguous way in XMI 2.4 UML 2.4 to serialize UML 2.4's StructuredActivityNode
Issue 16331: XMI composite opposite constraint overly restrictive
Issue 16341: Revise XMI examples in 9.4
Issue 16585: EnumerationLiterals in the XMI
Issue 16889: Grammar for XML Schema - XMI 2.4 Beta
Issue 16890: Grammar for XML Schema - XMI XMI 2.1.1
Issue 17389: An XMIReferenceElement cannot be used for serializing a composite property

Issue 9637: metamodel for XML Schema (mof2xmi-rtf)

Given that the XMI spec contains a metamodel for XML Schema it would be possible to express the Schema production rules using QVT as a transformation from the MOF metamodel to the XSD metamodel. This would create a more rigorous specification that could be automated

Section 8: would be more usefully titled "The XML Schema Metamodel". An electronic version of this metamode is needed. It should reference a specific dated version of the XSD standard. The metamodel should specify the XMI tags required for serializatrion as XMI.

At the moment every metaclass has a XML element generated, allowing it to be the root of any interchange.

While this flexibility might be useful in some cases, it clogs up the XSD with elements that will never get used in practice.

 

Proposed resolution:

Define two boolean XMI Tags:

1. To define whether root elements should be restricted: org.omg.xmi.restrictRoots (defaults to true)

2.   To mark classifiers (classes or associations) as being potential roots: org.omg.xmi.rootElement (defaults to false)

Proposed Disposition:	Deferred

MOF/UML does not require names of elements in a metamodel to be valid XML names.

Therefore the XMI spec should document a transformation to be applied to cope with spaces, punctuation etc to be used for XML element and attribute names.

 

Metamodels do not necessarily use names compliant with XML syntax.

XMI should include a name transformation algorithm to convert names e.g. replace spaces by ‘_’

 

  In the XMI.xsd file, the xmi:XMI element has the following attributes which apply to model elements and do not make sense at the XMI element level:

-            <xsd:attribute ref="id"/>

-            <xsd:attributeGroup ref="IdentityAttribs"/>
  <xsd:attributeGroup ref="LinkAttribs"/>
  <xsd:attribute name="type" type="xsd:QName" use="optional" form="qualified"/>

( "<xsd:complexContent>"

                              "<xsd:extension base=’" 4a:ClassTypeName "’")?

…

                            ( "</xsd:extension>"

                              "</xsd:complexContent>" )?

Should be:

  ( "<xsd:complexContent>" |

                              "<xsd:extension base=’" 4a:ClassTypeName "’")?

…

                            ( "</xsd:extension>" |

                              "</xsd:complexContent>" )?

4f. ClassCompositions ::= ( "<xsd:element name=’" //Name of Reference// "’"

Should be:

4f. ClassCompositions ::= ( "<xsd:element name=’" //Name of Class-typed Property// "’"

 "></xsd:choice></xsd:complexType></xsd:element>" ) )*

Should be:

                                  "</xsd:choice></xsd:complexType></xsd:element>" ) )*

  ( 6b: DataTypeContents |

                                 "<xsd:any minOccurs=’0’ maxOccurs=’u

                                    processContents=’" // ProcessCont

                               "’/>")?

Should be:

                            ( 6b: DataTypeContents |

                                 "<xsd:any minOccurs=’0’ maxOccurs=’unbounded’

                                    processContents=’" // ProcessContents Value // 

                               "’/>")?

7. AssociationDef    ::= "<xsd:element name=’"’ 7a:AssnElmtName ’"’>"

                         "<xsd:complexType>

                         <xsd:choice minOccurs=’0’ 

                                      maxOccurs=’unbounded’>"

                         7b:AssnContents

                         "</xsd:choice>"

                         7d:AssnAtts 

                         "</xsd:complexType>

                         </xsd:element>"

Should be:

7. AssociationDef    ::= "<xsd:element name=’"’ 7a:AssnElmtName ’"’>"

                         "<xsd:complexType>”

                         (“<xsd:choice minOccurs=’0’ 

                                      maxOccurs=’unbounded’>" |

                          “<xsd:sequence>” )

                         7b:AssnContents

                         ("</xsd:choice>" | “<xsd:sequence>” )

                         7d:AssnAtts 

                         "</xsd:complexType>

                         </xsd:element>"

Replace the text for rule 7:

The declaration of an Association consists of the names of its AssociationEnd XML elements (whether 

or not they are owned by the Association).

With:

The declaration of an Association consists of the names of its AssociationEnd XML elements (whether 

or not they are owned by the Association). If org.omg.xmi.ordered is true then a sequence is used (with the order of ends being that form the metamodel), otherwise  a choice. 

We just recently had discussion with Ed about an issue with Activity::node and Activity::group. Both are composite non-derived properties and it causes problems with all StructuredActivityNodes, which are ActivityNodes and ActivityGroups at the same time. 
MagicDraw or Eclipse implementation of UML does not allow to own the same element in two composites , even if owner element is the same.
Does XMI support that?

So, ExpansionRegion or any other StructuredActivityNode appears in Activity::group only.  

fUML spec/engine expects to find them in Activity::node , as all owned nodes should be there.

Any suggestions? Don't you think we should fix that somehow?

The problem is that the combination of the UML, MOF and XMI specs taken together do not provide an adequate specification of how to serialize StructuredActivityNodes, which leads to ambiguity.
Currently, the ownership of StructuredActivityNode by Activity is derived, and is a subset of Activity::node and Activity::group.  This leads to the question of whether a StructuredActivityNode should be serialized as a node, as a group, or both.  This has obvious impacts on model interchange, and also impacts fUML.
The solution is to make the ownership of StructuredActivityNode by Activity non-derived, and then fix the MOF semantics and XMI serialization rules to ensure that a StructuredActivityNode is serialized in a structuredNode element, and not in a node or a group element.
This resolution fixes the XMI part; there are two counterpart issues corresponding to the UML and XMI parts.
The problem with XMI 2.4 is in the table in section 9.4.1 where it says “A Property, type is not a PrimitiveType or Enumeration, isComposite = true” must be serialized with a Nested XMIObjectElement.  This does not take account of situations where more than one composite property contains the same value, which is true for the case at hand.  The resolution is to note that according to MOF rules, there is only one property in the contained object that has a slot referring to the owner, and that the XMIObjectElement should be serialized for the property opposite that unique owner property.  Other composite properties in the same object with the same value must be serialized using a reference element.

Revised text:
Underneath table 9.4.1, add the following new “additional rule”:
ItIn table 9.4.1, in the XMI Representation column corresponding to “A Property, type is not a PrimitiveType or Enumeration, isComposite = true”, replace the existing text “Nested XMIObjectElement” by the following:
When the object has only one non-derived property with isComposite = true, that property is serialized as a nested XMIObjectElement.  However, it may be the case that an object has more than one non-derived property with isComposite=true, all containing the same value. In such a case, because of MOF constraints, only one of those properties will may have an opposite with a non-empty slot. The property with the non-empty opposite slot is serialized as a nested XMIObjectElement, and the others are notserialized either as XMIReferenceAttributes or nested XMIReferenceElements.

Disposition:	
Resolved

Section 9.4.1 of the specification contains the following constraint:


For Properties with isComposite=true, the opposite property is not serialized.

While this is fine when objects are nested it doesn't make sense when an object is serialised as a root object. For example, stereotype extensions are mapped to composite associations. Stereotypes instances are serialised as root objects because the composite property is not owned by the extended class. To attach them to their extended object the 'base' property is serialised, but this is the opposite of a property with isComposite=true.

These  examples in the XMI spec s have nothing to do with modeling but are related to Departments and stoplights.

Furthermore they do not show xmi:ids and xmi:types.

They should also illustrate some of the more sophisticated cases such as that introduced by Issue 16330.

Finally, the Figures in Section 9.4 are all labeled Figure 1

The EnumerationLiterals in the XMI include values for the ‘classifier’ property which is redefined to be derived in the metamodel.

Even if not derived it would be the inverse of the owning composition so should not be serialized.

 

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

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

Specification: OMG MOF XMI Mapping Specification, Version 2.4.1 (formal/2011-08-09)

 

Subclause 9.4.1 EMOF Package requires that “A property, type is not a PrimitiveType or Enumeration, isComposite=true” have an XMI representation of “Nested XMIObjectElement”. Nothing in Subclause 9.4.2 CMOF Package alters this.

 

The BNF for an XMIObjectElement is given in Subclause 9.5.2 Object Structure by production 2a:XMIObjectElement. This production does allow such an element to include 2d:XMIAttributes, but such attributes do not include hrefs. The production 2m:Link is the one for hrefs, and this is used in 2l:LinkAttribs, which is, in turn, used only by 2c:XMIReferenceElement. It is not included directly in 2a:XMIObjectElement.

 

So, the conclusion is that something like “<packagedElement href=”…”/> would not be a valid EMOF/CMOF serialization, since that is an XMIReferenceElement, not and XMIObjectElement, and packagedElement is a composite property. Divide a large model based on its hierarchical composition structure into across multiple XMI files, resulting in tool-specific approaches for such modularization in most major UML tools.

 

Suggested resolution: In the last line of the table in Subclause 9.4.1, change the XMI representation of “XMIObjectElement” to:

 

Choice of: 

1.       Nested XMIObjectElement 

2.       Nested XMIReferenceElement