${taskforce.name} Avatar
  1. OMG Task Force

XMI 2.1 RTF — Open Issues

  • Key: XMI21
  • Issues Count: 24
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
XMI21-4 Revise 7.13.2 XMI Document Exchange with Multiple Tools XMI 2.0 open
XMI21-2 section 8.2.1 on page 46 (editorial) XMI 2.0 open
XMI21-3 XMI 2.0 terminology XMI 2.0 open
XMI21-8 Mandatory Extensions when enforceMinimumMultiplicity is true XMI 2.0 open
XMI21-5 section 8.2.1 on page 44 (editorial) XMI 2.0 open
XMI21-7 XMI for TypeLibrary::Objects::Object is Unspecified XMI 1.3 open
XMI21-11 ISSUE: XMI for MOF 2 does not reflect MOF 2 model XMI 1.3 open
XMI21-9 ISSUE: XMI for MOF 2 should address models, not just metamodels XMI 1.3 open
XMI21-6 section 8.2.1 on page 46 (editorial) XMI 2.0 open
XMI21-1 section 7.10.2.2(.2) on page 23 (editorial) XMI 2.0 open
XMI21-10 XMI for MOF 2 defines tagged values XMI 1.3 open
XMI21-20 Remarks to chapter "3.4.3 Derived Types and References" in XMI Spec. , v 2 XMI 1.3 open
XMI21-19 Are xlinks legal? XMI 1.3 open
XMI21-12 XMI 2.0 issue: Proxies and Multiplicities XMI 1.3 open
XMI21-15 Incosistent XMI namespace URL XMI 1.3 open
XMI21-14 More type safety in generated schemas XMI 1.3 open
XMI21-13 Schema production rule 4d clarification request XMI 1.3 open
XMI21-18 tag value constraint in chapter 1.11.2 XMI 2.0 open
XMI21-17 Schema production rule for 'ClassReferences' (4.e) XMI 1.3 open
XMI21-16 The ClassAttribRef Production Rule (4i) can be enhanced XMI 2.0 open
XMI21-24 How to serialize values of the PrimitiveType UnlimitedNatural XMI 2.1 open
XMI21-23 Page: 60 XMI 2.1 open
XMI21-22 Page: 58 XMI 2.1 open
XMI21-21 How are attributes and compositions inherited? XMI 2.0 open

Issues Descriptions

Revise 7.13.2 XMI Document Exchange with Multiple Tools

  • Key: XMI21-4
  • Legacy Issue Number: 8669
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This applies to XMI 2.1 - ptc/04-06-11.

    The above section proposes a scheme that does not hold water. In particular it does not provide a means for the original tool to recognize its own objects. For this a simple extension is neded that assigns extenderIds at the same time as uuids. In addition it is also important that the exporterId is set.

    Proposed resolution: see ad/2005-03-06 for a change-barred proposed text.

  • Reported: XMI 2.0 — Thu, 31 Mar 2005 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

section 8.2.1 on page 46 (editorial)

  • Key: XMI21-2
  • Legacy Issue Number: 7382
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    In section 8.2.1 on page 46, change the first three lines of rule
    4. ClassTypeDef from (Note mis-placed closing quote for "name"
    attribute)

    "<xsd:complexType name='" //Name of Class//
    ("mixed='true'")?
    "'>"

    to

    "<xsd:complexType name='" //Name of Class// "'"
    ("mixed='true'")?
    ">"

  • Reported: XMI 2.0 — Wed, 19 May 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

XMI 2.0 terminology

  • Key: XMI21-3
  • Legacy Issue Number: 7648
  • Status: open  
  • Source: Anonymous
  • Summary:

    I am reading through the XMI 2.0 "convenience document" ptc/04-06-11 and
    I am getting stuck trying to figure out the terminlogy. In particular,
    what precicely is a "reference," what is an "association end," and what
    is an "association role?" "Reference" and "association end" seem to be
    leftovers from MOF 1.4, while "association role" is maybe a leftover
    from UML 1.x. But, as far as I can tell these constructs do not exist
    any more in MOF 2, so some definitions for them are need. Are these
    suitable definitions?:

    Reference: A reference is a Property owned by a Class (ownedProperty)
    with isComposite=false and a type that is a subtype of Class.
    Association End: An association end is a Property owned by an
    Association (ownedEnd).
    Association Role: An association role is an association end.

    In section 7.8.4, there is a statement "For multi-valued Properties, no
    XML attributes are declared; each value is encoded as an XML element."
    However, the OMG-provided XMI 2.0 representations of the EMOF/CMOF
    models use attributes to represent multi-valued Properties that meet the
    definition of "Reference" above. This seems to be a contradiction. I
    assume that the XMI spec should say "For multi-valued Properties, no XML
    attributes are declared; each value is encoded as an XML element, unless
    the Property is a Reference."

  • Reported: XMI 2.0 — Fri, 13 Aug 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Mandatory Extensions when enforceMinimumMultiplicity is true

  • Key: XMI21-8
  • Legacy Issue Number: 7306
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    My base document is the MOF 2 XMI Final Adopted Specification,
    ptc/03-11-04.

    There is an issue with rule 4c, part of the XML Schema Production rules,
    on page 46.

    If either org.omg.xmi.enforceMinimumMultiplicity or org.omg.xmi.enforce-
    MaximumMultiplicity is true, then rule 4 places the 4b:ClassContents in
    an xsd:sequence element – and subelements are then decorated with
    minOccurs and maxOccurs attributes.

    However, rule 4c still emits the constant element,
    <xsd:element ref='xmi:extension'/>

    Therefore, in this case, the extension element becomes mandatory, with
    an implicit multiplicity of 1..1. This needs to be changed to
    <xsd:element ref='xmi:extension' minOccurs='0' maxOccurs='unbounded'/>

  • Reported: XMI 2.0 — Thu, 6 May 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

section 8.2.1 on page 44 (editorial)

  • Key: XMI21-5
  • Legacy Issue Number: 7383
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    In section 8.2.1 on page 44, change rule 1g. XMIFixedAttribs from
    (missing end of tags on line 2 and 4, missing namespace tag on line 3)

    ( "<xsd:attribute ref='xmi:id'"
    "use='optional'>" |
    "<attribute name='" //Id attrib name// "'"
    "type='xsd:ID' use='optional'" )
    "<xsd:attributeGroup ref='xmi:ObjectAttribs'/>"

    to

    ( "<xsd:attribute ref='xmi:id'"
    "use='optional'/>" |
    "<xsd:attribute name='" //Id attrib name// "'"
    "type='xsd:ID' use='optional'/>" )
    "<xsd:attributeGroup ref='xmi:ObjectAttribs'/>"

  • Reported: XMI 2.0 — Wed, 19 May 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

XMI for TypeLibrary::Objects::Object is Unspecified

  • Key: XMI21-7
  • Legacy Issue Number: 6345
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    Issue for XMI for MOF 2

    The specification of XMI for MOF 2 does not describe handling of MOF's
    object type, which is a supertype of ordinary class types as well as data
    types. Particularly, it does not describe what XML results from the
    following small example. The whole model is this:

    In a package M there is one class X having one owned attribute named Y of
    type TypeLibrary::Objects::Object with multiplicity 1..1.

    Consider the following 4 instances of X:

    1. An instance of X having Y set to the second instance of X.
    2. An instance of X having Y set to the integer 3.
    3. An instance of X having Y set to the string "this UNICODE string".
    4. An instance of X having Y set to that same fourth instance of X.

    What would an XMI-based serialization of these four instances of X look
    like?

    What would an XML schema for the package M look like?

  • Reported: XMI 1.3 — Thu, 4 Sep 2003 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

ISSUE: XMI for MOF 2 does not reflect MOF 2 model

  • Key: XMI21-11
  • Legacy Issue Number: 6636
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    The XMI for MOF 2 Specification seems to have been written as if referring to a MOF 1 Specification. For example, it defines mappings and mapping parameters for AssociationEnd, which is not in MOF 2.

    Recommended Resolution: Restate the XMI rules and mapping parameters in terms of MOF 2 and UML 2.

  • Reported: XMI 1.3 — Thu, 20 Nov 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

ISSUE: XMI for MOF 2 should address models, not just metamodels

  • Key: XMI21-9
  • Legacy Issue Number: 6635
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    The XMI for MOF 2 specification has not been updated to reflect one of the key goals in the alignment of MOF 2 with UML 2, which is that XMI becomes applicable to UML class models in general rather than to MOF-based metamodels only.

    Recommended Resolution: Replace "metamodel" with "model" in most places within the XMI for MOF 2 specification. Also, in describing the mapping from classes, properties, etc. to XML, do not use wording that implies a restriction to a MOF context except where MOF is , such as for elements of the MOF Type Library.

  • Reported: XMI 1.3 — Thu, 20 Nov 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

section 8.2.1 on page 46 (editorial)

  • Key: XMI21-6
  • Legacy Issue Number: 7384
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    In section 8.2.1 on page 46, change the fourth and fifth line of
    rule 4. ClassTypeDef from (missing eod of tag '>')

    ( "<xsd:complexContent>"
    "<xsd:extension base='" 4a:ClassTypeName "'")?

    to

    ( "<xsd:complexContent>"
    "<xsd:extension base='" 4a:ClassTypeName "'>")?

  • Reported: XMI 2.0 — Wed, 19 May 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

section 7.10.2.2(.2) on page 23 (editorial)

  • Key: XMI21-1
  • Legacy Issue Number: 7381
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    I've posted these to the XMI 2.1 RTF before. Since these typos still
    exist in the MOF2XMI Final Adopted Spec (ptc/03-11-04), I figured I
    should send them again. As editorial issues, they were not assigned
    an official issue number.

    In section 7.10.2.2(.2) on page 23, the URN for the XMI namespace
    needs to be in lowercase, according to W3C. Thus, change

    xmlns:xlink="http://www.w3.org/1999/XLink"

    to

    xmlns:xlink="http://www.w3.org/1999/xlink"

  • Reported: XMI 2.0 — Wed, 19 May 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

XMI for MOF 2 defines tagged values

  • Key: XMI21-10
  • Legacy Issue Number: 6394
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    The XMI for MOF 2 specification defines several tagged values for adding
    data to a UML model that guide generation of an XML Schema and that guide
    document production. But these tags appear to be defined as if for MOF 1.
    To be appropriate for MOF 2 these must be defined using either an extension
    to the MOF or UML core models (as a package that adds to MOF and/or UML
    infrastructure) or they must be defined as a UML 2 profile. In either case,
    an official XML rendering of the model or profile is required. And given
    the big change from MOF 1, an example of such tags as they would appear in
    an XMI-based XML document of an example model would be very helpful.

  • Reported: XMI 1.3 — Thu, 30 Oct 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Remarks to chapter "3.4.3 Derived Types and References" in XMI Spec. , v 2

  • Key: XMI21-20
  • Legacy Issue Number: 6065
  • Status: open  
  • Source: Anonymous
  • Summary:

    Remarks to chapter "3.4.3 Derived Types and References" in XMI Spec. , v 2.0, S. 3-15
    There it says:

    "... An instance of Company can use xsi:type to
    indicate that its HQAddress is actually of type USAddress and includes a zipcode:
    <Company xmi:id="Company_1" name="Acme">
    <HQAddress xmi:type="USAddress" xmi:id="Address_1"
    Street="Side Street" City="Hometown" zipcode="90210"
    ... "
    The 'HQAdress'-Element has a 'xmi:type'-Attribute. Parsing this with Xerces 2.4.0 gives problems, since a 'xsi:type' Attribute is required. Derived types must be specified with the 'xsi:type'-Attibute. Maybe the line
    "... An instance of Company CAN use xsi:type ..."
    should be changed in
    " ... An instance of Company MUST use xsi:type ..."

  • Reported: XMI 1.3 — Wed, 13 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Are xlinks legal?

  • Key: XMI21-19
  • Legacy Issue Number: 6054
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    maybe this is just because of my ignorance, but I'm running into
    a problem trying to validate documents against an XMI based schema
    here, and it looks like the validator has a point.

    As usual, my base document is XMI 2.0, formal/03-05-02.

    Section 1.10.2 "Linking" describes the usage of XLink simple links
    and XPointers to link across documents.

    However, looking at the schema production rules (page 2-2 to 2-5,
    rules 4g:ClassAttListItems and 1g:XMIFixedAttribs, as well as the
    LinkAttribs attributeGroup in the Fixed Schema Declarations on
    page 2-10, the xlink:href is never declared as a legal attribute
    for complexTypes.

    Hence I see why the parser (Xerces-C, when requested to validate)
    complains about attempts to use XLinks in a document.

    I think it is paramount that documents validate against the schema.
    (Am I the first to attempt validation? Can't be.)

    I realize that there doesn't seem to be a schema for XLinks yet,
    so the short-term solution might be to allow the "normal" href
    attribute to contain an XPointer.

    As a minor nitpicking, page 1-23 gives the XLink namespace as
    "http://www.w3.org/1999/XLink", whereas the W3C recommendation
    for XLink uses "http://www.w3.org/1999/xlink" (note case).

  • Reported: XMI 1.3 — Wed, 13 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

XMI 2.0 issue: Proxies and Multiplicities

  • Key: XMI21-12
  • Legacy Issue Number: 5950
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    Doc references are based on formal/03-05-02.

    In a Schema that is produced by the XML Schema Production
    rules, enforcement of multiplicities is incompatible with
    the use of proxies.

    According to 1.10.1, page 1-21, "Elements act as a union,
    where they are either a definition or a proxy. Proxies use
    the LinkAttribs attribute group to define the link, and
    contain no nested elements."

    However, if the org.omg.xmi.enforceMinimumMultiplicity is
    true, then the generated schema does not allow the complex-
    Type's content to be empty, and so proxies cannot exist in
    an XML document.

    As a simple fix, the 4b:ClassContents could be wrapped into
    an additional choice element, as in

    <xsd:choice minOccurs="0">
    <xsd:sequence>
    4b:ClassContents
    </xsd:sequence>
    </xsd:choice>

    This would allow the element to be empty. However, in this
    form, an XML document that contained both link attributes
    and contents would still validate.

    A stronger solution would be to make a choice between a
    link element and contents, by removing the LinkAttribs from
    the ObjectAttribs attribute group and by, in rule set 4,
    defining something along the lines of

    <xsd:choice>
    <xsd:sequence>
    4b:ClassContents
    </xsd:sequence>
    <xsd:element name="href" type="xsd:string">
    <xsd:element name="idref" type="IDREF">
    </xsd:choice>

    This way, an element in a validating document could only be
    either a proxy or not.

    As a side note to this issue, there are obviously unpleasant
    side effects when org.omg.xmi.enforceMinimumMultiplicity is
    true and org.omg.xmi.element is false. org.omg.xmi.enforce-
    MinimumMultiplicity=true should have the same effect as
    if org.omg.xmi.element=true and org.omg.xmi.attribute=false.

  • Reported: XMI 1.3 — Thu, 12 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT


More type safety in generated schemas

  • Key: XMI21-14
  • Legacy Issue Number: 5981
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    Document refs are against formal/03-05-02.

    According to rule 4d of the Schema production rules on page 2-5,
    "The type is 'xsd:string' for simple attributes".

    I assume here that "simple attributes" refers to MOF primitive
    types (Boolean, Integer, Long, Float, Double, String).

    I wonder why xsd:string was used for all these primitive types,
    when perfectly suitable data types are predefined for XML Schemas:
    there's xsd:boolean, xsd:int, xsd:long, xsd:float and xsd:double
    that exactly match the data types used by MOF.

    I propose to make use of these existing types to strengthen the
    generated schema.

  • Reported: XMI 1.3 — Mon, 23 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Schema production rule 4d clarification request

  • Key: XMI21-13
  • Legacy Issue Number: 5975
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    Document refs are against formal/03-05-02.

    Maybe it's because I'm still struggling with the details
    of XML Schemas and MOF, but I'm confused with rule 4d of
    the XML Schema Production rules (EBNF on page 2-4, expla-
    nation on page 2-5).

    • According to the EBNF, a type='xmi:Any' is an output
      option, but according to the explanation, this option
      is never used.
    • The explanation goes, "The type is 'xsd:string' for simple
      attributes ..." It is not clear to me what constitutes a
      "simple" vs. "non-simple" attributes. I assume this refers
      to MOFs PrimitiveTypes, but in any case a clarification
      would be useful.
    • The explanation goes on, "The type is [...] part of the
      of the value of the org.omg.xmi.schemaType tag". Why does
      it say "part of"? What should be removed from the value?
    • There is also a question of precedence. I guess the
      intention is that the schemaType tag should take
      precedence over the "simple attribute" decision?
    • There is no "else:" What if the attribute is not simple,
      not an enumeration, and the schemaType tag is not set?
      (Or maybe that is not possible in MOF?)
  • Reported: XMI 1.3 — Mon, 23 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

tag value constraint in chapter 1.11.2

  • Key: XMI21-18
  • Legacy Issue Number: 6011
  • Status: open  
  • Source: TU Braunschweig ( Lorenz Däubler)
  • Summary:

    Schema Production Rule 4i says, if tag enforceMinimumMultiplicity is true, IDREF is required. But tag value constraint in chapter 1.11.2 says, that with the enforceMultiplicity tag, attributes must be serialized as elements.

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

Schema production rule for 'ClassReferences' (4.e)

  • Key: XMI21-17
  • Legacy Issue Number: 6010
  • Status: open  
  • Source: TU Braunschweig ( Lorenz Däubler)
  • Summary:

    The Schema production rule for 'ClassReferences' (4.e) does not conform with the Document Production Rule 'Reference Element' (4). In the Class References the linking attribues are missing

  • Reported: XMI 1.3 — Mon, 21 Jul 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The ClassAttribRef Production Rule (4i) can be enhanced

  • Key: XMI21-16
  • Legacy Issue Number: 6009
  • Status: open  
  • Source: TU Braunschweig ( Lorenz Däubler)
  • Summary:

    The ClassAttribRef Production Rule (4i) can be enhanced by adding a minLength/maxLength facette to the reference attribute. With this facette the cardinality can be constrained.

  • Reported: XMI 2.0 — Mon, 21 Jul 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

How to serialize values of the PrimitiveType UnlimitedNatural

  • Key: XMI21-24
  • Legacy Issue Number: 12407
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The XMI is not explicit as to how to serialize values of the PrimitiveType UnlimitedNatural. In practice, and in the normative metamodels for UML as well as MOF, the value ‘’ has been used to represent ‘unlimited’ (as opposed to the value ‘-1’ which was used at UML/MOF 1.x). Rule 2i in section 6.3 states: Use this production rule to serialize an attribute whose type is not an object and whose value can be represented by a string. Multi-valued attributes cannot be serialized as XML attributes. If the attribute’s type is one of the types defined by the XML Schema Part 2: Datatypes specification, serialize the value as specified in that specification. PROPOSED RESOLUTION Add the following sentence to the end of the above paragraph: “Unless specified otherwise, values of other types may be serialized as strings using any permitted visual notation for that type. This applies to values for the Primitive Type UnlimitedNatural, where unlimited is serialized, as well as displayed, as ‘’.

  • Reported: XMI 2.1 — Wed, 23 Apr 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page: 60

  • Key: XMI21-23
  • Legacy Issue Number: 9359
  • Status: open  
  • Source: Klocwork ( Adam Neal)
  • Summary:

    There are two typo's for element 2h:FeatureAttrib. >From Document: ------------------- 2h:FeatureAttrib ::= X2i:MIValueAttribute | 2jXMIReferenceAttribute ------------------- - X is misplaced for 2i element - missing colon for 2j element Should be: ------------------- 2h:FeatureAttrib ::= 2i:XMIValueAttribute | 2j:XMIReferenceAttribute -------------------

  • Reported: XMI 2.1 — Wed, 8 Feb 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page: 58

  • Key: XMI21-22
  • Legacy Issue Number: 9358
  • Status: open  
  • Source: Klocwork ( Adam Neal)
  • Summary:

    There are two issues in this section of the document pertaining to referencing elements which only exist in the specification for the previous version, formal/05-05-01 (which is a changebar version of formal/03-05-02). First issue: 1:Document references 2:ContentElements. Here, 2:ContentElements does not exist in the formal/05-09-01 specification. Second issue: 1a:XMI references 5j:Extension. Here, 5j:Extension does not exist in the formal/05-09-01 specification.

  • Reported: XMI 2.1 — Wed, 8 Feb 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

How are attributes and compositions inherited?

  • Key: XMI21-21
  • Legacy Issue Number: 7334
  • Status: open  
  • Source: None ( Arno Leist)
  • Summary:

    In my understanding of the XMI 2.0 spec, it is not clear about how attributes and compositions are inherited. On page 34 point 1.8.7 is stated, that for attributes and compositions copy-down inheritance is required. Contrarily is rule 4c on page 57, which states that only local attributes, references, and compositions are included if the org.omg.xmi.useSchemaExtensions is set to true.

  • Reported: XMI 2.0 — Wed, 12 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT