XML Metadata Interchange Avatar
  1. OMG Specification

XML Metadata Interchange — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
XMI26-6 Normative document references not found XMI 2.5.1 open
XMI24-181 Minor spelling mistakes XMI 2.5.1 open
XMI26-5 The processContent attribute should be "lax" in the official XMI.xsd XMI 2.5 open
XMI26-2 9.4.1 serialization of a composite property typed by a class XMI 2.5 open
XMI26-1 9.4.1 serialization of a null-valued property typed by an enumeration or primitive type XMI 2.5 open
XMI26-4 XMI spec lacks support for profiles XMI 2.5 open
XMI26-3 9.4.1 serialization of a property typed by a structured datatype XMI 2.5 open
XMI12-7 3.6.4 Inheritance Specification XMI 1.1 open
XMI12-11 XMI 1.2 Issue - Association elements with references XMI 1.1 open
XMI12-4 DTD's (01-04-03) for XMI 1.2 XMI 1.1 open
XMI12-3 Invalid example model encoding XML XMI 1.1 open
XMI12-5 3.6.5 Attribute Specification XMI 1.1 open
XMI12-10 "3.6.1 Namespace Qualified XML Element Names" XMI 1.1 open
XMI12-8 General question to "3.6.4 Inheritance Specification" XMI 1.1 open
XMI12-2 Empty Fragment Identifier in Link XMI 1.1 open
XMI12-1 Urgent XMI 2.0 issue: XML Schema Production XMI 1.1 open
XMI12-6 3.6.4 Inheritance Specification XMI 1.1 open
XMI12-9 XMI issue - referenceless composition does not export components XMI 1.1 open
XMI12-43 Production by Package Extent Example in 00-12-05 XMI 1.1 open
XMI12-57 EmbeddedObject is misused XMI 1.1 open
XMI12-14 Problem with namespaces XMI 1.1 open
XMI12-18 MOF structured types missing from XMI 1.2 XMI 1.1 open
XMI12-20 XMI issue - xmi.exporterId inconsistently used and undefined XMI 1.1 open
XMI12-26 Unclear URI format XMI 1.1 open
XMI12-28 XMI: No way to specify the meta-meta-metamodel XMI 1.1 open
XMI12-30 Tool interchange recommendation insufficient (major) XMI 1.1 open
XMI12-34 Specification addresses only generation not consumption (medium) XMI 1.1 open
XMI12-40 Section 5.3 still uses old datatypes XMI 1.1 open
XMI12-45 UML: Using public identifiers to denote DTDs XMI 1.1 open
XMI12-42 Include derived attributes and references in rule 6d in DTD production XMI 1.1 open
XMI12-47 Inconsistencies for classifier-level Attributes XMI 1.1 open
XMI12-48 Anomalies with References and ordered Associations. XMI 1.1 open
XMI12-53 Include Derived Attributes and References of Derived Associations XMI 1.1 open
XMI12-54 EBNF incomplete for Attributes with complex types XMI 1.1 open
XMI12-55 Garbled descriptions in ObjectAsElement (page 9-204) XMI 1.1 open
XMI12-52 Minor bug / typo in handling of References XMI 1.1 open
XMI12-60 How to represent a "null" for a Class-valued Attribute? XMI 1.1 open
XMI12-12 org.omg.xmi.enumerationUnprefix XMI 1.1 open
XMI12-15 XMI 1.2: Missing class scope in <7m:AttName>, pp. 6-6? XMI 1.1 open
XMI12-17 What IS this "General Datatype Mechanism" anyway? XMI 1.1 open
XMI12-23 Outmoded use of '|' as separator XMI 1.1 open
XMI12-21 Unclear software compliance - see also issues 3887 and 3889 XMI 1.1 open
XMI12-19 [xmi] xmi.label / xmi:label XMI 1.1 open
XMI12-27 XMI does not document the tag used to determine XML Namespace XMI 1.1 open
XMI12-25 Appendix A, Example , the example is not valid UML. XMI 1.1 open
XMI12-31 Nonexistent '' used (minor) XMI 1.1 open
XMI12-33 Effect of xmi.import is unclear (medium) XMI 1.1 open
XMI12-37 Directory structure for OMG standard XMI documents and DTDs XMI 1.1 open
XMI12-35 Problems with section on Linking XMI 1.1 open
XMI12-39 Incomplete rules for non-Primitive Datatype values XMI 1.1 open
XMI12-46 bi-directional References and redundancy XMI 1.1 open
XMI12-56 Association elements when no immediate references XMI 1.1 open
XMI12-58 DTD element content and multiplicities versus compliance. XMI 1.1 open
XMI12-13 propose a new tag to be applied to metamodels XMI 1.1 open
XMI12-16 What is the idea of encoding package contents? XMI 1.1 open
XMI12-22 OMG XML Metadata Interchange issue XMI 1.1 open
XMI12-24 UML conversion to MOF out of scope XMI 1.1 open
XMI12-29 Adoption of XLink specification (minor) XMI 1.1 open
XMI12-32 Example 4 in A.5 is obscure (minor) XMI 1.1 open
XMI12-36 Clarify that references to external documents can be virtual (minor) XMI 1.1 open
XMI12-41 XMI document production rule 7c issue XMI 1.1 open
XMI12-38 Example in A.5 is misleading XMI 1.1 open
XMI12-44 Composition Association problems XMI 1.1 open
XMI12-49 XML attribute encoding of values underspecified XMI 1.1 open
XMI12-50 Reconsider XML attribute encoding of values in XMI 1.1 XMI 1.1 open
XMI12-51 Encoding of strings and characters in XMI documents XMI 1.1 open
XMI12-59 Document production rules for "un-Referenced" Associations. XMI 1.1 open
XMI12-61 DTD rules unclear for attributes of subclasses. XMI 1.1 open
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
XMI12-64 Miss-stated XMI compliance points. XMI 1.1 open
XMI12-67 The "complete" approach to XMI data types must be optional XMI 1.1 open
XMI12-62 "Inputs" that define an XMI metadata interchange format. XMI 1.1 open
XMI12-69 Bug in pseudo-code for PackageDTD XMI 1.1 open
XMI12-76 XMI.reference suppression XMI 1.1 open
XMI12-71 Editorial: remove unnecessary hitorical references. XMI 1.1 open
XMI12-82 Example C Multiplicity XMI 1.1 open
XMI12-74 XMI Tags XMI 1.1 open
XMI12-85 Usage of XMI for GIS ISO 19118/TC211 XMI 1.1 open
XMI12-90 AssociationEnds without references XMI 1.1 open
XMI12-86 XMI cross-version compatibility XMI 1.1 open
XMI21-3 XMI 2.0 terminology XMI 2.0 open
XMI21-7 XMI for TypeLibrary::Objects::Object is Unspecified XMI 1.3 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
XMI12-63 XMI MOF Subset" optional compliance point. XMI 1.1 open
XMI12-66 Editorial: Fix up the cross-references. XMI 1.1 open
XMI12-68 DTD generation rules for composed Packages. XMI 1.1 open
XMI12-70 Section 6.12 needs rewriting. XMI 1.1 open
XMI12-72 DTD production clarifications for nested Packages XMI 1.1 open
XMI12-83 QName for XML attribute values XMI 1.1 open
XMI12-80 Containment as links XMI 1.1 open
XMI12-77 Allow suppression of reference serialization XMI 1.1 open
XMI12-79 XMI.content declaration XMI 1.1 open
XMI12-75 Status of pseudo-code in Chapter 7 XMI 1.1 open
XMI12-84 Appendix C example XMI 1.1 open
XMI12-89 Documentation of References in section 6.6 XMI 1.1 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-9 ISSUE: XMI for MOF 2 should address models, not just metamodels XMI 1.3 open
XMI21-11 ISSUE: XMI for MOF 2 does not reflect MOF 2 model XMI 1.3 open
XMI12-65 DTD generation for DataTypes with typecode.kind == tk_alias XMI 1.1 open
XMI12-73 The UML and MOF DTD appendices are poor examples. XMI 1.1 open
XMI12-81 Additional examples XMI 1.1 open
XMI12-78 Specifying Attributes vs Elements XMI 1.1 open
XMI12-91 Typo in applicability scenarios XMI 1.1 open
XMI12-92 Reference to deleted text on fully qualified names. XMI 1.1 open
XMI12-88 Examples with references confusing. XMI 1.1 open
XMI12-87 Open DTD content for subclasses XMI 1.1 open
XMI12-93 Element Identification Attributes XMI 1.1 open
XMI21-10 XMI for MOF 2 defines tagged values XMI 1.3 open
XMI11-101 Examples are instances of non-MOF metamodels (medium) XMI 1.0 open
XMI11-100 MOF and UML tagged value alignment. XMI 1.0 open
XMI13-3 XMI Schema Issue - representation for Associations XMI 1.2 open
XMI13-1 More use of schema structural constraints XMI 1.2 open
XMI13-2 Introduce extenderVersion XMI 1.2 open
XMI24-9 [MOF2] and [UML2] not further specified in the document XMI 2.4 open
XMI24-6 Revise XMI examples in 9.4 XMI 2.4 open
XMI24-10 Canonical XMI (ptc/2013-08-28): need rules for generating xmi:id and xmi:uuid for auxiliary XML elements XMI 2.4 open
XMI24-7 No XML-Schema for UML-XMI XMI 2.4 open
XMI24-8 MOF/XMI schemaType is incorrectly defined relative to its use and its scope is too restrictive XMI 2.4 open
XMI24-5 XMI should include a name transformation algorithm to convert names e.g. replace spaces by ‘_’ XMI 2.4 open
XMI24-4 Name transformation XMI 2.4 open
XMI24-3 XMI issue - root elements for XMI Schemas XMI 2.4 open
XMI24-1 Which type of name should be used XMI 2.0 open
XMI24-2 metamodel for XML Schema XMI 2.1 open
XMI21-24 How to serialize values of the PrimitiveType UnlimitedNatural XMI 2.1 open
XMI21-22 Page: 58 XMI 2.1 open
XMI21-21 How are attributes and compositions inherited? XMI 2.0 open
XMI21-19 Are xlinks legal? XMI 1.3 open
XMI21-23 Page: 60 XMI 2.1 open
XMI21-20 Remarks to chapter "3.4.3 Derived Types and References" in XMI Spec. , v 2 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-15 Incosistent XMI namespace URL XMI 1.3 open
XMI21-12 XMI 2.0 issue: Proxies and Multiplicities 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
XMI24-124 Extension is only referenced from 1a. However it certainly should be valid within an XMIObjectElement. XMI 2.4 open

Issues Descriptions

Normative document references not found


Minor spelling mistakes

  • Key: XMI24-181
  • Status: open  
  • Source: Eurostep Group AB ( Phil Spiby)
  • Summary:

    Section B.2

    • bullet 2 - smi:XMI should be xmi:XMI
    • bullet 6 - smi:type should be xmi:type and smi:idref should be xmi:idref
      Section B.5.3
    • second bullet - xmi:idreg should be xmi:idref
  • Reported: XMI 2.5.1 — Fri, 3 May 2019 15:20 GMT
  • Updated: Tue, 7 May 2019 18:38 GMT

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

3.6.4 Inheritance Specification

  • Key: XMI12-7
  • Legacy Issue Number: 5548
  • Status: open  
  • Source: Anonymous
  • Summary:

    4) "3.6.4 Inheritance Specification" should go after "3.6.5 Attribute
    Specification" because uses attribute concepts explained in 3.6.5.

  • Reported: XMI 1.1 — Mon, 8 Jul 2002 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

XMI 1.2 Issue - Association elements with references

  • Key: XMI12-11
  • Legacy Issue Number: 5305
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    There are several problems related to the specification of Association
    elements (representing Links).

    1) At the moment Association elements are only generated in DTDs/Schemas for
    referenceless associations.
    This precludes the use of Association instances in XMI files to link
    existing/external objects: a technique I have certainly found useful even
    when those objects do have references. There seems to be little reason for
    not generating the Association elements.

    2) The description of DTD design principles in 3.6.6 refers to association
    roles. Presuming this is intended to mean association ends, the text is not
    accurate since the element name generated is based on the reference name for
    the class which may differ from the association end name.

    3) Section 3.6 does not mention the creation of Association elements even
    for the existing referenceless Association case.

    4) The DTD and document generation rules for Association elements are
    unnecessarily heavyweight and inconsistent with the treatment of references
    on classes. For example it does not make sense for an AssociationEnd element
    to have the fixed xmi attributes; and it should be possible to dispense with
    them completely: letting an Association element refer to the linked elements
    using XML attributes. e.g. for association A with ends b and c, a link could
    be represented as follows (b1 and c1 are xmi.id's): <A b=b1 c=c1 />).

  • Reported: XMI 1.1 — Fri, 17 May 2002 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

DTD's (01-04-03) for XMI 1.2

  • Key: XMI12-4
  • Legacy Issue Number: 5883
  • Status: open  
  • Source: Eurostep AB ( Robert Noack)
  • Summary:

    The DTD's (01-04-03) for XMI 1.2 does not correspond to the specification of the xmi.version attribute (section 3.5.3). This makes it difficult to detect whether XMI 1.1 or 1.2 was used to export a UML model.

  • Reported: XMI 1.1 — Tue, 11 Mar 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Invalid example model encoding XML

  • Key: XMI12-3
  • Legacy Issue Number: 5770
  • Status: open  
  • Source: Telecommunity Consultants ( Phillip J. Eby)
  • Summary:

    The example model encoding XML is invalid, according to the DTD that appears above it. It shows <Envelope.toAddress> and <Envelope.fromAddress> tags which are not as described in the DTD, instead of containing nested <Address> tags, as it should.

    I found this confusing and in fact implemented code that handled parsing of erroneous constructs such as these because I thought I had misread the specification portions of the document. The error has been present since early versions of the XMI 1.1 specification.

  • Reported: XMI 1.1 — Sun, 1 Dec 2002 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

3.6.5 Attribute Specification

  • Key: XMI12-5
  • Legacy Issue Number: 5547
  • Status: open  
  • Source: Anonymous
  • Summary:

    3) In "3.6.5 Attribute Specification" on site 3.17.
    There is:
    <!ELEMENT a EMPTY >
    <!ATTLIST c.a xmi.value (enum1 | enum2 | .) #REQUIRED >

    Should be:
    <!ELEMENT c.a EMPTY >
    <!ATTLIST c.a xmi.value (enum1 | enum2 | .) #REQUIRED >

    The same error repeated on next site, where should be:
    <!ELEMENT c.a1 (#PCDATA | XMI.reference) *>
    <!ELEMENT c.a2 EMPTY >
    <!ATTLIST c.a2 xmi.value (true | false) #REQUIRED >

    The same error repeated on bottom direct before note, where should be:
    <!ELEMENT c.a EMPTY >
    <!ATTLIST c.a xmi.value (enum1 | enum2 | .) #REQUIRED d >

  • Reported: XMI 1.1 — Mon, 8 Jul 2002 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

"3.6.1 Namespace Qualified XML Element Names"

  • Key: XMI12-10
  • Legacy Issue Number: 5545
  • Status: open  
  • Source: Anonymous
  • Summary:

    1) In "3.6.1 Namespace Qualified XML Element Names" on site 3.15. An example
    uses inheritance, what is explained later, we should find another example.

  • Reported: XMI 1.1 — Mon, 8 Jul 2002 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

General question to "3.6.4 Inheritance Specification"

  • Key: XMI12-8
  • Legacy Issue Number: 5549
  • Status: open  
  • Source: Anonymous
  • Summary:

    General question to "3.6.4 Inheritance Specification": Why we declare all
    XML elements and XML attributes direct under class C0 declaration and not as
    parameter entity named like:

    <!ENTITY % C0.elem "C0.a0">
    <!ENTITY % C0.ref "C0.r0">
    <!ENTITY % C0.comp "C0.comp0">

    <!ENTITY % "C0.attr
    a0 CDATA #IMPLIED
    a1 CDATA #IMPLIED
    r0 CDATA #IMPLIED
    r1 CDATA #IMPLIED
    >

    and then:
    <!ELEMENT C0 (%C0.elem; | XMI.extension | %C0.ref; | %C0.comp*>
    <!ATTLIST C0
    %C0.attr;
    %XMI.element.att;
    %XMI.link.att;"
    >

    and for third subclass analogical:

    <!ELEMENT C3
    (%C0.elem; | %C1.elem; | %C2.elem | %C3.elem | XMI.extension |
    %C0.ref; | %C1.ref; | %C2.ref; | %C3.ref |
    %C0.comp | %C1.comp | %C2.comp | %C3.comp )*>

    • >
      <!ATTLIST C3
      %C0.attr;
      %C1.attr;
      %C2.attr;
      %C3.attr;
      %XMI.element.att;
      %XMI.link.att;"
      >

    Imagine how short would be the DTD of UML in such an format.

    It can be even shorter if we declare only one entity for all subelements
    like:

    <!ENTITY % C0.elem "C0.a0 | C0.r0 | C0.comp0 | XMI.extension">
    <!ENTITY % C1.elem "%C0.elem | ... my own elements without XMI.extension ...
    ">

    and than any n-subclass:

    <!ENTITY Cn "%C'n-1'.elem | ... my own elements without XMI.extension ...">
    <!ELEMENT Cn (%Cn.elem*>

    analogical implified form for ATTLIST is applicable, the last example could
    be:

    <!ENTITY Cn.attr "
    %C'n-1'.attr
    ... my own elements without %XMI.element.att; and %XMI.link.att; ... ">
    <!ATTLIST Cn
    %Cn.attr;
    >

  • Reported: XMI 1.1 — Mon, 8 Jul 2002 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Empty Fragment Identifier in Link

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

    This is a feature request for the XMI 2.1 RTF. (Does
    it have a mailing list? I'm crossposting to the XML
    Schema FTF in case that list is still alive.)

    My base document is the proposed available specification
    (ptc/02-06-03). (I did not find a later version.)

    Section 2.10.2, "Linking" specifies that "the URI
    reference must be of the form URI#id_value, where URI
    locates the XML file containing the XML element to link
    to, and id_value is the value of the XML element's XMI
    id attribute."

    I propose to add the feature that if the URI does not
    contain a fragment, then the link is to the outermost
    document element of the referenced file.

    This is a common use case, and allows linking to a
    document that was provided by someone else and not
    annotated with values for the optional xmi:id attribute.

    Therefore I propose to change the text in 2.10.2.1 (the
    "Using the XMI href attribute to locate an XMI id" sub-
    section):

    The URI reference must be of the form URI#id_value,
    where URI locates the XML file containing the XML
    element to link to, and id_value is the value of
    the XML element's XMI id attribute.

    to

    If the URI reference contains a fragment identifier
    (as in URI#id_value), then the URI locates an XML
    file, and the fragment identifier is used to locate
    an XML element with the fragment identifier as its
    XMI id attribute. If the URI reference does not
    contain a fragment identifier, then the outermost
    document element of the XML file is referenced.

    And to change, in 2.10.2.2 (the "Using an XLink simple
    link and XPointer bare name to locate an XMI id" sub-
    section) likewise:

    The value of xlink:href must again be a URI reference
    of the form URI#id_value. In this case, id_value is
    technically an XPointer bare name, but it looks just
    like the id_value for the XMI href attribute.

    to

    The value of xlink:href must again be a URI reference,
    which is evaluated as above. If the URI reference
    contains a fragment identifier, which is then
    technically an XPointer bare name, then the fragment
    identifier is used to locate an XML element with the
    fragment identifier as its XMI id attribute in the
    referenced XML file. If the URI reference does not
    contain a fragment identifier, then the outermost
    document element of the XML file is referenced.

  • Reported: XMI 1.1 — Thu, 22 May 2003 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Urgent XMI 2.0 issue: XML Schema Production

  • Key: XMI12-1
  • Legacy Issue Number: 5946
  • Status: open  
  • Source: Mercury Systems ( Jim Kulp)
  • Summary:

    This is an urgent XMI 2.0 issue. All section and page numbers are against XMI 2.0 (formal/03-05-02).

    Section 1.11 (page 1-26) introduces the org.omg.xmi.attribute and org.omg.xmi.element tags to drive schema and document production so that a MOF attribute becomes either an XML attribute or subelement (or both, if both tags are false).

    Chapter 3 (XML Document Production) explicitly evaluates these tags, in rule 3g (page 3-6) or rule 5 (page 3-9).

    However, chapter 2 (XML Schema Production) does not mention these tags at all, so they are ignored by the schema production rules. Therefore, an XML Schema that is produced using these rules always contains attribute and element definitions for each MOF attribute.

    To avoid this ambiguity, rules 4i and 4j should only be executed if org.omg.xmi.element is false. Rules 4d and 4e should only be executed if org.omg.xmi.attribute is false.

  • Reported: XMI 1.1 — Thu, 5 Jun 2003 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

3.6.4 Inheritance Specification

  • Key: XMI12-6
  • Legacy Issue Number: 5546
  • Status: open  
  • Source: Anonymous
  • Summary:

    2) In "3.6.4 Inheritance Specification" on site 3.17. What makes '%' in
    first line of element declaration?:
    <!ELEMENT % C1 (C0.a0 | C1.a1 | XMI.extension | C0.r0 | C1.r1 | C0.comp0 |
    C1.comp1)* >

  • Reported: XMI 1.1 — Mon, 8 Jul 2002 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

XMI issue - referenceless composition does not export components

  • Key: XMI12-9
  • Legacy Issue Number: 5300
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    It's possible to create a composition without having a Reference from the
    composite to the component. This is not obscure - a prime example of this is
    in UML: a ModelElement owns Tags but has no reference to them.
    The XMI production rules talk only about traversing composite references.

    Production by object containment is described as follows (section 5.3.1 of
    XMI 1.2 formal spec):
    "...XMI provides for XML document production by object containment. Given a
    composite object, XMI’s rules define the XML document, which represents the
    composite object and all the contained objects in the composition hierarchy
    of which it is the root."
    However the detailed rules will not achieve this if there is not a reference
    from composite to component.

    It gets worse - moving onto Production by Package Extension, the text in
    5.3.3 (bottom of p5-9) states:
    "Then, the SimplePackageClass is traversed. For each RefObject instance, the
    extent is examined. Any object that is not participating as a component in a
    composition link becomes the starting point for generating XML."

    Because the components we're talking about DO participate as a component in
    a composition link then these components will neither be starting points for
    generating XML nor exported as part of their composition (since they are not
    referred to by a reference).

  • Reported: XMI 1.1 — Thu, 16 May 2002 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Production by Package Extent Example in 00-12-05

  • Key: XMI12-43
  • Legacy Issue Number: 4212
  • Status: open  
  • Source: University of Ireland ( Ronan Conlon)
  • Summary:

    I was reading document 00-11-02, i.e. the XMI 1.1 specs, and I was a bit confused with the example of production by Package Extent on page 5-12.

    Should the line which says, "Similarly, the second Node in the NodeClass extent..." actually say, "...the second Net in the NetClass extent... "???

    There is no reference to PDT, one of the XMI.field values of the second Net object. Also, there seems to be no reference to NodeZ in the same XML, although NodeW is referenced again.

    Are these typos??? Sorry for nitpicking

  • Reported: XMI 1.1 — Thu, 22 Feb 2001 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

EmbeddedObject is misused

  • Key: XMI12-57
  • Legacy Issue Number: 3941
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    Assuming that issue 3822 is resolved as Dave Frankel suggests, we have a
    problem with the way that the EmbeddedObject production is used in other
    productions; e.g. MvAttributeContents and SvAttributeContents. In these
    cases (and possibly others), EmbeddedObject may generate embedded XML
    for
    a Class instance that needs to be referenced (via an xmi.idref)
    elsewhere
    in the document. But the EmbeddedObject production does not include the
    necessary "xmi.id" attribute to make this work.

    The easiest solution is to get rid of the EmbeddedObject production
    altogether, and replace all uses with ObjectAsElement.

  • Reported: XMI 1.1 — Mon, 9 Oct 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Problem with namespaces

  • Key: XMI12-14
  • Legacy Issue Number: 4847
  • Status: open  
  • Source: Anonymous
  • Summary:

    In any metamodel it is possible to specify an xmi namespace for a package using xmi.namespace tag, however the tag value seems to contain only the name of the namespace. How is the XMI writer supposed to know the URI of the namespace to be able to generate the namespace declaration into the XMI file?

    Concrete example:
    MOF has an xmi.namespace=Model tag attached to the Model package.
    Now suppose I have a MOF metamodel and want to serialize it into the XMI. The XMI writer needs to declare Model namespace like this:
    <XMI xmlns:Model="org.omg.mof.Model">
    Where is the XMI writer suppose to get the "org.omg.mof.Model" thing to generate it into the XMI? It is not explicitly specified anywhere in the MOF 1.4 model. Or can I generate just any URI I like?

  • Reported: XMI 1.1 — Wed, 20 Feb 2002 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

MOF structured types missing from XMI 1.2

  • Key: XMI12-18
  • Legacy Issue Number: 4817
  • Status: open  
  • Source: Anonymous
  • Summary:

    In keeping with the new MOF 1.4 specification, XMI 1.2 has removed all
    references to the "old" MOF type mechanism based on CORBA IDL types. A
    wonderful simplification of both MOF and XMI - no complaints!

    However, the new simplified MOF type concept has not been included.
    Specifically: there are no explicitly stated rules for encoding
    StructureType, AliasType or CollectionType.

    Probably linked to this is the fact that the pre-defined XMI elements
    XMI.field, XMI.sequence and XMI.seqItem are stated to be "...used only when
    required by the metamodel" [XMI 1.2, pp. 4-17]. And since they are never
    referenced by the rest of the specification, this apparently means "never".

    It is of course not difficult to connect these two peculiarities and deduce
    how the new MOF datatypes should be encoded, but it should really be stated
    explicitly.

  • Reported: XMI 1.1 — Thu, 31 Jan 2002 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

XMI issue - xmi.exporterId inconsistently used and undefined

  • Key: XMI12-20
  • Legacy Issue Number: 4790
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    xmi.exporterId inconsistently used and undefined
    Section 3.5.8 includes an element declaration for xmi.exporterId. However it
    is not included as a valid member of XMI.Documentation (the subject of the
    section) either in 3.5.8 or 4.4, nor the description at the start of 3.5.8.
    Although it is in production rule 3a.
    (Nor incidentally is it mentioned at all in the XMI Production of XML
    Schemas spec)

    Proposed Resolution
    Since there appears to be no use for xmi.exporterId delete it from 3.5.2,
    3.5.8, 4.4 and production rule 3a.

  • Reported: XMI 1.1 — Mon, 17 Dec 2001 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Unclear URI format

  • Key: XMI12-26
  • Legacy Issue Number: 4702
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    Section 3.5.1.2, bottom of p3-7 states "The xmi.id attribute value can be
    specified using a special URI form for XPointers defined in the XLink and
    XPointer working drafts." It's not clear what this 'special form' is (and in
    which working draft) and in any case XLink and XPointer are now
    Recommendation and Candidate Recommendation respectively.

  • Reported: XMI 1.1 — Tue, 20 Nov 2001 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

XMI: No way to specify the meta-meta-metamodel

  • Key: XMI12-28
  • Legacy Issue Number: 4646
  • Status: open  
  • Source: Anonymous
  • Summary:

    It seems for completeness sake, a "XMI.metametametamodel" element would need to be provided to specify the name and version of the metametametamodel (M3 model) being used. This is because XMI doesn't require that the M3 model be MOF. Even if the M3 model must be MOF, then it should still be possible to address which version of MOF is assumed.

    Below is an excerpt from the M0-level "Department" model from XMI 1.2, Appendix A.4. I have corrected it (by adding the required "version" attributes and the XML header) and expanded it include a reference to the metametamodel and metametametamodel (using a new "XMI.metametametamodel" element I am proposing):

    <?xml version='1.0'?>
    <XMI version="1.1" xmlns:Department="edu.university/Department">
    <XMI.header>
    <XMI.model name="Chemistry" version="1.0"/>
    <XMI.metamodel name="Department" version="1.0"/>
    <XMI.metametamodel name="UML" version="1.4"/>
    <XMI.metametametamodel name="Model" version="1.3"/>
    </XMI.header>
    <XMI.content>
    <Department:Department name="Chemistry">
    <Department:Department.instructors>
    <Department:Professor name="Dr. Smith" xmi.id="Smith"/>
    <Department:Postdoc name="Dr. Jones" xmi.id="Jones"/>
    <Department:Lecturer name="Dr. Visitor" xmi.id="Visitor"/>
    <Department:TeachingAssistant name="Fred" xmi.id="Fred"/>
    </Department:Department.instructors>
    </Department:Department>
    </XMI.content>
    </XMI>

    Basically, the new element would be defined just like

    {XMI.model}

    ,

    {XMI.metamodel}

    , and

    {XMI.metametamodel}

    .

  • Reported: XMI 1.1 — Sat, 27 Oct 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Tool interchange recommendation insufficient (major)

  • Key: XMI12-30
  • Legacy Issue Number: 4605
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    Section 3.10 has the following significant issues:

    • it treats xmi.uuids as interchangeable with xmi.externIDs. However the
      latter is not defined as globally unique in the same way as uuids;
    • it provides no mechanism to cope with the common case where tools do not
      support a globally unique id.
    • it requires that a tool knows whether a uuid was originally generated by
      it but provides no mechanism to allow this. For example, in section 3.10.3
      step 3, Tool1 needs to be able to recognize that the xmi.uuid "abcdefgh" was
      generated by it, yet "X012345678" was not. No information is provided in the
      file to allow this and it cannot be assumed that the format of the uuid can
      identify the tool that generated it.
    • there are inconsistencies between the text and the XMI. Specifically step
      2 should refer to xmi.uuid (instead of xmi.extenderID) of "X012345678" and
      step 4 should refer to xmi.uuid (instead of xmi.extenderID) of "qrstuvwxyz"
  • Reported: XMI 1.1 — Mon, 8 Oct 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Specification addresses only generation not consumption (medium)

  • Key: XMI12-34
  • Legacy Issue Number: 4599
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    The focus is exclusively on generation of XMI Documents and not on their
    consumption: how is the consuming program expected to process/interpret
    incoming XMI documents. Some specific questions:

    • in what order should the xmi.differences items be applied (compared to
      the rest of the document and with each other);
    • how should an incoming document be matched/reconciled with existing
      objects (in a repository) e.g. by uuid, xmi.id, some other nominated
      property? What impact should the version number of the metadata (as opposed
      to the metamodel) have?
    • to what extent should the absence of any links for a
      references/composition/association be taken as meaning it should be empty
      (and moreover that any existing links of that type for the object concerned
      should be deleted)
    • what if hrefs to another document do not uniquely identify an element
      (e.g. if xmi.label is used)?
      The answers to these questions also have an impact for generators since they
      will need to know the impact of various generation choices and be assured of
      some consistency. If consuming programs can do what they like with the XMI
      file then you lose interoperability.
  • Reported: XMI 1.1 — Mon, 8 Oct 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Section 5.3 still uses old datatypes

  • Key: XMI12-40
  • Legacy Issue Number: 4580
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    The example in section 5.3 still uses the MOF 1.3 DataType system. Specifically DateTimeType should be an instance of StructureType which has StructureFields of 'time' and 'timezone'; and TokenColor as an instance of EnumerationType with labels attribute having values for (at lest) 'blue', 'green' and 'red'.

  • Reported: XMI 1.1 — Sun, 23 Sep 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

UML: Using public identifiers to denote DTDs

  • Key: XMI12-45
  • Legacy Issue Number: 4215
  • Status: open  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    n order to exchange UML models by means of XMI, using an external DTD
    subset is common to avoid including the DTD into each document. Usage
    of SYSTEM identifiers should be avoided, since location of the DTD
    might vary between installations.

    To detect that a document is based on a well-known DTD (e.g. the XMI
    1.1 UML 1.4 DTD), a formal public identifier should be used. Since it
    is likely that OMG will need a number of public identifiers, it would
    be best if OMG could register an owner ID with ISO. With that, a
    DOCTYPE declaration could read

    <!DOCTYPE XMI PUBLIC "+//<omg>//DTD UML 1.4 XMI 1.1//EN">

    The procedure for registering public identifiers is defined in ISO
    9070; registration authority is ANSI (and delegated to
    GCA). Alternatively, an owner identifier can be derived through an ISO
    6523 organization identifier (authority is BSI), or using the Annex J
    IDN scheme.

  • Reported: XMI 1.1 — Thu, 1 Mar 2001 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Include derived attributes and references in rule 6d in DTD production

  • Key: XMI12-42
  • Legacy Issue Number: 4248
  • Status: open  
  • Source: International Business Machines ( Stephen Brodsky)
  • Summary:

    DTD production rule 6d states that DTD declarations are made for only
    non-derived attributes and references. This is inconsistent with the
    document production rules that include derived attributes.

    Resolution:
    Derived attributes and references in rule 6d are included in DTD
    production.

  • Reported: XMI 1.1 — Tue, 3 Apr 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Inconsistencies for classifier-level Attributes

  • Key: XMI12-47
  • Legacy Issue Number: 4086
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    There are significant inconsistencies in the handling of "classifier-level"
    Attributes by the XMI 1.1 spec.

    According to the DTD EBNF & pseudo-code, the <content> element should
    contain a <pkg-name> element for the outermost package that contains
    (some of) the classifier-level Attributes as XMI elements and/or XMI
    attributes. Nested Packages and their classifier-level Attributes
    are represented as nested XML elements withing the outer <pkg-name>
    element.

    By contrast, the document EBNF etcetera do not output a <pkg-name>
    element at all. Instead, all classifier-level Attribute values are
    output as content elements of the <xmi.content> node. In fact, the
    package nesting structure seems to disappear.

    In practice, the document production rules give a more convenient
    XML notation. It is convenient to have all of the classifier elements
    at the beginning of the contents, because they can be easily retrieved
    to create the "package instance" that holds the elements described
    by the rest of the document. By contrast, the DTD rules result in
    a document in which you have to process the entire document before
    you have the classifier-level Attribute values needed to create the
    "package instance" object.

    It should also be noted that the DTD rules and the document rules are
    variously unclear (or say nothing) about the handling of classifier-level
    Attributes that belong to super-type Packages and clustered Packages.

    My recommended fix would be to standardise on the document rules with
    the following change. The <xmi.content> element should contain a
    <pkgname> element for the top-level Package. This should have xml
    elements and attributes for all classifier-level Attributes in Classes
    it directly contains or that it inherits. It should also contain
    (recursively) elements for any clustered or nested Packages.

    This does four things:

    • It allows the consumer to tell what kind of Package to generate
      in all situations.
    • It puts values for all classifier-level Attributes at the front
      of the document.
    • It means that encoding of classifier-level and instance-level
      Attribute values is uniform.
    • It avoids the trap of having two or more MOF Attributes in
      a composed Package map to the same unqualified XML attribute
      name of the top <pkgname> element. [If it wasn't for this,
      we could collapse all classifier-level Attributes into the
      top level <pkgname> element.]
  • Reported: XMI 1.1 — Thu, 30 Nov 2000 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Anomalies with References and ordered Associations.

  • Key: XMI12-48
  • Legacy Issue Number: 4067
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    In trying to implement a consumers for ordered Associations, I've
    come across the following anomalies caused by References.

    Consider the following metamodel:

    package P {
    class C1

    { reference r1 to a1_e2 of A1; }

    ;

    class C2

    { reference r2 to a2_e1 of A2; reference r3 to a1_e1 of A1; }

    ;

    association A1

    { end set [0..*] of C1 a1_e1; end ordered set [0..*] of C2 a1_e2; }

    association A2

    { end set [0..*] of C1 a2_e1; end ordered set [0..*] of C2 a2_e2; }

    The first anomaly is with the "r2" Reference. Since this "refers to"
    the unordered end of an Association, the "value" of the Reference does
    not contain any ordering information. But, since the Association has a
    Reference, the links for the Association won't be output in an
    <association-name> element. In other words, the ordering information
    for the Association links will be lost. This is a serious problem. [For
    the record, there is nothing "wrong" with the meta-model either IMO]

    The second anomaly (or maybe it's just a "feature" ...) is with the
    References "r1" and "r3". The problem is that while the xmi entities
    generated for the "r1" Reference can be converted into links, this is
    not true for the reverse "r3" References. Clearly, if I try to use
    "add_links" on a C2 instance to set the "r3" Reference values, it is
    next to impossible to get the ordering of the A1 links correct. This
    makes the "r3" References next to useless ... as well as their being
    redundant.

    My preferred resolution to this issue would be to simply remove all
    handling of References from XMI, and represent all links in the
    <association-name> element.

  • Reported: XMI 1.1 — Tue, 21 Nov 2000 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Include Derived Attributes and References of Derived Associations

  • Key: XMI12-53
  • Legacy Issue Number: 3967
  • Status: open  
  • Source: International Business Machines ( Dan Chang)
  • Summary:

    Topic: Include Derived Attributes and References of Derived Associations in
    the XML DTD Production

    XMI 1.1 is not clear nor consistent with respect to inclusion of derived
    attributes and references of derived associations in the XML DTD
    production. As a result, some XMI RTF member believes they should be
    included, while some other member believes they should not be included.

    To be consistent with MOF, MOF to IDL Mapping, and JMI (Java Metadata API,
    a standard being developed under the Java Community Process), XMI should
    include derived attributes and references of derived associations in the
    XML DTD production.

    If not, XMI will limit its usefulness in addition to being inconsistent
    with MOF, MOF to IDL Mapping, and JMI. For example, suppose age is a
    derived attribute of class Person in some MOF-compliant metamodel. MOF to
    IDL Mapping allows one to access or interchange age in IDL or any
    programming language that has an IDL mapping. JMI allows one to access or
    interchange age in Java. If XMI does not allow one to access or interchange
    age in XML, then one would have to use something like XML Binding to Java
    in conjunction with JMI to do so. The same goes for references of derived
    associations.

    Therefore, if XMI does not allow inclusion of derived attributes and
    references of derived associations in the XML DTD production, one would
    have to use XMI to access or interchange most metadata information in XML
    and use something like XML Binding to Java with JMI to access or
    interchange derived metadata information in XML. This is simply
    unreasonable.

  • Reported: XMI 1.1 — Tue, 17 Oct 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

EBNF incomplete for Attributes with complex types

  • Key: XMI12-54
  • Legacy Issue Number: 4006
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The DTD EBNF for Attributes (e.g. production 4c on page 7-88) does not cover
    the more complex DataTypes; e.g. arrays, sequences, structs, unions, TypeCode,
    Any, Principal or object reference types. Similarly, the document EBNF for
    Attributes (production 8d on page 9-205) fails to say how the corresponding
    attibute values should be encoded.

  • Reported: XMI 1.1 — Mon, 30 Oct 2000 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Garbled descriptions in ObjectAsElement (page 9-204)

  • Key: XMI12-55
  • Legacy Issue Number: 3945
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    There are some sub-productions of ObjectAsElement whose meaning I cannot
    fathom. Specifically ElementAttributes may include a RefValueAtt that
    is described as follows:

    The XML attribute for reference contains the XML ID of each referenced
    object.

    Is this referring to the rendering of a Reference, or the rendering of
    an Attribute whose type is a Class? In either case, how does this
    square
    with the sub-productions of ObjectContents on the next page?

    Or does it mean something else?

  • Reported: XMI 1.1 — Tue, 10 Oct 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Minor bug / typo in handling of References

  • Key: XMI12-52
  • Legacy Issue Number: 4032
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    In the description of ReferenceAsElement in 9.5.5.1 on page 9-218, the
    spec says:

    "When the Reference's multiplicity has an upper bound greater than one
    ... a lower bound of zero, the reference is checked to see if any values
    exist."

    In reality, this check needs to happen >>always<<. Even in the [1..1] case,
    the value may not exist if you are generating XML for an incomplete model.

  • Reported: XMI 1.1 — Mon, 6 Nov 2000 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

How to represent a "null" for a Class-valued Attribute?

  • Key: XMI12-60
  • Legacy Issue Number: 3936
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    Suppose that my meta-model has a Class whose Attribute has another Class
    as its value. How do I represent this attribute in an XMI document when
    its value is a null object reference?

    According 9.5.4.2, the document should contain something like this:

    <pkg.cls.attr>
    <pkg.othercls xmi.idref="" />
    </pkg.cls.attr>

    Unfortunately, this doesn't work as the empty string is not legal as an
    IDREF value.

    As far as I can tell the 9.3 EBNF rules (e.g. production 7h) don't even
    consider the case where an Attribute's type is a Class.

  • Reported: XMI 1.1 — Thu, 5 Oct 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

org.omg.xmi.enumerationUnprefix

  • Key: XMI12-12
  • Legacy Issue Number: 4944
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    I have noticed that UML 1.4 metamodel heavily uses tag named
    org.omg.xmi.enumerationUnprefix. The UML 1.4 metamodel that is on the OMG
    server is in form of XMI 1.1. I could not find description of this tag in
    XMI 1.1 spec. Is this tag described somewhere? Why is it used? IMHO it only
    complicates the implementation of XMI readers/writers without any
    significant reason.

  • Reported: XMI 1.1 — Tue, 5 Mar 2002 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

XMI 1.2: Missing class scope in <7m:AttName>, pp. 6-6?

  • Key: XMI12-15
  • Legacy Issue Number: 4849
  • Status: open  
  • Source: HiQ ( Thomas Schaumburg)
  • Summary:

    Given a model "Acme" consisting of a class "Wiz", with a string-valued
    attribute "name", two types of model instance encoding are possible. Either
    this, using the <8a:ContentElement> production:

    <Acme:Wiz>
    <Acme:Wiz.name>foo</Acme:Wiz.name>
    </Acme:Wiz>

    or this, using the <7i:DataValueAtt> production:

    <Acme:Wiz name="foo"/>

    At best, the lack of a namespace and class scope identifier in the last
    example is inconsistent. But I suspect that the inclusion of a class scope
    in the former is intended to support instances implementing classes with an
    overlap in attribute names - e.g.:

    // The Acme model:
    class Base

    { attribute String name: }

    class Derived: Base

    { attribute String name; }

    (I'm not familiar enough with the MOF to know if this is allowed, but it
    appears to be the only possible rationale for scoping attribute names in the
    <8a:ContentElement> production)

    Using the <8a:ContentElement> production, a "Derived" instance is easily
    represented:

    <Acme:Derived>
    <Acme:Derived.name>foo</Acme:Derived.name>
    <Acme:Base.name>bar</Acme:Base.name>
    </Acme:Derived>

    However, using the <7i:DataValueAtt> production, things get ambiguous:

    <Acme:Derived name="foo"/>

    Which "name" value is being specified here? Base.name or Derived.name?

    If the XML atrribute names were scoped, this would not be a problem:

    <Acme:Derived Acme:Derived.name="foo" Acme:Base.name="bar"/>

  • Reported: XMI 1.1 — Wed, 20 Feb 2002 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

What IS this "General Datatype Mechanism" anyway?

  • Key: XMI12-17
  • Legacy Issue Number: 4819
  • Status: open  
  • Source: Anonymous
  • Summary:

    The XMI 1.2 spec - like its predecessor - extols the virtues of the "General
    Datatype mechanism" [XMI 1.2, pp. 3-30], showing e few examples of how
    useful it is.

    Maybe it's just me missing the point here: but what IS this mechanism, and
    where is it defined?

    I have read the examples given on page 3-30 about 20 times, but I still
    don't understand what is going on.

  • Reported: XMI 1.1 — Thu, 31 Jan 2002 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Outmoded use of '|' as separator

  • Key: XMI12-23
  • Legacy Issue Number: 4704
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    All uses of '|' as separator between URL and XPointer expression should be
    replaced by '#'.

  • Reported: XMI 1.1 — Tue, 20 Nov 2001 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Unclear software compliance - see also issues 3887 and 3889

  • Key: XMI12-21
  • Legacy Issue Number: 4705
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    Appendix C refers only to the conformance of XMI DTDs and Documents and
    provides no statements regarding what it means for a software
    implementation/tool to be conformant (except tangentially the first bullets
    in C.2.2 and C.2.3 under Usage Compliance). Note that references under Usage
    Compliance to early releases of many tools not supporting XML 1.0 are now
    outdated and statements about 'conforming to the XML recommendation' are too
    vague.

    Draft strawman resolution (needs to fully absorb myriad points in issue
    3887)
    ----------------------------
    Delete existing sections Usage Compliance under C.2.2 and C.2.3.

    Add new section C.3 Software Compliance Points
    -----------------------------------------
    To be "minimally XMI compliant for metamodel M" software must:

    • Produce XMI documents compliant with M (as defined in section C.2.2)
      representing its 'internal' elements through the rules of at least one of
      Containment or Package Extent.
    • Consume a XMI document compliant with M to create a new set of
      'internal' elements.
    • Be at least 'non-validating processor' (as defined in the XML
      Recommendation) with respect to a DTD compliant with M (as defined in
      section C.2.2).
    • Support at least simple hrefs using xmi.id of the form outlined in
      section 3.8.2.1.

    To be "fully XMI compliant for metamodel M" software must:

    • Produce XMI documents compliant with M (as defined in sections C.2.2 and
      C.2.3) representing its 'internal' elements through the rules of at least
      both of Containment or Package Extent.
    • Consume a XMI document compliant with M to create/update/delete an
      existing set of internal elements.
    • Completely process a set of xmi.differences
    • Be a 'validating processor' (as defined in the XML Recommendation) with
      respect to a DTD compliant with M (as defined in sections C.2.2 and C.2.3).
    • Support all the href options outlined in section 3.8.2.1.
    • Support tool interchange using the recommendation in section 3.10.
    • Support the exchange of model fragments as described in section 3.7.

    To be "minimally multi-metamodel XMI compliant" software must be minimally
    compliant with any metamodel M (as defined above) for any MOF-compliant
    metamodel. Additionally it must be able to generate a compliant DTD (as
    defined in section C.2.2) for such a metamodel and support at least the XMI
    MOF Subset outlined in section C.2.3.

    To be "fully multi-metamodel XMI compliant" software must be fully
    compliant with any metamodel M (as defined above) for any MOF-compliant
    metamodel. Additionally it must be able to generate a compliant DTD (as
    defined in sections C.2.2 and C.2.3) for such a metamodel

  • Reported: XMI 1.1 — Tue, 20 Nov 2001 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

[xmi] xmi.label / xmi:label

  • Key: XMI12-19
  • Legacy Issue Number: 4791
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    What is the intended purpose of the "xmi.label" attribute? The XMI
    specs. don't seem to give it any semantics. They just say that the user
    may put any value in the attribute.

    If my XMI processor that imports an XMI document and then serializes it
    back out with all the "xmi.label" attributes removed or perhaps randomly
    modified, would my processor be breaking any XMI conformance rules?

  • Reported: XMI 1.1 — Mon, 17 Dec 2001 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

XMI does not document the tag used to determine XML Namespace

  • Key: XMI12-27
  • Legacy Issue Number: 4652
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    We should aim to fix this at XMI 1.3. I think it belongs in 3.6.1 (para 2)
    as well as a (new) section that summarizes all the metamodel tags affecting
    XMI. Also I think 3.6.1 is misleading in implying it's up to the DTD
    Generator to use whatever namespace it likes and (potentially) ignore what's
    specified in the xmi.namespace tag.

  • Reported: XMI 1.1 — Wed, 31 Oct 2001 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Appendix A, Example , the example is not valid UML.

  • Key: XMI12-25
  • Legacy Issue Number: 4647
  • Status: open  
  • Source: Adaptive ( Gene Mutschler)
  • Summary:

    OMG received a query last week about XMI, which I answered. The response
    from the originator to my comments about his example were to the effect that
    he took them from the XMI spec. I looked at the XMI spec (Appendix A,
    Example 1) and found that the example is not valid UML.

    This is the second time that I'm aware of that someone has tried to use this
    example in the UML environment and encountered problems, so it clearly needs
    to be corrected.

  • Reported: XMI 1.1 — Mon, 29 Oct 2001 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Nonexistent '' used (minor)

  • Key: XMI12-31
  • Legacy Issue Number: 4604
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    '<ElementContent>' is used twice in rule 8a in section 6.2, but not defined
    anywhere: presumably it should be <ContentElement>.

    Adoption of XLink specification (minor)
    ---------------------------------------------
    There are several references (e.g. 3.5.10, XMI.metamodel) to the effect that
    "this element is expected to become a simple XLink when the XLinks
    specification becomes a recommendation of the W3C ". It has (in June 2001).

  • Reported: XMI 1.1 — Mon, 8 Oct 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Effect of xmi.import is unclear (medium)

  • Key: XMI12-33
  • Legacy Issue Number: 4601
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    The text just says that xmi.import 'identifies additional documents that are
    needed to process the current document' but does not say what effect/benefit
    the xmi.import has. For example, if one uses xmi.import to reference an
    external file, does this make all the elements available in the same xmi.id
    address space as the current document (hence it is an error if the imported
    document has an xmi.id clash)? The example in A.3 still uses hrefs to refer
    to an element (Department.xml#Instructor) in the imported file
    Department.xml which implies that the xmi.import is completely redundant
    since such an href can be used without the xmi.import being required.
    Moreover the usage of the xmi.name and xmi.version attributes are not made
    clear: is it a means of selecting a specific model from the referenced file?
    (The example does not use version). What is the impact of referencing a
    model compared to the other information that may be in the file? Can one
    only import a model? Does the xmi.import fail if the file does not contain
    the referred-to version of the Model?

  • Reported: XMI 1.1 — Mon, 8 Oct 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Directory structure for OMG standard XMI documents and DTDs

  • Key: XMI12-37
  • Legacy Issue Number: 4596
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    XMI documents for various OMG standards need to be made available
    on the OMG web server in a properly organised directory structure.
    The structure need to take account of different versions of the
    "domain" standard, different versions of XMI and different versions
    of MOF. It should cater for XMI documents and XMI DTDs, and
    possibly other representations of metamodels, interfaces and so on.

  • Reported: XMI 1.1 — Wed, 3 Oct 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Problems with section on Linking

  • Key: XMI12-35
  • Legacy Issue Number: 4598
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The section on Linking (3.8 in the XMI 1.2 RTF draft) has a number of
    problems. In general, it doesn't explain the alternative link methods
    clearly or give examples for all of them. It also seems to be offering
    lots of alternatives where there is no obvious need to do this. Some of
    the XLink/XPointer formats (e.g. "|descendant(...)" are now apparently
    obsolete. Finally, much of the text of 3.8.2.x is ungrammatical and/or
    generally hard to read.

  • Reported: XMI 1.1 — Mon, 8 Oct 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Incomplete rules for non-Primitive Datatype values

  • Key: XMI12-39
  • Legacy Issue Number: 4581
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    The EBNF for attributes does not make clear how the different MOF types are to be represented: it is clear for the PrimitiveTypes (via rule 7i) but not the others. For example, the use of xmi.field for StructureField values is only mentioned as part of the example in section 5. And it's not clear what difference there should be between multivalued attributes and those defined to be a CollectionType. And the nesting of DataTypes should also be addressed (e.g. a StructureField has as its datatype another Structure or CollectionType). Specifically 7h should make it clearer that XML Elements must be used for model attributes with non-Primitive datatype (except if the DataType is an Alias for a PrimitiveType?), as well as for multi-valued attributes. And 8e wrongly states that if not a PrimitiveDataType then "the <AttribContent> is a Class and the <AttribContent> is the Class object". There should be a clear table for all the MOF DataTypes as provided for the PrimitiveTYpes in 7i.

  • Reported: XMI 1.1 — Sun, 23 Sep 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

bi-directional References and redundancy

  • Key: XMI12-46
  • Legacy Issue Number: 4068
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    In addition to other anomalies with References, XMI's handling of
    bi-directional References puts redundant information into an XMI
    document. This redundancy adds unnecessary complexity for XMI
    document consumers.

    Discussion:

    For example, consider the following meta-model:

    package P {
    class C1

    { reference r1 to c2_end of A; }

    ;
    class C2

    { reference r2 to c1_end of A; }

    ;
    association A

    { end set [0..*] of C1 c1_end; end set [0..*] of C2 c2_end; }

    ;
    };

    An XMI document will represent a link between a C1 & C2 instance something
    like this:

    ...
    <P.C1 id="id1">
    <P1.C1.r1 idref="id2" />
    </P.C1>
    ...
    <P.C2 id="id2">
    <P1.C2.r2 idref="id1" />
    </P.C2>
    ...

    It may not be obvious, but when the References are bi-directional (i.e.
    on both ends of an Association), one of them is actually redundant.

    So what?

    The problem is that this introduces considerable complexity for an
    XMI document consumer, especially if the consumer is to protect itself
    against erroneous input.

    If the consumer assumes that the document is correct, it can statically
    choose to use either the "r1" or "r2" information to reconstruct the
    links. [The choice is more complex if the Association is ordered or one
    end is not Referenced.] Note that you can't simply create links for any
    References, since that will lead to duplicate links exceptions (or
    worse).

    The risk with this approach is that the consumer may lose information if
    the XMI document doesn't include elements for both References. For
    example, if the input document was produced by hand ...

    It is therefore better for the consumer not to assume that the document
    is correct. There are two options:

    1) Make sure that the "r1" and "r2" information is consistent. This
    is complex, and probably entails building in-memory copies of
    the links ... which may present scalability problems.

    2) Create links from the "r1" and "r2" information, catching and
    ignoring any duplicate link exceptions. This has a couple of
    problems:

    • If there are any inconsistencies, they won't be noticed.
    • It doesn't work for ordered Associations because if you
      add the link corresponding to a Reference that "refers to"
      the unordered end first, you will trash the ordering
      information.

    My preferred resolution to this issue would be to drop all XMI handling
    of References and represent the links in the <association-name> element.

  • Reported: XMI 1.1 — Tue, 21 Nov 2000 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Association elements when no immediate references

  • Key: XMI12-56
  • Legacy Issue Number: 3949
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    The XMI 1.1 Specification says an Association elements is generated only if
    there is no reference for the Association. But if the only references are
    defined on subclasses of related types, then links could be created between
    objects of the more general type, and those links cannot be passed via XMI
    because there is no reference on the general type. Therefore, the
    specification needs to state more precisely that an Association element is
    generated in a DTD if it has no reference whose container is equal to the
    type of the reference's exposedEnd.

  • Reported: XMI 1.1 — Fri, 13 Oct 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

DTD element content and multiplicities versus compliance.

  • Key: XMI12-58
  • Legacy Issue Number: 3901
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    In XMI 1.0, the DTD generation rules give a DTD that "tightly" specify
    the element content and multiplicities for Attributes according to the
    meta-model types and multiplicities. In XMI 1.1, the generation rules
    (at least the EBNF version) "loosen" the element content and
    multiplicity.

    The current XMI conformance rules have the effect that an XMI 1.0 DTD is
    not conformant to XMI 1.1. Is this intentional? Should 11.2.1 bullet
    point 4 be amended to account for different degrees of looseness?

    I argue that:

    1) Tighter DTDs should in general be compliant. A "tight" DTD that
    constrains element content to meta-data that matches a meta-model
    shouldn't be deemed non-compliant. The real point of XMI DTDs is
    to ensure supposed XMI documents contain meaningful metadata, as
    far as possible. It is counter-productive to make it "incorrect"
    for an XMI DTD generator to do a better job than the templates.

    2) A specific statement on backwards (in-)compatibility should be
    added to deal with the sub-cases where XMI 1.0 DTDs are over-
    constrained according to XMI 1.1; e.g. where the XMI 1.0 DTDs
    constrain the order of elements representing Attributes.

  • Reported: XMI 1.1 — Fri, 22 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

propose a new tag to be applied to metamodels

  • Key: XMI12-13
  • Legacy Issue Number: 4900
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    If we haven't already I think we need to propose a new tag to be applied to
    metamodels which will contain the URI for the namespace (as opposed to the
    namespace name which is given by the existing tag xmi.namespace).
    e.g. xmi.namespaceURI

    Two main reasons for doing this:
    a) automated generation of the DTD/schema for standards
    b) (and more importantly) allow instance documents to be generated with the
    right URI (which is obviously important) - without implementations having to
    hardcode a value or guess (which is what they have to do currently).

  • Reported: XMI 1.1 — Fri, 15 Feb 2002 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

What is the idea of encoding package contents?

  • Key: XMI12-16
  • Legacy Issue Number: 4818
  • Status: open  
  • Source: Anonymous
  • Summary:

    Reading through the XMI 1.2 spec, I notice that a peculiar DTD production is
    still there: the <9:PackageElementDef> on page 4-10.

    In short, this means that if I have say a very simplified UML metamodel,
    containing only the "Core" package, containing the single empty class
    "ModelElement", I will get the following DTD (fixed elements omitted):

    <!ELEMENT Uml:Core (Uml:ModelElement)*>
    <!ATTLIST Uml:Core
    %XMI.element.att;
    %XMI.link.att;
    >
    <!ELEMENT Uml:ModelElement EMPTY>
    <!ATTLIST Uml:ModelElement
    %XMI.element.att;
    %XMI.link.att;
    >

    My problem here is this: why would you ever want to use the Uml:Core package
    element? Since packages cannot be instantiated, there will never be a
    package instance to serialize..

    And, interestingly enough, the XML document production part of the
    specification never uses the package element either.

  • Reported: XMI 1.1 — Thu, 31 Jan 2002 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

OMG XML Metadata Interchange issue

  • Key: XMI12-22
  • Legacy Issue Number: 4721
  • Status: open  
  • Source: Anonymous
  • Summary:

    On page 394 (/400) of your whitepaper on XMI, version 1.1, you have falsely stated that "UML, the" is an "acronym: The Universal Modeling Language". It is in fact an acronym for the UNIFIED Modeling Language.

  • Reported: XMI 1.1 — Fri, 30 Nov 2001 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

UML conversion to MOF out of scope

  • Key: XMI12-24
  • Legacy Issue Number: 4703
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    Section 3.11 last paragraph refers to "The convention for converting UML
    classes to MOF datatypes". This is out of scope for XMI and belongs in UML
    Profile for MOF which has now been standardized by OMG (as part of EDOC).

  • Reported: XMI 1.1 — Tue, 20 Nov 2001 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Adoption of XLink specification (minor)

  • Key: XMI12-29
  • Legacy Issue Number: 4606
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    There are several references (e.g. 3.5.10, XMI.metamodel) to the effect that
    "this element is expected to become a simple XLink when the XLinks
    specification becomes a recommendation of the W3C ". It has (in June 2001).

  • Reported: XMI 1.1 — Mon, 8 Oct 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Example 4 in A.5 is obscure (minor)

  • Key: XMI12-32
  • Legacy Issue Number: 4603
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    Several points, the first 3 of which seem to concern the implicit use of a
    UML Profile which is not documented, and is not the UML Profile for CORBA
    (ad/00-05-07) which one might expect to be used for this:
    a) The diagram shows class Address with a stereotype of <<struct>> which is
    presumably part of a stereotype uses a UML Profile which is not indicated or
    documented in the CCM Spec referred to.
    b) Para 2 states that "The Base IDL metamodel should subclass MOF:DataType."
    which is not clear (a metamodel cannot be a subclass of a MOF Class). Later
    on the statement is made that "Since Address is a definition of a struct, it
    is an instance of the IDL metaclass StructDef" without any reasoning. This
    would require a mapping between the stereotype in the UML Profile and an IDL
    MOF model.
    c) It's not clear how the example model would be created: UML requires the
    'type' reference of an Attribute to refer to an instance of UML::Classifier.
    Does BaseIDL.StructDef inherit from UML::Classifier? With the use of a
    profile/stereotype one would end up with an instance of Class with an
    attached stereotype of <<struct>>. There's a lot that's not made clear.
    d) It would be far more useful to show a UML diagram for StructDef, or even
    a fragment of MOF XMI, than a block of DTD which is not adequate as a
    metamodel definition - especially in a specification that is supposed to
    be describing how to create DTDs from a metamodel.

  • Reported: XMI 1.1 — Mon, 8 Oct 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Clarify that references to external documents can be virtual (minor)

  • Key: XMI12-36
  • Legacy Issue Number: 4600
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    It should be clarified that hrefs do not have to refer to physical XMI
    documents that exist concurrently with the document to hand: the href could
    refer to elements in a database or repository so long as, when the first
    document is processed, the href can be navigated on demand to produce the
    referred-to document or element in XMI form.

  • Reported: XMI 1.1 — Mon, 8 Oct 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

XMI document production rule 7c issue

  • Key: XMI12-41
  • Legacy Issue Number: 4505
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    XMI document production rule 7c. states that "The element tag name is the name of the namespace followed by the element name. For class, package and association instances, this name is the name of the type instantiated." It is not totally clear that this permits only the single type that was used to create/instantiate the item, as opposed to another type to which it might conform: in particular the 'target' type of the reference.

  • Reported: XMI 1.1 — Fri, 17 Aug 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Example in A.5 is misleading

  • Key: XMI12-38
  • Legacy Issue Number: 4582
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    The example 4 in Appendix A.5 is confusing/misleading and out of scope since the XMI is shown not as generated from an instance of the MOF Model but from an amalgum of UML and IDL metamodels for which no XMI mapping is defined!

    Specifically the way that the Address <<struct>> is represented in both DTD and instances is NOT representative of how MOF StructureType datatypes are to be handled and this could mislead.

  • Reported: XMI 1.1 — Sun, 23 Sep 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Composition Association problems

  • Key: XMI12-44
  • Legacy Issue Number: 4134
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    According to the DTD generation EBNF, a Class element contains embedded
    <class-name> elements for Classes (and their subclasses) related as
    components via composite Associations. According to the DTD generation
    pseudo-code, the embedded elements are <reference-name> elements.
    Neither of these approaches work properly: both fail for some valid and
    meaningful meta-models.

    Discussion:

    The first approach can fail when there is more than one composite Association
    in the meta-model. For example:

    package P {
    class C1

    { ... };
    class C2 { ... }

    ;

    association A1

    { composite end single C1 the_c1; end set [0..*] of C2 the_c2; };

    association A2 { composite end single C1 the_c1; end set [0..*] of C2 the_c2; }

    ;
    };

    The resulting DTD for this meta-model does not allow you to tell if a
    a C1 instance that is related to a (component) C2 instance via an A1
    link or an A2 link.

    The second approach fails if there is no reference to the component
    Class from the composite Class. For example

    package P {
    class C1

    { // no reference to the_C2 of A1 }

    ;

    class C2

    { ... }

    ;

    association A1

    { composite end single C1 the_c1; end set [0..*] of C2 the_c2; }

    ;
    };

    Since there is no Reference from C1 to C2, there is no name for the
    element.

  • Reported: XMI 1.1 — Tue, 2 Jan 2001 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

XML attribute encoding of values underspecified

  • Key: XMI12-49
  • Legacy Issue Number: 4063
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    Assuming that XMI 1.2 retains XMI 1.1's optional encoding of DataType
    values as XML attributes, the specification needs to be fixed as follows:

    • It should list that DataTypes that can be encoded in two ways,
      how they are encoded, and the meta-model and runtime contexts under
      which this is legal.
    • The spec should say how a decoder should deal with anomalies like
      the following:

    <some.attr xmi.value="1">1</some.attr>

    <someother.attr xmi.value="1">2</someother.attr>

    <multi.attr xmi.value="1" />
    <multi.attr>2</multi.attr>

    <string.attr xmi.value="hi">
    </string.attr>

    Which (if any) of the above is legal?

    • The spec should state explicitly that a decoder that does not
      look in both the xmi.value attribute and the content is not
      XMI 1.2 conformant. [Not that this helps much in practice :-(]
  • Reported: XMI 1.1 — Mon, 20 Nov 2000 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Reconsider XML attribute encoding of values in XMI 1.1

  • Key: XMI12-50
  • Legacy Issue Number: 4062
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    I want the XMI RTF to reconsider the XMI 1.1 change to the encoding
    of simple data type values. My experience and that of some others
    is that this makes implementation of XMI unnecessarily hard.

    Discussion:

    In XMI 1.0, the rules for encoding simple DataType values were
    relatively straightforward:

    • The value of an Attribute (whose type is a simple type) is
      represented as the text content of the Attribute's element,
      except for booleans and enums which are represented using
      the xmi.value attribute.
    • An embedded simple value (e.g. in a any, struct field, etc) is
      represented the same except that boolean and enum values are
      represented using the XMI.enum element.

    This is pretty straightforward ... apart from the inconsistent
    handling of boolean and enum.

    In XMI 1.1, the rules changed so that the XMI document producer
    could put values of simple DataTypes into the xmi.value attribute.
    The purported aim of this change was to allow more compact XMI
    documents to be generated. [I woould argue this is a bad reason
    for this change. Standard text compression algorithms would give
    ten-fold better compaction than tinkering with XMI encoding.]

    Unfortunately, this change has some consequences that were not
    apparent at the time:

    1) The rules for encoding values of Attributes got more complex.
    For example, with character and string values, you apparently
    need to see if the value contains 'problem' characters before
    deciding whether to encode them as attributes or elements.

    [It does not help that the XMI 1.1 does not mention this. It
    doesn't even bother even list the DataTypes that could be
    encoded as XMI attributes!]

    2) The rules for decoding values are similarly complex. Indeed
    more so, since the decoder cannot predict what choices the
    encoder made.

    3) XMI 1.1 value encoding is apparently problematical for XMI
    consumers that are implemented using XSLT. It has been
    reported that having to look for an Attribute value in
    two places is a serious problem.

    [The counter argument that XMI was not designed to be used
    with XSL is bogus IMO. We should be supporting a wide spectrum
    of modes of use for XMI. Besides, the XMI 1.1 spec specificly
    mentions XSL in 4.3.6 with the implication that it is, or
    will be supported!]

    4) Having to look in two places will be problematical for conformance
    of hand-built XMI consumers. A hand built consumer will typically
    be tested against one XMI producer which makes one set of choices
    on encoding Attributes. If the consumer encounters an XMI document
    generated by different producer software, the chances are that it
    will break.

    These problems – particularly 3) and 4) – are sufficiently serious
    that we should review the decision that XMI 1.1 made to allow simple
    DataType values to be expressed in two ways.

  • Reported: XMI 1.1 — Mon, 20 Nov 2000 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Encoding of strings and characters in XMI documents

  • Key: XMI12-51
  • Legacy Issue Number: 4046
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The document production rules for encoding of strings and characters (9.5.9.23
    & 9.5.9.24) need to be clarified.

    They need to say how to encode significant whitespace characters so that they
    don't get mangled by XML document builders and parsers. Leading and trailing
    whitespace are particularly worrisome. One possible solution is surround the
    entire character or string value with matching quotes, and say that anything
    outside of the quotes is significant.

    They also need to say that characters and strings are encoded using ISO-10646
    (as per 3.1.5).

  • Reported: XMI 1.1 — Wed, 15 Nov 2000 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Document production rules for "un-Referenced" Associations.

  • Key: XMI12-59
  • Legacy Issue Number: 3942
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The EBNF for an "un-referenced" Association on page 9-206 says that it
    should be represented as follows:

    <...assocname>
    <...assocname.end1name>
    <...class1name xmi.idref="..." />
    </...assocname.end1name>
    <...assocname.end2name>
    <...class2name xmi.idref="..." />
    </...assocname.end2name>
    ...
    </...assocname>

    This does not conform to the DTD generated by production 11 on page
    7-93.

  • Reported: XMI 1.1 — Mon, 9 Oct 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

DTD rules unclear for attributes of subclasses.

  • Key: XMI12-61
  • Legacy Issue Number: 3890
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    This issue relates to the description of production 4c of the simple
    DTD ruleset on page 7-88. The text says

    "If the Class has subclasses, the element name of each of its
    subclasses
    is included in the declaration".

    This is ambiguous.

    Suppose that we are generating a DTD for a Package P1 that contains C1,
    and there is also Package P2 that imports clusters or inherits from P1
    and defines C2 as a subclass of C1. In each case, should the DTD
    generated for C1 in P1 include declarations for C2 attributes, or not?

    If yes, how does the generator find out what packages import / cluster
    / subtype P1? Also, how does XMI deal with addition of (say) a new
    importer of P1 after the DTD for P1 has been generated? (Does it
    break?)

    If no, how do I represent in XMI a link in an Association in P1 that
    has a C2 instance at one end?

    [I can guess some answers to these questions, but that isn't good
    enough.
    The spec should cover this Package composition issue here, or there
    should
    be a reference to some other part of the spec that deals with it.]

  • Reported: XMI 1.1 — Thu, 21 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT

