1. OMG Mailing List
  2. XMI 2.6 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: mof2xmi-rtf
  • Issues Count: 16

Issues Descriptions

The processContent attribute should be "lax" in the official XMI.xsd

  • Key: XMI26-5
  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    As suggested by Pete while reviewing the XMI files generated for SysML 1.5, the official XMI.xsd should have the processContent attribute set to "lax" instead of "strict". It would allow using it for validating official XMI files for specification related to UML (e.g. SysML) since UML has no XSD.

  • Reported: XMI 2.5 — Wed, 14 Dec 2016 16:30 GMT
  • Updated: Thu, 22 Dec 2016 19:27 GMT

9.4.1 serialization of a composite property typed by a class

  • Key: XMI26-2
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Table 9.4.1 states:

    Choice of:
    1. XMIObjectElement
    2. Nested XMIReferenceElement
    3. Nested XMIReferenceAttribute

    Normally, serialized properties with isComposite = true are serialized as nested XMIObjectElements.
    In the case where the model is split across more than one file then a nested XMIReferenceElement would be used. Exceptionally, even within one file, it may be the case that a containing object has more than one serialized class-typed property with isComposite = true that, contain the same object or include it among their collection of objects. In such an exceptional case, because of MOF contstraints, only one of those properties can have an opposite with a non-empty slot. Objects of the property with the non-empty opposite slot are serialized as nested XMIObjectElements, and the other references to the same object are serialized either as XMIReferenceAttributes or nested XMIReferenceElements.

    This rule is very bad for several reasons:

    1) The criteria for determining which of the 3 possible options is very difficult to understand

    2) Words such as "Exceptionally" convey a sense that there is a distinction that should be seldom relevant in practice. This is definitely not the case. This rule affects all serializations of UML profiles and UML models that contain Structured Activities.

    3) Whether a model is serialized in one or multiple files has nothing to do with the intent of this rule. Mentioning this adds an unnecessary layer of complexity to the rule.

    4) The criteria for choosing between nested vs. reference/attribute serialization refers to unexplained considerations about MOF:

    • no explanation in the XMI spec
    • no cross-references to existing explanations in MOF specifications (it is even unclear which MOF specifications, if any, have such explanations)

    5) The combination of no illustrative example and of exceptional opacity has contributed to legitimate doubts as to whether there exists any truly conforming implementation of XMI 2.x (incl. 2.5.1) and whether claims of conformance to the XMI 2.x specification can be independently verified by non XMI experts.

    Suggest:

    a) Reword this rule to clearly explain all of what is necessary to unambiguously and deterministically determine whether a value of a composite property typed by a class must be serialized as a nested element, a nested reference or an attribute reference.

    b) Provide examples for all three options

  • Reported: XMI 2.5 — Wed, 22 Jun 2016 22:00 GMT
  • Updated: Thu, 23 Jun 2016 15:23 GMT

9.4.1 serialization of a null-valued property typed by an enumeration or primitive type

  • Key: XMI26-1
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Table 9.4.1 states:

    When the value of a Property is null, it is serialized as XMIValueElement with attribute nil=’true’.

    In UML, null means "lack of a value".
    MOF (which is based on a subset of UML) inherits this – that is, for MOF, null also means "lack of a value".

    Currently, many UML tools do not serialize null-valued properties according to the rule above, instead, the property is not serialized at all.

  • Reported: XMI 2.5 — Wed, 22 Jun 2016 21:45 GMT
  • Updated: Thu, 23 Jun 2016 04:59 GMT

XMI spec lacks support for profiles

  • Key: XMI26-4
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    In principle, any metamodel can have a profile extending it.
    The XMI spec only addresses producing an XMI schema for a metamodel. The XMI spec should also address the production of an XMI schema for a profile that extends one or model metamodels.

    In principle, any model that is an instance of a metamodel extended by one or more profile can be augmented with the application of such profiles. The XMI spec only addresses the production of an XMI document for the model itself. The XMI document production rules should also cover the augmentation of such a model corresponding to the profile-defined stereotypes applied and to the profile-defined datatypes & classes instantiated.

  • Reported: XMI 2.5 — Wed, 22 Jun 2016 22:14 GMT
  • Updated: Wed, 22 Jun 2016 22:14 GMT

9.4.1 serialization of a property typed by a structured datatype

  • Key: XMI26-3
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Table 9.4.1 states:

    Choice of:
    1. XMIObjectElement
    2. XMIValueAttribute
    3. Nested XMIValueElement
    By default instances of structured datatypes are serialized as if they were classes, as described in 7.8.7. This can be overridden by the tag org.omg.xmi.flattenStructuredDatatypes in which case the values of the Properties are serialized as a single string separated (by default) by commas. The default separator can be overridden by the XMI org.omg.xmi.valueSeparator tag.

    The flag org.omg.xmi.flattenStructuredDatatypes adds a layer of complexity for XMI interchange because tools need to handle effectively two different serialization strategies: flatten vs. structured.

    The benefit of flattened structured datatype value serialization is questionable because its relevance has not been established in current practice and current implementations.

    Suggest eliminating org.omg.xmi.flattenStructuredDatatypes.

  • Reported: XMI 2.5 — Wed, 22 Jun 2016 22:06 GMT
  • Updated: Wed, 22 Jun 2016 22:06 GMT

Extension is only referenced from 1a. However it certainly should be valid within an XMIObjectElement.

  • Key: XMI24-124
  • Legacy Issue Number: 15613
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    3:Extension is only referenced from 1a. However it certainly should be valid within an XMIObjectElement.

    (3:Extension)* should be added to 2a

  • Reported: XMI 2.4 — Tue, 21 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Canonical XMI (ptc/2013-08-28): need rules for generating xmi:id and xmi:uuid for auxiliary XML elements

  • Key: XMI24-10
  • Legacy Issue Number: 19719
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    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.

  • Reported: XMI 2.4 — Sun, 8 Feb 2015 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

[MOF2] and [UML2] not further specified in the document

  • Key: XMI24-9
  • Legacy Issue Number: 19552
  • Status: open  
  • Source: supportgis.de ( Martin Dieblich)
  • Summary:

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

  • Reported: XMI 2.4 — Wed, 30 Jul 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

MOF/XMI schemaType is incorrectly defined relative to its use and its scope is too restrictive

  • Key: XMI24-8
  • Legacy Issue Number: 18838
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    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.

    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?

  • Reported: XMI 2.4 — Wed, 31 Jul 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

No XML-Schema for UML-XMI

  • Key: XMI24-7
  • Legacy Issue Number: 16582
  • Status: open  
  • Source: Software Systems Engineering ( Holger Eichelberger)
  • Summary:

    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.

  • Reported: XMI 2.4 — Wed, 5 Oct 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Revise XMI examples in 9.4

  • Key: XMI24-6
  • Legacy Issue Number: 16341
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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

  • Reported: XMI 2.4 — Tue, 21 Jun 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

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

  • Key: XMI24-5
  • Legacy Issue Number: 16257
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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 ‘_’

  • Reported: XMI 2.4 — Thu, 19 May 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Name transformation

  • Key: XMI24-4
  • Legacy Issue Number: 15887
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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.

  • Reported: XMI 2.4 — Thu, 9 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

XMI issue - root elements for XMI Schemas

  • Key: XMI24-3
  • Legacy Issue Number: 15452
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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)

  • Reported: XMI 2.4 — Wed, 8 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

metamodel for XML Schema

  • Key: XMI24-2
  • Legacy Issue Number: 9637
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    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

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Which type of name should be used

  • Key: XMI24-1
  • Legacy Issue Number: 7599
  • Status: open  
  • Source: ISIS ( Matt Emerson)
  • Summary:

    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’.

  • Reported: XMI 2.0 — Tue, 27 Jul 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT