Issues for XMI 2.6 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 7599: Which type of name should be used Jira Issue XMI24-1
Issue 9637: metamodel for XML Schema Jira Issue XMI24-2
Issue 15452: XMI issue - root elements for XMI Schemas Jira Issue XMI24-3
Issue 15613: Extension is only referenced from 1a. However it certainly should be valid within an XMIObjectElement. Jira Issue XMI24-124
Issue 15887: Name transformation Jira Issue XMI24-4
Issue 16257: XMI should include a name transformation algorithm to convert names e.g. replace spaces by �_� Jira Issue XMI24-5
Issue 16341: Revise XMI examples in 9.4 Jira Issue XMI24-6
Issue 16582: No XML-Schema for UML-XMI Jira Issue XMI24-7
Issue 18838: MOF/XMI schemaType is incorrectly defined relative to its use and its scope is too restrictive Jira Issue XMI24-8
Issue 19552: [MOF2] and [UML2] not further specified in the document Jira Issue XMI24-9
Issue 19719: Canonical XMI (ptc/2013-08-28): need rules for generating xmi:id and xmi:uuid for auxiliary XML elements Jira Issue XMI24-10

Issue 7599: Which type of name should be used (mof2xmi-rtf)

This problem is preventing me from implementing a XMI 2.0 Schema generator for a MOF 1.4 metamodeling environment. The specification is often unclear about which type of name (short name, fully-qualified name, or namespace-qualified name) should be used. >From section 1.8.1: �The XML element name for each metamodel class, package, and association in a document is its short name.� Then, in section 2.2.1, rule 4 we have �ClassTypeDef ::= "<xsd:complexType name=�" //Name of Class//��. Now, the w3 xml schema specification (http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ states that �no complex type definition can have the same name as another simple or complex type definition.� If the spec means that we should use the short name of the Class in rule 4 above, then it isn�t in line with the xml schema specification, because it�s obvious that several classes in different namespaces of the same metamodel can have the same short name. Furthermore, the w3 schema specification defines the name attribute of a complexType declaration to be of type NCName, or �non-colonized name�. This means that we can�t use the namespace-qualified name for the Class either. The only solution is to use the fully-qualified name for metamodel elements** when defining their types. **The fully-qualified name of a metamodel element lists all of the encapsulating MOF Namespaces of the element. So, if you have Class A in nested Package B in outermost Package C, the qualified name of A would be �C.B.A�.   

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

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

 3:Extension is only referenced from 1a. However it certainly should be valid within an XMIObjectElement.        (3:Extension)* should be added to 2a     

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.         

More time is required to develop a reliable transformation algorithm that can handle  all possible non-XML characters that can occur in model element names. This goes  way beyond just spaces.  Disposition: Deferred

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 �_�         

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    

More time is required to develop more sophisticated examples. The figure numbering  error, however, has already been corrected in the context of the ISO/PAS revision.  Disposition: Deferred

While for older versions of XML the concrete syntax for persisting UML models was given in DTD, for newer versions of XMI a related concrete syntax specification e.g. as XML Schema is missing (even if the syntax is described in ptc/2010-12-06). Pure syntax compliance tests for given XMI files cannot be performed.

This issue was transferred from the UML FTF with the mandate �The XMI RTF is  encouraged either to delete or deprecate the XSD generation rules from its  specification, or to improve them so they meet the expectations of customers that  schema validation corresponds to syntactic correctness.�  The XMI RTF believes that more time is needed to reach a satisfying conclusion.  Disposition: Deferred

MOF/XMI defines the schemaType tag as follows: "The name of a datatype defined in the XML Schema Datatype specification."      First,the examples in the MOF/XMI specification and current use of this tag in OMG's XMI artifacts use datatype URIs, not datatype names.      Second, the definition of this tag is vague about which datatypes are allowed.      - The builtin datatypes explicitly defined in the XML Schema Datatype spec? http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#built-in-datatypes  - Any datatype defined in the "xs" namespace?       Consider for example "precision decimal", a datatype that is explicitly mentioned but not explicitly defined in the XML Schema Datatypes spec:  http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#primitive-vs-derived  This datatype is explicitly defined in a different specification but in the "xs" namespace: http://www.w3.org/TR/xsd-precisionDecimal/#precisionDecimal      This example illustrates the ambiguity of the scope as currently specified, that is, is "xs:precisionDecimal" allowed as a value for schemaType?      Third, even if schemaType were to be clarified to be some subset of datatypes defined in the "xs" namespace, there are legitimate business reasons to expect greater flexibility.      - Several OMG specifications define XSDs (e.g., BPMN, DTV, �) If these include XML Schema datatype definitions, why are we precluded from referring to them via a PrimitiveType that has a schemaType tag pointing to their URI?  - For working with RDF, it would make sense to define a PrimitiveType whose schemaType tag maps it to rdf:PlainLiteral � I.e., http://www.w3.org/TR/rdf-plain-literal/#Definition_of_the_rdf:PlainLiteral_Datatype  - Similarly, for OWL, it would make sense to define PrimitiveType that would be mapped to owl:Rational and owl:Real: http://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#Datatype_Maps      

This issue was received well after the comment deadline and would require a fair bit  of thought as to the implications � not only on XMI but other specifications including  MOF and metamodels.  Disposition: Deferred

The subsection refers to documents [MOF2] and [UML2] which are not further specified in the document.

Canonical XMI, ptc/2013-08-28, states that xmi:uuid must be always present (B2, #5) except for values that are datatypes (B2, #7).  What does "values that are datatypes" in B2 #7 mean?      Are auxiliary XML elements like mofext:Tag and stereotype instances considered "values that are datatypes" ?      If not, then according to B2 #5, these auxiliary XML elements must have identification attributes (xmi:id and xmi:uuid).      Historically, the OMG used rather arbitrary conventions for producing the xmi:id of mofext:Tag � not a big deal because nobody really refers to them. However, these arbitrary conventions break the repeatability and reproducibility of Canonical XMI!      The Canonical XMI document production rules in B4 are incomplete: they should be augmented to specify the serialization, identification and ordering of auxiliary XML elements.      Consider augmenting the Canonical XMI specification B6 with the following rules:      Generate the xmi:id and xmi:uuid for mofext:Tag by appending "_mofext.Tag" to the xmi:id and xmi:uuid respectively of the referenced element.      Generate the xmi:id and xmi:uuid for stereotype instances by concatenating the xmi:id and xmi:uuid respectively of the stereotype with that of the element on which the stereotype is applied.