Revise 7.13.2 XMI Document Exchange with Multiple Tools

  • Key: XMI21-4
  • Legacy Issue Number: 8669
  • Status: open  
  • Source: agnos.ai UK Ltd ( 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

Miss-stated XMI compliance points.

  • Key: XMI12-64
  • Legacy Issue Number: 3887
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    There are a number of problems with the XMI compliance statements:

    1) These statements all refer to specific XMI documents and XMI DTDs.
    There are no compliance statements for tools that generate DTDs and
    documents. Not even a mention that they might exist.

    2) XMI DTD compliance -

    • DTD generation assumes a MOF meta-model, yet there is not
      mention
      of input meta-models. Does this mean that all DTDs must be
      equivalent? (Obviously not ... but you could read the statements
      as requiring that.)
    • The third bullet point refers to "one of the rule sets in Chapter
      6". First, there are no rulesets in Chapter 6 (they are in
      Chapter
      7). Second, what happens if the rule sets give different
      expanded
      entities? Third, within one ruleset, does the EBNF or the
      pseudo-
      code take precedence in the event of a contradiction?
    • The third bullet includes "content multiplicities" as one of the
      items that must be identical in the expanded DTD. Yet the spec
      says that multiplicities are optional (and is inconsistent in the
      DTD rulesets; EBNF versus pseudo-code.)
    • When comparing a DTD against a reference DTD to determine if it
      is compliant, what else must be considered as an "input"? For
      instance, for a given meta-model, an XMI DTD generated using
      "fixed" data typing is clearly not equivalent to one generated
      using the "complete" approach. So how do you measure compliance?

    3) XMI document compliance -

    • No mention of input meta-data. Must all documents be the same?
    • How do you measure compliance when comparing two XMI documents
      produced with different data type mappings?

    4) Usage compliance -

    What is this statement trying to say? That a tool is XMI compliant
    if it complies to the XML recommendations?

    The bulleted point makes no sense as a "condition" under which XMI
    documents must be used ...

    5) XMI MOF subset optional compliance -

    Apparently, this is trying to make it "optional" to transmit complete
    MOF meta-models in an "XMI for MOF" document.

    • The XMI spec has no business making this sort of statement. Such
      statements are the sole business of the MOF spec ... and the MOF RTF.
    • These are stupid restrictions anyway. A MOF implementation that only
      supports the XMI MOF subset is not going to be able to exchange
      meta-models with one the supports the full MOF Model.

    6) XMI DTD optional compliance -

    • The wording is horribly vague; for example

    "XMI DTDs optionally conform to ... DTDs may support ... X .. or Y"

    A lawyer would have a field day with this!

    • The first bullet point says: "The definition of XML entities within DTDs
      are suggested ...". This is not a compliance point. It is a vague
      recommendation.
    • The second bullet says: "Either all incomplete rules or no incomplete
      rules should be supported". Then it says "Support for incomplete models
      is an optional addition to the mandatory support for complete models".

    a) Isn't this a contradiction? Doesn't the first sentence mean that
    support for complete models is optional? Or does it mean something
    else.

    b) Statements of non-optional functionality in this section are
    misplaced. The last part of the last statement belongs in 11.2.1

    • The third bullet could be read as meaning that DTDs don't need to
      support either mapping.
    • The fourth bullet doen't make sense. What does "role" mean?

    7) XMI Document optional compliance -

    In general, how does an XML document "support" something?

    • Bullet 1 is not a compliance point ... it is a weak recommendation.
    • Bullet 2 is meaningless, given that "production" and "processing" of
      XMI documents is apparently not covered by the earlier mandatory
      compliance points.
    • Bullets 3 & 4 leave open the interpretation that a compliant DTD
      may conform to neither option.
    • Bullet 5 – see Bullet 5 comments for DTD optional compliance

    8) Usage optional compliance -

    I don't think that the XMI spec has any business telling (optionally or
    not) an implementor what XML parser APIs to use. We shouldn't even be
    making recommendations. This is completely outside of the scope of the
    XMI spec.

  • Reported: XMI 1.1 — Thu, 21 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

The "complete" approach to XMI data types must be optional

  • Key: XMI12-67
  • Legacy Issue Number: 3883
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The XMI 1.1 RTF added material to section 6.5.18 to allow XMI DTDs
    to be defined (by the metamodeller) that use custom XML elements to
    represent data values. This is the so called "complete" approach,
    and is new in XMI 1.1.

    The description of the "complete" approach in section 6.5.18 and
    elsewhere seems to allow XMI DTDs to be created by hand that cannot
    be automatically generated from a meta-model. This means that the
    "complete" approach cannot be implemented by a MOF / XMI vendor
    without relying on proprietary extensions; e.g. a proprietary way
    of telling XMI generators for import and export tools how to
    encode / decode custom data strings.

    At a minimum the "complete" approach should be downgraded to an
    optional
    XMI compliance point in XMI 1.2 It could be argued that the material
    should not have added in the first place, since:

    1) adding significant new functionality is beyond the scope of
    an RTF, and

    2) incomplete specifications that rely on "magic" or on proprietary
    extensions are forbidden.

  • Reported: XMI 1.1 — Thu, 21 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

"Inputs" that define an XMI metadata interchange format.

  • Key: XMI12-62
  • Legacy Issue Number: 3896
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    In XMI 1.0, an XMI metadata interchange format (i.e. the XMI DTD and
    associated
    encoding rules) was determined solely by the metadata's MOF meta-model.

    In XMI 1.1, various additions were made that meant that this is no
    longer
    the case. An XMI 1.1 format now also depends significantly on other
    "input parameters". This includes:

    1) The XML namespace used to abbreviate element names

    2) The so called "domain datatype meta-model" and its relations to
    the main meta-model.

    3) Any custom rules for converting between data values and XML
    strings.

    4) Whether the format supports complete meta-models or incomplete
    meta-models.

    Since differences in any one of these parameters (or the MOF meta-model)
    result in non-interoperable XMI formats, it is crucial that
    meta-modellers
    define the parameter values, explicitly and clearly. Without this,
    implementation of "standard" XMI formats is a matter of guesswork.

    The XMI spec should say precisely what parameters effect the XMI
    mappings,
    and how they should be specified for a "standard" XMI format.

    The examples in the XMI spec, and particularly the Appendices should
    state
    what parameters have been used.

  • Reported: XMI 1.1 — Fri, 22 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Bug in pseudo-code for PackageDTD

  • Key: XMI12-69
  • Legacy Issue Number: 3867
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The pseudo-code for PackageDTD on p. 7-95 is inconsistent with the
    EBNF. The EBNF states the requirements for when to generate a
    CompositionDTD for an Association as follows: "The composition element
    is generated for each Reference in the Package which has an exposedEnd
    whose aggregation is composite." This means that if the one of the
    AssociationEnds of a Association has an composite aggregation and the
    referencing Reference's exposedEnd points to that same AssociationEnd,
    only then should the composition element (CompositionDTD) be created.

    The pseudo-code makes a similar, but weaker requirement. It requires
    only that an Association contains an AssociationEnd that has a composite
    aggregation. In fact, this would create duplicate declarations of the
    Reference XML element if the referencedEnd of a Reference has a
    composite aggregation, which is clearly wrong.

  • Reported: XMI 1.1 — Tue, 19 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

XMI.reference suppression

  • Key: XMI12-76
  • Legacy Issue Number: 3851
  • Status: open  
  • Source: International Business Machines ( Stephen Brodsky)
  • Summary:

    Allow the model to specify whether XMI.reference is allowed. Reduces size and simplifies DTDs for XML elements. Reduces mixed content from DTDs. Default would be to turn XMI.reference use off.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Editorial: remove unnecessary hitorical references.

  • Key: XMI12-71
  • Legacy Issue Number: 3879
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The XMI 1.1 specification contains numerous references to the way that
    things
    used to be in XMI 1.0, scattered throughout the document. For example,
    on page 6-55, we see:

    "xmi.uuidref: This attibute is no longer used in XMI 1.1. In XMI
    1.0, its
    use is described in the following paragraph".

    It is not normal for OMG specs to include this kind of material.
    Unless
    there is a good reason for retaining it, it should be removed.

    The only justification for this kind of material is if there is a
    converted effort to maintain backwards compatibility; e.g. the CORBA
    core describes multiple versions of the IIOP formats.

  • Reported: XMI 1.1 — Wed, 20 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Example C Multiplicity

  • Key: XMI12-82
  • Legacy Issue Number: 3845
  • Status: open  
  • Source: Anonymous
  • Summary:

    Clarify if example should show multiplicity as structure or object.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

XMI Tags

  • Key: XMI12-74
  • Legacy Issue Number: 3864
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The XMI 1.1 spec makes reference to a number of XMI specific Tags.
    Unfortunately, they are underspecified, and have names that do not
    conform to the MOF Tag naming conventions given in the MOF 1.3 spec
    in section 3.4.23.

    To fully specify a Tag, you need to define the following:

    1) The full tag name; e.g. "org.omg.xmi.data_type". (Note:
    spelling!)

    2) The metamodel class(es) that the Tag may be attached to; e.g.
    Model::Class

    3) The CORBA type and number of "values" (i.e. parameters) that a Tag
    instance may have.

    4) The meaning of the Tag in all contexts that it is meaningful.

    Finally, it would be a good idea if all of the XMI Tags were defined in
    a
    separate section ... possibly with cross references to the places where
    they are used in production sets.

  • Reported: XMI 1.1 — Tue, 19 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Usage of XMI for GIS ISO 19118/TC211

  • Key: XMI12-85
  • Legacy Issue Number: 3844
  • Status: open  
  • Source: SINTEF ( Arne Berre)
  • Summary:

    Identify and resolve issues for using XMI for data interchange of Geospatial System Interoperability data in ISO 19118/ ISO/TC211

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

AssociationEnds without references

  • Key: XMI12-90
  • Legacy Issue Number: 3839
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    Improvements to grammar for AssociationEnds that have no references.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

XMI cross-version compatibility

  • Key: XMI12-86
  • Legacy Issue Number: 3843
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    State the differences between versions and the modifications needed for a sender/receiver to handle previous versions.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 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

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

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 MOF Subset" optional compliance point.

  • Key: XMI12-63
  • Legacy Issue Number: 3889
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    This compliance point (11.3.1) is worrying. It means that a compliant
    XMI implementation may be capable of transmitting/receiving metadata
    described by a legal and meaningful MOF meta-model. For example, the
    MOF Model itself has a number of References where the Reference's name
    and the corresponding AssociationEnd have different names. Thus, XMI
    support for the MOF Model is optional. This is in violation of the
    XMI RFP requirements, and contradicts the intention of other parts of
    the spec.

    I suggest that the MOF and XMI RTFs jointly review the listed "optional"
    MOF features in 11.3.1 with a view to either making them mandatory in
    XMI, or removing them from the MOF Model in MOF 1.4.

  • Reported: XMI 1.1 — Thu, 21 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Editorial: Fix up the cross-references.

  • Key: XMI12-66
  • Legacy Issue Number: 3886
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    There are a number of missing and broken cross-references in
    ad/99-10-02.
    For example:

    • the Glossary refers to "MOF 1.x",
    • the Compliance chapter contains references to [SAX reference],
      [XMI reference] and so on.
    • the Compliance has a cross reference to "Section ." (sic) and
      to "rulesets in Section 6" which should be 7.

    And so on.

  • Reported: XMI 1.1 — Thu, 21 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

