XML Metadata Interchange Avatar
  1. OMG Specification

XML Metadata Interchange — Open Issues

  • Acronym: XMI
  • Issues Count: 11
  • Description: Issues not resolved
Open Closed All
Issues not resolved

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

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

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

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

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