DTD generation rules for composed Packages.

  • Key: XMI12-68
  • Legacy Issue Number: 3882
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The DTD generation rules do not adequately cover Package importing,
    clustering and inheritance.

    1) There are no references to clustering anywhere in the DTD
    generation rules.

    2) There are allusions to the XMI.import element in Chapter 6 but no
    proper explanation of how it is used. Other points need to be
    clarified. For example, I can't work out how the DTDs allow you
    to represent an instance of metamodel Class which has an Attribute
    whose type is an imported Class.

    3) Package inheritance seems to be covered in the EBNF for DTD
    generation and the corresponding pseudo-code. However, the
    terminology is loose; e.g. refering to "Packages from which
    this Package is derived" without stating whether "derived"
    refers to the MOF::Model::Generalizes association.

  • Reported: XMI 1.1 — Thu, 21 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Section 6.12 needs rewriting.

  • Key: XMI12-70
  • Legacy Issue Number: 3878
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    Section 6.12 deals with the mapping of meta-model DataTypes to XMI.
    A key requirement of XMI was that XMI producer and consumer software
    could generated from a meta-model, or written to be "table driven" using
    the meta-model as input. Such software has to be compatible with any
    hand-built XMI software built according to the spec. The problem with
    Section 6.12 (as written) is that it seems to break this requirement.
    (See point 4 below).

    By saying "This general solution ...", section 6.12 seems to try to
    define a mechanism for tailoring XMI data type mappings. Unfortunately,
    it is woefully inadequate as a specification. It is unimplementable as
    written.

  • Reported: XMI 1.1 — Wed, 20 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

DTD production clarifications for nested Packages

  • Key: XMI12-72
  • Legacy Issue Number: 3865
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    When a Package contains another Package:

    a) If the containing Package contains an Association which is only
    referenced in the contained Package, should the containing Package treat
    it as an unreferenced or referenced Association?

    b) If the contained Package contains a child Class which inherits
    from a
    parent Class in the containing Package, should the DTD for the
    containing
    Package allow instances of the child Class?

  • Reported: XMI 1.1 — Tue, 19 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

QName for XML attribute values

  • Key: XMI12-83
  • Legacy Issue Number: 3846
  • Status: open  
  • Source: International Business Machines ( Stephen Brodsky)
  • Summary:

    XML Namespaces includes a Qname for XML attributes that allows cross-document references. Supplements XML element href cross-file links.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Containment as links

  • Key: XMI12-80
  • Legacy Issue Number: 3848
  • Status: open  
  • Source: International Business Machines ( Stephen Brodsky)
  • Summary:

    Requiring containment to use nested elements creates DTDs with large copydowns. Containment using attribute references would simplify DTDs as an option to be stated in the model.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Allow suppression of reference serialization

  • Key: XMI12-77
  • Legacy Issue Number: 3850
  • Status: open  
  • Source: International Business Machines ( Stephen Brodsky)
  • Summary:

    Allowing the suppression of reference serialization on one side of an association reduces redundancy of information. Allows one side of a cross-file relationship to be updated without requiring a write update to the other side. Declaration is made in the model.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

XMI.content declaration

  • Key: XMI12-79
  • Legacy Issue Number: 3852
  • Status: open  
  • Source: International Business Machines ( Stephen Brodsky)
  • Summary:

    Allow the content of XMI.content to be declared in the model instead of ANY for more readily validated and edited documents.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Status of pseudo-code in Chapter 7

  • Key: XMI12-75
  • Legacy Issue Number: 3863
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    It is not clear whether or not the pseudo-code and accompanying text in
    7.2.2, 7.2.3 and so on is intended to be normative.

    Chapter 7.1 states in the second paragraph:

    "... In XMI 1.1, these rule sets are stated formally in EBNF. The
    pseudo-code that was used to state these rules in XMI 1.0 remains
    for reference and explanatory value."

    This implies that the pseudo-code is non-normative. But it doesn't say
    so clearly.

    It is necessary to clarify this point in order to decide how to deal
    with the (numerous) inconsistencies between the EBNF and the
    pseudo-code.

  • Reported: XMI 1.1 — Tue, 19 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Appendix C example

  • Key: XMI12-84
  • Legacy Issue Number: 3841
  • Status: open  
  • Source: International Business Machines ( Stephen Brodsky)
  • Summary:

    Portions of the example are inconsistent

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Documentation of References in section 6.6

  • Key: XMI12-89
  • Legacy Issue Number: 3836
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Go through EBNF and be sure that each rule is documented in section 6.6. Accept.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 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

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

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

DTD generation for DataTypes with typecode.kind == tk_alias

  • Key: XMI12-65
  • Legacy Issue Number: 3884
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The pseudo-code on page 7-97 does not address this case.

  • Reported: XMI 1.1 — Thu, 21 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

The UML and MOF DTD appendices are poor examples.

  • Key: XMI12-73
  • Legacy Issue Number: 3881
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    Section 6.11 of the XMI 1.1 spec deals with the UML DTDs generated using
    XMI. Appendix A contains the complete UML 1.1 DTD. Appendix B contains
    the MOF 1.1 DTD.

    If this hasn't happened already, responsibility for these DTDs should
    be transferred to the their respective RTFs. The MOF and UML DTDs
    should be removed from the XMI spec.

    In my opinion, the UML and MOF DTDs are both too large to be good
    examples
    for XMI. We should come up with a set of smaller examples that
    illustrate
    how XMI works with complex meta-models, and how you use the various
    "bells
    and whistles" for tailoring the XMI mappings.

  • Reported: XMI 1.1 — Wed, 20 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Additional examples

  • Key: XMI12-81
  • Legacy Issue Number: 3847
  • Status: open  
  • Source: International Business Machines ( Stephen Brodsky)
  • Summary:

    More examples would clarify the specification.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Specifying Attributes vs Elements

  • Key: XMI12-78
  • Legacy Issue Number: 3849
  • Status: open  
  • Source: International Business Machines ( Stephen Brodsky)
  • Summary:

    Allow the model to specify serialization as XML attributes or XML elements. Removes duplicate declarations in DTDs (and Schemas when available). Requires issue 124 to support cross-doc links from XML attributes.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Typo in applicability scenarios

  • Key: XMI12-91
  • Legacy Issue Number: 3842
  • Status: open  
  • Source: Anonymous
  • Summary:

    "page 4-33, 4.3.2 Benefits of using XML, . The cost ...WYSYWIG editors. may be WYSIWYG ?"

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Reference to deleted text on fully qualified names.

  • Key: XMI12-92
  • Legacy Issue Number: 3827
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:


    106 resolved clarification minor Dave Frankel Reference to deleted text on fully qualified names. "Section 8.3.1 on p. 8-189, the second paragraph begins with: ""Note that all names in XMI are fully qualified, based on the MOF description of their metamodel."" This appears to contradict 6.6.1" Accept. The sentence will be dropped.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Examples with references confusing.

  • Key: XMI12-88
  • Legacy Issue Number: 3837
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    "The example for document serialization uses references with different names than the assocation ends, which is confusing (although legal)." Accept. Create simpler examples.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Open DTD content for subclasses

  • Key: XMI12-87
  • Legacy Issue Number: 3840
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    "Since DTDs are not extensible for subclasses, add the ANY element to containment content for future subclasses. See issue 126 for another solution."

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Element Identification Attributes

  • Key: XMI12-93
  • Legacy Issue Number: 2924
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    This is in regard to section 6.5.1 of 98-10-05 which has the following declaration at the beginning:

    <!ENTITY % XMI.element.att
    ’xmi.id ID #IMPLIED
    xmi.label CDATA #IMPLIED
    xmi.uuid CDATA #IMPLIED ’ >

    Since MOF 1.3 makes it mandatory that ref_mof_id return a unique id for a metaobject it seems that xmi.id ID should be required rather than implied.

  • Reported: XMI 1.1 — Thu, 7 Oct 1999 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

Examples are instances of non-MOF metamodels (medium)

  • Key: XMI11-101
  • Legacy Issue Number: 4602
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    Example 3 in A.4 purports to show instances of the Department model defined
    in the previous example (it says that "Department is considered the
    metamodel for Chemistry"). However Department is not a MOF-compliant
    metamodel (it is a fairly basic UML model). So XMI just does not apply!

    Similarly the XMI Document Instance in Example 4 in A.5 shows instance data
    for the Mail model which again is not a MOF-compliant metamodel.

  • Reported: XMI 1.0 — Mon, 8 Oct 2001 04:00 GMT
  • Updated: Sat, 7 Mar 2015 20:03 GMT

MOF and UML tagged value alignment.

  • Key: XMI11-100
  • Legacy Issue Number: 3835
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Question if both MOF and UML were defining the same tag values for initialValue. No change. This is a DTD initialValue which differs from UML's initial value.

  • Reported: XMI 1.0 — Wed, 13 Sep 2000 04:00 GMT
  • Updated: Sat, 7 Mar 2015 20:03 GMT

XMI Schema Issue - representation for Associations

  • Key: XMI13-3
  • Legacy Issue Number: 5304
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    Association elements are essential for referenceless associations, and can
    be very useful for creating links between existing objects for associations
    with references also (the latter should be optional controlled by a new
    tag).
    They are not mentioned at all in section 4 (Schema Design Principles)
    despite appearing as Rule Set 10 in 5.2.1. and Rule Set 7 in 5.3.1.

    Also the schema and document generation rules for Association elements are
    unnecessarily heavyweight and inconsistent with the treatment of references
    on classes. For example it does not make sense for an AssociationEnd element
    to have the fixed xmi attributes; and it should be possible to dispense with
    them completely: letting an Association element refer to the linked elements
    using XML attributes. e.g. for association A with ends b and c, a link could
    be represented as follows (b1 and c1 are xmi.id's): <A b=b1 c=c1 />).

  • Reported: XMI 1.2 — Fri, 17 May 2002 04:00 GMT
  • Updated: Sat, 7 Mar 2015 04:37 GMT

More use of schema structural constraints

  • Key: XMI13-1
  • Legacy Issue Number: 4638
  • Status: open  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    It is not clear why a separate XML construct has not been used for proxies
    (as described in 4.9) - rather than leaving an importer to check for the
    presence of link attributes. And providing no Schema-level enforceable
    constraint that proxies have no content (and vice versa).
    It would also help to have a stronger statement with respect to the use of
    XMI attributes as a 'cache' within proxies: to what extent must they be
    accurate and what options does an importer have if they are not? Does
    validation include checking the accuracy of cached attributes?
    4.6.2: Could Schema mechanisms be used to enforce the constraint that only
    one of href and idref is to be used?

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Updated: Sat, 7 Mar 2015 04:37 GMT

Introduce extenderVersion

  • Key: XMI13-2
  • Legacy Issue Number: 4642
  • Status: open  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    4.5.3: It would be useful to have an extenderVersion to match
    exporterVersion.

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Updated: Sat, 7 Mar 2015 04:37 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

Revise XMI examples in 9.4

  • Key: XMI24-6
  • Legacy Issue Number: 16341
  • Status: open  
  • Source: agnos.ai UK Ltd ( 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

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

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

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

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: agnos.ai UK Ltd ( 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: agnos.ai UK Ltd ( 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: agnos.ai UK Ltd ( 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

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

metamodel for XML Schema

  • Key: XMI24-2
  • Legacy Issue Number: 9637
  • Status: open  
  • Source: agnos.ai UK Ltd ( 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

How to serialize values of the PrimitiveType UnlimitedNatural

  • Key: XMI21-24
  • Legacy Issue Number: 12407
  • Status: open  
  • Source: agnos.ai UK Ltd ( 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: 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

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

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

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

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


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

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: agnos.ai UK Ltd ( 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