XML Metadata Interchange Avatar
  1. OMG Specification

XML Metadata Interchange — All Issues

  • Acronym: XMI
  • Issues Count: 65
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
XMI24-179 There's inconsistent use of spacing within quotes XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-178 The XMI.xsd has elements documentation and Documentation XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-177 There was an error in the resolution for issue 16889 XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-176 XML Schema for Associations XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-175 Fixed-point issues with the definition of default values for literals XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-174 Annex B XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-173 Annex A Page 73 XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-172 Section 9.2: Change “introduction” to “general.” XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-171 Section 10 XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-170 Section 7.12.4 XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-169 Section 7.11.6: change type=”CitiMember” to type=”CitiFeature” XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-168 Section 7.11.6 XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-167 Section 7.10.3 XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-166 Section 7.1, 3rd Paragraph XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-165 Section 3 Terms and Definitions XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-164 Section 7.1, 2nd Paragraph XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-163 Clause “Additional Information” is not needed. XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-161 Section 1 Scope: The statements are not for the Scope XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-160 Foreword Page vii: Title of ISO/IEC DIS 195058 is different. XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-159 Foreword Page vii XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-158 Title page i: f “MOF 2 XMI” in a title means “MOF to XMI”, it is not adequate XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-162 Section 2 Normative Reference: ISO/IEC standards were not specified XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-157 Title page i XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-156 Section 7.12 XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-155 Section 7.11.6: Move the example to an informative annex and delete the clause from its present position. XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-154 Section 6 - delete clause XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-153 Section 4 XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-152 Section 3 references XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-151 Section 2.3.1 XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-150 Section 2.2.2 XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-149 Section 2.1 - delete XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-148 Section1: The intended scope of the standard is unclear XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-147 The text should be reviewed for clarity and objectivity and then amended XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-146 Section B6 XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-145 An XMIReferenceElement cannot be used for serializing a composite property XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-144 Grammar for XML Schema - XMI XMI 2.1.1 XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-143 Grammar for XML Schema - XMI 2.4 Beta XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-142 No unambiguous way in XMI 2.4 UML 2.4 to serialize UML 2.4's StructuredActivityNode XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-141 The production rule for Associations should use sequence if the tag order is set to true XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-140 The rule for 6f has become corrupted XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-139 Rule 4f has an extraneous “>” XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-138 Rule 4f still uses the word “Reference” instead of Class-typed Property XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-137 In the XML Schema production rules the following in rule 4 is missing the option separator |: XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-136 attributes which apply to model elements and do not make sense at the XMI element level: XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-135 Section 6.5.: XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-134 Section 6.5.2 – nil=’true’ is only used if org.omg.xmi.includeNils = ‘true’ XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-133 Section 6.5.2 XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-132 Section 6, rule 2n XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-131 Section 4.11.3 needs better clarification XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-130 Section 4.5.3 states that the XMI element is ‘typically not present’ XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-129 Section 5.2.2: XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-128 Section 5.2.1, rule 5: XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-127 Section 5.2.1 rules 4d to 4e XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-126 Section 5.2.1, rule 4b/4c XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-125 The syntax in 6.2.1 allows URI in attributes, which is not mentioned or documented or used elsewhere XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-123 Specification makes frequent use of ‘attribute’ and ‘reference’ from MOF 1.4 XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-122 Production rule wrongly includes type on link elements XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-121 Change default of tag org.omg.xmi.contentType XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-120 Allow for ‘tight’ schemas XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-119 Missing rules for production of document by Extent or Object Containment XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-118 Unclear XSD production for external metamodels XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-117 Unclear order of property production XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-116 Deprecate/remove Chapter 7 XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-115 XMI does not allow the differentiation between "set to default" and "unset" states for properties XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-114 Use of xmi:type XMI 2.1.1 XMI 2.4 Resolved closed

Issues Descriptions

There's inconsistent use of spacing within quotes

  • Key: XMI24-179
  • Legacy Issue Number: 15615
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    There's inconsistent use of spacing within quotes. 3:Extension has spaces within its quoted optional attributes, but none of the other rules follow

    this convention.

  • Reported: XMI 2.1.1 — Tue, 21 Sep 2010 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    This is taken care of in the resolution to issue 15610 which rewrites the new rule 3..

  • Updated: Sat, 7 Mar 2015 21:39 GMT

The XMI.xsd has elements documentation and Documentation

  • Key: XMI24-178
  • Legacy Issue Number: 18968
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    The XMI.xsd has elements documentation and Documentation,

    The presence of Documentation as well as documentation is a bug in the XMI spec: there is no purpose in having two elements for the same purpose; and this is meant to be derived from the model which has the lowercase ‘d’.

    Proposed resolution: remove the Documentation element

  • Reported: XMI 2.1.1 — Wed, 25 Sep 2013 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Make the change as suggested.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

There was an error in the resolution for issue 16889

  • Key: XMI24-177
  • Legacy Issue Number: 18869
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    There was an error in the resolution for issue 16889 in ballot 2.

    That removed the following from rule 4e for XML schema production:

    "xsd:attributeGroup ref=’linkAttribs’"

    In fact the attribute group should not be removed but be enclosed in a xsd:complexType.

    Recommended fix:

    Replace last line:

    "xsd:attributeGroup ref='linkAttribs'")*

    By

    "<xsd:complexType>

    "xsd:attributeGroup ref='linkAttribs'

    </xsd:complexType>

    />" )*

  • Reported: XMI 2.1.1 — Tue, 13 Aug 2013 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Agreed. Accept in principle

  • Updated: Fri, 6 Mar 2015 23:16 GMT

XML Schema for Associations

  • Key: XMI24-176
  • Legacy Issue Number: 18379
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Rule 7 in section 8.2.1 deals with serialization of association instances (links).
    At the moment it uses <xsd:choice minOccurs=”0” maxOccurs=”unbounded”> for the ends. Though MOF is constrained to binary Associations, this would allow no, one, or even many ends to be serialized – which would never be valid.
    It would be a lot cleaner and more sensible to use <xsd:all> which requires exactly 2 ends.
    NB Rule 7 does not allow the use of XML attributes for the association ends, which would be allowed if the same reference were on an Object. I’m not convinced it would be useful (and it would not be Canonical XMI) but we should confirm that.

  • Reported: XMI 2.1.1 — Fri, 18 Jan 2013 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Make the change as suggested

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Fixed-point issues with the definition of default values for literals

  • Key: XMI24-175
  • Legacy Issue Number: 18286
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The definition of LiteralBoolean in the XMI for UML1.5 includes the following:

    <packagedElement xmi:type="uml:Class" xmi:id="LiteralBoolean" name="LiteralBoolean">

    …

    <ownedAttribute xmi:type="uml:Property" xmi:id="LiteralBoolean-value" name="value" visibility="public">

    …

    <defaultValue xmi:type="uml:LiteralBoolean" xmi:id="LiteralBoolean-value-_defaultValue"/>

    </ownedAttribute>

    …

    So the default value for value, which is correctly specified as false in the model, is specified by the absence of a value attribute as “the default value for LiteralBoolean::value” in the XMI. This is circular and ill-defined.

    One issue is with the XMI specification. The rule that property values should not be serialized when they have their default value should not apply when those properties are being used to define default values for themselves.

  • Reported: XMI 2.1.1 — Wed, 5 Dec 2012 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    This needs to be addressed.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Annex B

  • Key: XMI24-174
  • Legacy Issue Number: 17745
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex B is only described as an agreement for OMG. Delete Annex B.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Annex A Page 73


Section 9.2: Change “introduction” to “general.”

  • Key: XMI24-172
  • Legacy Issue Number: 17743
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Clause “introduction” explains informative sentences usually. However, this clause explains an overview of XML Document Production. Change “introduction” to “general.”

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Add the following bullet to the bottom of the list of bullets in clause 3:
    • [INFOSET] "XML Information Set (Second Edition)" W3C Recommendation 4
    February 2004 http://www.w3.org/TR/ 2004/REC-xml-infoset-20040204

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section 10

  • Key: XMI24-171
  • Legacy Issue Number: 17742
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue as XML Schema Inforset Model is informative. Delete it or move to an annex.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace the title of clause 9.2, which current reads:
    9.2 Introduction
    with:
    9.2 Overview

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section 7.12.4

  • Key: XMI24-170
  • Legacy Issue Number: 17741
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This sub sub clause describes informative example only. Move to an annex.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Partially resolved by resolution to Issue 17727
    Replace the title of clause 7.12.5, which current reads:
    7.12.5 Example
    with:
    7.12.5 Example of Differences
    Insert the following as a 1 sentence paragraph before the first paragraph of clause
    7.12.4:
    This sub clause is informative.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section 7.11.6: change type=”CitiMember” to type=”CitiFeature”

  • Key: XMI24-169
  • Legacy Issue Number: 17740
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There is an element named CitiMember typed CitiMember. However, there is no complex type named CitiMember in a diagram... Change type=”CitiMember” to type=”CitiFeature” .

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    In the second schema for CitiMember type change:
    <xsd:element name="cityMember" type="CityMember" minOccurs="0"
    maxOccurs="unbounded"/>
    to
    <xsd:element name="cityMember" type="CityFeature" minOccurs="0"
    maxOccurs="unbounded"/>

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section 7.11.6

  • Key: XMI24-168
  • Legacy Issue Number: 17739
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There is no element named Cambridge as described in the default XML schema for this model. Delete an element named Cambridge from a schema or add an element into a diagram.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    That element named "Cambridge" should be renamed to "GIS" the name of the
    metamodel. This element is the root element in the schema for the XMI document
    for a model instance of this meta model.
    Change title of Figure 17.3 from:
    GIS Cambridge model
    To
    GIS meta model
    In both occurrences in 17.11.6 change
    <xsd:element name="Cambridge">
    To:
    <xsd:element name="GIS">

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section 7.10.3

  • Key: XMI24-167
  • Legacy Issue Number: 17738
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This sub sub clause describes informative example only. Move to an annex.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Insert the following as a 1 sentence paragraph before the first paragraph of clause
    7.10.3:
    This sub clause is informative.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section 7.1, 3rd Paragraph

  • Key: XMI24-166
  • Legacy Issue Number: 17737
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There is a sentence “See Clause 10 for a complete description of how to generate XML schema using these tag value pairs.” However, there is no sentence related tag value pair in Clause 10. Delete this sentence “See Clause 10 ...”

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Delete the second to last sentence of para 3 of 7.1, which currently reads:
    "
    See Clause 10 for a complete description of how to generate XML schemas using
    these tag value pairs.
    "

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section 3 Terms and Definitions

  • Key: XMI24-165
  • Legacy Issue Number: 17736
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Other documents should be specified. Titles should be specified as referencing definitions.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace the last sentence in the second paragraph in clause 7.1, which current
    reads:
    That definition is presented in Chapter 7.
    with:
    That definition is presented in Clause 8
    Replace the last sentence in the secondparagraph of clause 7.1, which current
    reads:
    That definition is presented in Clause 7.
    with:
    That definition is presented in Clause 8.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section 7.1, 2nd Paragraph

  • Key: XMI24-164
  • Legacy Issue Number: 17735
  • Status: closed  
  • Source: Anonymous
  • Summary:

    That definition is presented in Clause 8 rather than 7. Change Clause 7 to Clause 8.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Clause “Additional Information” is not needed.

  • Key: XMI24-163
  • Legacy Issue Number: 17734
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Clause “Additional Information” is not needed. Delete this clause or move to an informative annex except as copyright.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Add formal reference to UML 2.4.1 superStructure and infrastructure specs
    "
    • [UMLInfra] "ISO/IEC 19505-1:2012 , Information technology — Object Management
    Group - Unified Modeling Language (OMG UML) – Part 1: Infrastructure" (OMG
    Specification Unified Modeling Language (OMG UML) Version 2.4.1 —Part 2:
    Infrastructure - http://www.omg.org/spec/UML/2.4.1/Superstructure)
    • [UMLSuper] "ISO/IEC 19505-2:2012 , Information technology — Object
    Management Group - Unified Modeling Language (OMG UML) – Part 2:
    OMG Issue No: 17734 Disposition: Resolved
    XMI 2.5 RTF Report – URGENT BALLOT 2.4.2 Page 77 of 95
    Superstructure" (OMG Specification Unified Modeling Language (OMG UML) Version
    2.4.1 —Part 2: Superstructure - http://www.omg.org/spec/UML/2.4.1/Superstructure)
    "
    Add formal reference to XML namespace spec:
    "
    • [NAMESP] "Namespaces in XML 1.0 (Third Edition)" W3C Recommendation 8 December 2009
    http://www.w3.org/TR/2009/REC-xml-names-20091208/ "
    See resolution for Issue 17743 for an additional normative reference to be added.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section 1 Scope: The statements are not for the Scope

  • Key: XMI24-161
  • Legacy Issue Number: 17732
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The statements are not for the Scope. The area or range of this standard should be stated clearly.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Foreword Page vii: Title of ISO/IEC DIS 195058 is different.

  • Key: XMI24-160
  • Legacy Issue Number: 17731
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Title of ISO/IEC DIS 195058 is different. Use “ISO/IEC DIS 195058 Information technology – Object Management Group – Meta Object Facility (MOF) Core Version 2.4.1”.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    There is no need for the version number in the title.
    Change reference in the forward to the following:
    "
    ISO/IEC 19508:2013 "Information technology - Object Management Group - Meta
    Object Facility (MOF) Core
    "

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Foreword Page vii

  • Key: XMI24-159
  • Legacy Issue Number: 17730
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Title of ISO/IEC 19505-2:2011 is different. Use “ISO/IEC 19505-2:2012 Information technology – Object Management Group Unified Modeling Language (OMG UML) – Part 2: Superstructure”.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Change reference in the forward to the following:
    "
    ISO/IEC 19505-2:2012 , Information technology — Object Management Group -
    Unified Modeling Language (OMG UML) – Part 2: Superstructure
    "

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Title page i: f “MOF 2 XMI” in a title means “MOF to XMI”, it is not adequate

  • Key: XMI24-158
  • Legacy Issue Number: 17729
  • Status: closed  
  • Source: Anonymous
  • Summary:

    If “MOF 2 XMI” in a title means “MOF to XMI”, it is not adequate. Change the title if it means “to”.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Change the title, which current reads:
    OMG MOF 2 XMI Mapping Specification
    with:
    Object Management Group - XML Metadata Interchange (XMI)

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section 2 Normative Reference: ISO/IEC standards were not specified

  • Key: XMI24-162
  • Legacy Issue Number: 17733
  • Status: closed  
  • Source: Anonymous
  • Summary:

    ISO/IEC standards were not specified. MOF(ISO/IEC19502) and XMI(ISO/IEC19502)
    MOF4.2 (ISO/IEC29505) should be considered

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Title page i

  • Key: XMI24-157
  • Legacy Issue Number: 17728
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Category “Object Management Group” is not adequate for standards. Change to “Information technology – Object Management Group MOF 2 XMI Version 2.4.1”.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section 7.12

  • Key: XMI24-156
  • Legacy Issue Number: 17727
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This hanging paragraph is but one example of the considerable amount of background and motivational text that occurs throughout the document. Such material may be appropriate in an introductory textbook, but is out of place in a standard. All such material should be removed from the body of the standard, leaving only detailed specification expressing requirements on implementers of products and other artefacts conforming to the standard . Delete all explanatory and motivational material from the body of the standard. Really useful elements may be moved to one or more informative annexes.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Place the hanging paragraphs into a new subclause, with a designation that 17.12 is
    informative
    "
    17.12.1 Motivation
    Subclause 17.12 is informative, and is not required for conformance.
    The goal is to provide a mechanism for specifying the differences between documents so
    that an entire document does not need to be transmitted each time. This design does not
    specify an algorithm for computing the differences, just a form for transmitting them.
    Up to now we have seen how to transmit an incomplete or full model. This way of working
    may not be adequate for allenvironments. More precisely, we could mention environments
    where there are many model changes that must be transmitted very quickly to other users.
    For these environments the full model transmission can be very resource consuming (time,

    network traffic, ...) making it very difficult or even not viable for finding solutions for
    cooperative work.
    The most viable way to solve this problem is to transmit only the model changes that occur.
    In this way different instances of a model can be maintained and synchronized more easily
    and economically. Concurrent work of a group of users becomes possible with a simple
    mechanism to synchronize models. Transmitting less information allows synchronizing
    models more efficiently.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section 7.11.6: Move the example to an informative annex and delete the clause from its present position.

  • Key: XMI24-155
  • Legacy Issue Number: 17726
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This clause contains an extended example and does not contain any requirements. It is out of place in the body of a standard. Move the example to an informative annex and delete the clause from its present position.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Add the following as a new first sentence to 7.11.6
    "The example in this subclause is informative."
    Change the caption for Figure 7.3 from:
    "
    Figure 7.3 - GIS Cambridge model
    "
    To:
    "
    Figure 7.3 - GIS Cambridge meta model

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section 6 - delete clause

  • Key: XMI24-154
  • Legacy Issue Number: 17725
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It is not usual in ISO or IEC standards to acknowledge contributors to the document. It is not obvious that in all cases the terms used uniquely identify a specific organisation. Delete the clause.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace clause 6 text, which current reads:
    The following companies submitted and/or supported parts of this specification:
    • Adaptive
    • Ceira Technologies, Inc.
    • Compuware Corporation
    • DSTC
    • Hewlett-Packard
    • International Business Machines
    • IONA
    • MetaMatrix
    • Softeam
    • Sun Microsystems
    • Telelogic, AB
    • Unisys
    • University of Kent
    with:
    6.1 Acknowledgements
    Annex C contains an informative list of companies which contributed to this
    specification .
    Add a new Informative Annex
    Annex C Acknowledgements
    This annex is informative
    The following companies submitted and/or supported parts of this specification: 88
    Solutions, Adaptive, Ceira Technologies, Inc., Compuware Corporation, DSTC,
    Hewlett-Packard, International Business Machines, IONA, MetaMatrix, Raytheon,
    Softeam, Sun Microsystems, Telelogic, AB, Unisys, University of Kent

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section 4

  • Key: XMI24-153
  • Legacy Issue Number: 17724
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Whilst the statement that the document contains no formal definitions taken from other documents may well be true, it is not particularly useful. It may also be true that no terms are used in this document with meanings that cannot be found in common dictionaries. If this is the case, then a statement to that effect would be more useful than the existing statement. Otherwise definitions of terms that are used with special meanings must be included here. There are a number of abbreviations that are used in the body of the document without explanation. They should be expanded or otherwise explained here. Include an “Abbreviation” clause, and if appropriate a populated Definitions clause.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section 3 references

  • Key: XMI24-152
  • Legacy Issue Number: 17723
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Where a referenced document has been published, or is in the course of publication, as an International Standard, as is the case for the MOF, then the reference should be to the IS version. Change the reference for the Meta Object Facility to ISO/IEC 19508, which should have been published no later than the IS version of the current document.
    Make similar changes for any other referenced documents that have been published in ISO, IEC or ITU versions.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Change clause 3 , from:
    "
    The following referenced documents are indispensable for the application of this document.
    For dated references, only the edition cited applies. For undated references, the latest edition
    of the referenced document (including any amendments) applies.
    • Meta Object facility (MOF) Core Specification, Version 2.4.1 http://www.omg.org/spec/MOF
    • Extensible Markup Language (XML) 1.0 (Fifth Edition) W3C Recommendation 26
    November 2008 • XML Schema Part 1: Structures Second Edition W3C Recommendation 28
    October 2004
    • XML Schema Part 2: Datatypes Second Edition W3C Recommendation 28 October 2004
    • XML Linking Language (XLink) Version 1.1 W3C Recommendation 06 May 2010
    • XPointer Framework W3C Recommendation 25 March 2003 • XPointer element() Scheme
    W3C Recommendation 25 March 2003
    • XPointer xmlns() Scheme W3C Recommendation 25 March 2003
    "
    To the following:
    '
    The following referenced documents are indispensable for the application of this
    document. For dated references, only the edition cited applies. For undated
    references, the latest edition of the referenced document (including any
    amendments) applies.
    • [MOF] "ISO/IEC 19508:2013 "Information technology - Object Management Group -
    Meta Object Facility Core" (OMG Specification Meta Object facility (MOF) Core
    Specification, Version 2.4.2 - http://www.omg.org/spec/MOF/2.4.2)
    • [UMLInfra] "ISO/IEC 19505-1:2012 , Information technology — Object Management
    Group - Unified Modeling Language (OMG UML) – Part 1: Infrastructure" (OMG
    Specification Unified Modeling Language (OMG UML) Version 2.4.1 —Part 2:
    Infrastructure - http://www.omg.org/spec/UML/2.4.1/Superstructure)
    • [UMLSuper] "ISO/IEC 19505-2:2012 , Information technology — Object
    Management Group - Unified Modeling Language (OMG UML) - Part 2:
    Superstructure" (OMG Specification Unified Modeling Language (OMG UML) Version
    2.4.1 —Part 2: Superstructure - http://www.omg.org/spec/UML/2.4.1/Superstructure)
    • [XML] " Extensible Markup Language (XML) 1.0 (Fifth Edition) W3C
    Recommendation 26 November 2008 http://www.w3.org/TR/2008/REC-xml-
    20081126/
    • [XMLSchema1] "XML Schema Part 1: Structures Second Edition" W3C
    Recommendation 28 October 2004 http://www.w3.org/TR/2004/REC-xmlschema-1-
    20041028/
    • [XMLSchema2] "XML Schema Part 2: Datatypes Second Edition" W3C
    Recommendation 28 October 2004 http://www.w3.org/TR/2004/REC-xmlschema-2-
    20041028/
    • [XLink] " XML Linking Language (XLink) Version 1.1" W3C Recommendation 06
    May 2010 http://www.w3.org/TR/2010/REC-xlink11-20100506/
    • [XPointerFramework] "XPointer Framework" W3C Recommendation 25 March
    2003 http://www.w3.org/TR/2003/REC-xptr-framework-20030325/
    • [XPointerElement] "XPointer element() Scheme" W3C Recommendation 25 March
    2003 http://www.w3.org/TR/2003/REC-xptr-element-20030325/
    • [XPointerXmls] "XPointer xmlns() Scheme" W3C Recommendation 25 March 2003
    http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/
    • [NAMESP] "Namespaces in XML 1.0 (Third Edition)" W3C Recommendation 8
    December 2009 http://www.w3.org/TR/2009/REC-xml-names-20091208/
    • [INFOSET] "XML Information Set (Second Edition)" W3C Recommendation 4
    February 2004 http://www.w3.org/TR/2004/REC-xml-infoset-20040204

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section 2.3.1

  • Key: XMI24-151
  • Legacy Issue Number: 17722
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Rather than referring to page numbers within the document, internal cross-references should identify clause numbers and titles. Include clause numbers, rather than page numbers in the references to “XMI Model” and “Tailoring Schema Production”.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace both bullets in clause 2.3.1, which current reads:
    • The guidelines for using the extension elements suggested in “XMI Model” on page
    8 are found there and in “Tailoring Schema Production” on page 26. Tools should
    place their extended information within elements that are not in the XMI namespace
    or within elements that have the XMI namespace and a tag name of “Extension.”
    They should also declare the nature of the extension using the standard XMI
    elements where applicable, and preserve the extensions of other tools that fall within
    the XMI namespace.
    • Processing of XMI differencing elements (“Effects on Document Production” on
    page 31) is an optional compliance point.
    with:
    • The guidelines for using the extension elements suggested in clause 7.5 “XMI
    Model” are found there and in clause 7.11 “Tailoring Schema Production”. Tools
    should place their extended information within elements that are not in the XMI
    namespace or within elements that have the XMI namespace and a tag name of
    “Extension.” They should also declare the nature of the extension using the standard
    XMI elements where applicable, and preserve the extensions of other tools that fall
    within the XMI namespace.
    • Processing of XMI differencing elements (“Effects on Document Production” in
    clause 7.11.5) is an optional compliance point.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section 2.2.2

  • Key: XMI24-150
  • Legacy Issue Number: 17721
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The first bullet is imprecise, although its intention is reasonably clear. It attempts to impose requirements that cannot be verified easily, or perhaps at all. Replace the bullet with:
    An XMI document shall be “valid” and “well formed”, as defined in the W3C XML Recommendation. If associated with a specific XML schema, then it shall be consistent with that XML schema.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section 2.1 - delete

  • Key: XMI24-149
  • Legacy Issue Number: 17720
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This clause contains what are, essentially, definitions of the terms “XMI Document” and “XMI Schema”, together with a sentence that does not obviously achieve what it claims to do. The subclause does not describe anything. Delete this clause 2.1, and include definitions of “XMI Document” and “XMI Schema” in clause 4.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace the second sentence in clause 2.1, which current reads:
    “XMI Document” and “XMI Schema” are defined as documents and schemas
    produced by the XMI production (document and XML schema) rules defined in this
    specification.
    with:
    The terms “XMI Document” and “XMI Schema” are defined in Clause 4.
    Replace 4, which current reads:
    There are no formal definitions in this specification that are taken from other
    documents.
    with:
    The following are the only terms defined in this standard. There are no other terms
    used in this document with meanings that cannot be found in other standards.
    [XMI Document] A document produced by the XMI production rules defined in
    this specification.
    [XMI Schema] A schema produced by the XMI production rules defined in this
    specification.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section1: The intended scope of the standard is unclear

  • Key: XMI24-148
  • Legacy Issue Number: 17719
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The intended scope of the standard is unclear. The first sentence is unnecessary commentary. The second sentence implies that this standard defines only some of the important aspects of defining objects using XML, but ignores others. The final sentence refers to MOF, but does not relate it in any way to what has gone before. Change the Scope to:
    This International Standard supports the Meta Object Facility (MOF) Core defined in ISO/IEC 19508 by defining mechanisms for the use of XML elements and attributes for representation of objects defined using the MOF.
    It defines mechanisms that may be used to link objects within the same file of in different files; supports references between objects in terms of Ids and UUIDS; and supports validation of XMI documents using XML schemas.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace clause 1, which current reads:
    XMI is a widely used interchange format for sharing models using XML. XMI defines
    many of the important aspects involved in describing objects in XML:
    • The representation of objects in terms of XML elements and attributes is the
    foundation.
    • Since objects are typically interconnected, XMI includes standard
    mechanisms to link objects within the same file or across files.
    • Object identity allows objects to be referenced from other objects in terms of
    IDs and UUIDs.
    • Validation of XMI documents using XML Schemas.
    XMI describes solutions to the above issues by specifying EBNF production rules to
    create XML documents and Schemas that share objects consistently.
    MOF is the foundation technology for describing metamodels, which cover the wide
    range of domains: this in turn is based on (a constrained subset) of UML.
    with:
    This International Standard supports the Meta Object Facility (MOF) Core defined in
    ISO/IEC 19508. MOF is the foundation technology for describing metamodels. It
    covers a wide range of domains, and is based on a constrained subset of UML. XMI
    is a widely used XML interchange format. It defines the following aspects involved in
    describing objects in XML:
    • The representation of objects in terms of XML elements and attributes.
    • The standard mechanisms to link objects within the same file or across files.
    • The validation of XMI documents using XML Schemas.
    • Object identity, which allows objects to be referenced from other objects in
    terms of IDs and UUIDs.
    XMI describes solutions to the above issues by specifying EBNF production rules to
    create XML documents and Schemas that share objects consistently.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

The text should be reviewed for clarity and objectivity and then amended

  • Key: XMI24-147
  • Legacy Issue Number: 17718
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The technical intent of the document is reasonably clear, and it appears to have been used for several effective implementations. The presentation of the material in the document is a long way from the ISO/IEC format, which is permitted for the first version of a standard introduced by the JTC1 PAS process, but there are a number of places where small changes would bring it closer to what users of ISO/IEC standards usually expect. There are also a number of places where the text is unclear or does not make obvious sense.
    Large tracts of motivational and background material tend to obscure the normative specifications. The text should be reviewed for clarity and objectivity, and then suitably amended before it is further considered for progression to IS.

  • Reported: XMI 2.1.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The proposed change is not sufficiently detailed to be actionable..
    Disposition: Close No Change

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section B6

  • Key: XMI24-146
  • Legacy Issue Number: 17494
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    I think it would be helpful if uuids were limited to valid
    URIs. An href is typed as xsd:anyURI, so if a uuid is a URI
    it is straightforward to use in an href. If the uuid is not
    a URI the href is more complex, probably requiring the
    document URL, which, given an id must also be present, would
    make the uuid pointless. (This comment applies for uuids
    in general. In JDeveloper we've taken uuids to be URIs.)

    Additionally, it is impossible for an importing tool to ensure
    arbitrary string uuids generated by different exporting tools
    are unique. A standard URI scheme gives some hope that if two
    uuids are the same, they are the same object.

  • Reported: XMI 2.1.1 — Fri, 13 Jul 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Requiring that UUIDs be URIs would be a drastic change beyond the powers of an
    RTF. Also, such a change would break almost any existing tool implementation and
    is therefore discouraged.
    Disposition: Closed – No Change

  • Updated: Fri, 6 Mar 2015 23:16 GMT

An XMIReferenceElement cannot be used for serializing a composite property

  • Key: XMI24-145
  • Legacy Issue Number: 17389
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Specification: OMG MOF XMI Mapping Specification, Version 2.4.1 (formal/2011-08-09)

    Subclause 9.4.1 EMOF Package requires that “A property, type is not a PrimitiveType or Enumeration, isComposite=true” have an XMI representation of “Nested XMIObjectElement”. Nothing in Subclause 9.4.2 CMOF Package alters this.

    The BNF for an XMIObjectElement is given in Subclause 9.5.2 Object Structure by production 2a:XMIObjectElement. This production does allow such an element to include 2d:XMIAttributes, but such attributes do not include hrefs. The production 2m:Link is the one for hrefs, and this is used in 2l:LinkAttribs, which is, in turn, used only by 2c:XMIReferenceElement. It is not included directly in 2a:XMIObjectElement.

    So, the conclusion is that something like “<packagedElement href=”…”/> would not be a valid EMOF/CMOF serialization, since that is an XMIReferenceElement, not and XMIObjectElement, and packagedElement is a composite property. Divide a large model based on its hierarchical composition structure into across multiple XMI files, resulting in tool-specific approaches for such modularization in most major UML tools.

    Suggested resolution: In the last line of the table in Subclause 9.4.1, change the XMI representation of “XMIObjectElement” to:

    Choice of:

    1. Nested XMIObjectElement

    2. Nested XMIReferenceElement

  • Reported: XMI 2.1.1 — Tue, 22 May 2012 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    This was in fact already addressed at XMI 2.4.1.
    However the text could be further clarified to cover the multiple file case and
    generally tidied (e.g. to remove the typo “clot”).

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Grammar for XML Schema - XMI XMI 2.1.1

  • Key: XMI24-144
  • Legacy Issue Number: 16890
  • Status: closed  
  • Source: Georgia Institute of Technology ( Mark Kindl)
  • Summary:

    As part of our UML work for the National Information Exchange Model (NIEM) we have encountered what appear to be errors in the grammars for XML Schema in several XMI specs. Please let us know if we have misinterpreted these issues

  • Reported: XMI 2.1.1 — Thu, 8 Dec 2011 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Grammar for XML Schema - XMI 2.4 Beta

  • Key: XMI24-143
  • Legacy Issue Number: 16889
  • Status: closed  
  • Source: Georgia Institute of Technology ( Mark Kindl)
  • Summary:

    As part of our UML work for the National Information Exchange Model (NIEM) we have encountered what appear to be errors in the grammars for XML Schema in several XMI specs. Please let us know if we have misinterpreted these issues

  • Reported: XMI 2.1.1 — Thu, 8 Dec 2011 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:16 GMT

No unambiguous way in XMI 2.4 UML 2.4 to serialize UML 2.4's StructuredActivityNode

  • Key: XMI24-142
  • Legacy Issue Number: 16330
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    We just recently had discussion with Ed about an issue with Activity::node and Activity::group. Both are composite non-derived properties and it causes problems with all StructuredActivityNodes, which are ActivityNodes and ActivityGroups at the same time.
    MagicDraw or Eclipse implementation of UML does not allow to own the same element in two composites , even if owner element is the same.
    Does XMI support that?

    So, ExpansionRegion or any other StructuredActivityNode appears in Activity::group only.

    fUML spec/engine expects to find them in Activity::node , as all owned nodes should be there.

    Any suggestions? Don't you think we should fix that somehow?

  • Reported: XMI 2.1.1 — Fri, 10 Jun 2011 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:16 GMT

The production rule for Associations should use sequence if the tag order is set to true

  • Key: XMI24-141
  • Legacy Issue Number: 16277
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    7. AssociationDef ::= "<xsd:element name=’"’ 7a:AssnElmtName ’"’>"

    "<xsd:complexType>

    <xsd:choice minOccurs=’0’

    maxOccurs=’unbounded’>"

    7b:AssnContents

    "</xsd:choice>"

    7d:AssnAtts

    "</xsd:complexType>

    </xsd:element>"

    Should be:

    7. AssociationDef ::= "<xsd:element name=’"’ 7a:AssnElmtName ’"’>"

    "<xsd:complexType>”

    (“<xsd:choice minOccurs=’0’

    maxOccurs=’unbounded’>" |

    “<xsd:sequence>” )

    7b:AssnContents

    ("</xsd:choice>" | “<xsd:sequence>” )

    7d:AssnAtts

    "</xsd:complexType>

    </xsd:element>"

    Replace the text for rule 7:

    The declaration of an Association consists of the names of its AssociationEnd XML elements (whether

    or not they are owned by the Association).

    With:

    The declaration of an Association consists of the names of its AssociationEnd XML elements (whether

    or not they are owned by the Association). If org.omg.xmi.ordered is true then a sequence is used (with the order of ends being that form the metamodel), otherwise a choice.

  • Reported: XMI 2.1.1 — Wed, 25 May 2011 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 23:16 GMT

The rule for 6f has become corrupted

  • Key: XMI24-140
  • Legacy Issue Number: 16276
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    ( 6b: DataTypeContents |

    "<xsd:any minOccurs=’0’ maxOccurs=’u

    processContents=’" // ProcessCont

    "’/>")?

    Should be:

    ( 6b: DataTypeContents |

    "<xsd:any minOccurs=’0’ maxOccurs=’unbounded’

    processContents=’" // ProcessContents Value //

    "’/>")?

  • Reported: XMI 2.1.1 — Wed, 25 May 2011 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    agreed, accept proposal

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Rule 4f has an extraneous “>”

  • Key: XMI24-139
  • Legacy Issue Number: 16275
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    "></xsd:choice></xsd:complexType></xsd:element>" ) )*

    Should be:

    "</xsd:choice></xsd:complexType></xsd:element>" ) )*

  • Reported: XMI 2.1.1 — Wed, 25 May 2011 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Rule 4f still uses the word “Reference” instead of Class-typed Property

  • Key: XMI24-138
  • Legacy Issue Number: 16274
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    4f. ClassCompositions ::= ( "<xsd:element name=’" //Name of Reference// "’"

    Should be:

    4f. ClassCompositions ::= ( "<xsd:element name=’" //Name of Class-typed Property// "’"

  • Reported: XMI 2.1.1 — Wed, 25 May 2011 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 23:16 GMT

In the XML Schema production rules the following in rule 4 is missing the option separator |:

  • Key: XMI24-137
  • Legacy Issue Number: 16273
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    ( "<xsd:complexContent>"

    "<xsd:extension base=’" 4a:ClassTypeName "’")?

    …

    ( "</xsd:extension>"

    "</xsd:complexContent>" )?

    Should be:

    ( "<xsd:complexContent>" |

    "<xsd:extension base=’" 4a:ClassTypeName "’")?

    …

    ( "</xsd:extension>" |

    "</xsd:complexContent>" )?

  • Reported: XMI 2.1.1 — Fri, 27 May 2011 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 23:16 GMT

attributes which apply to model elements and do not make sense at the XMI element level:

  • Key: XMI24-136
  • Legacy Issue Number: 16272
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    In the XMI.xsd file, the xmi:XMI element has the following attributes which apply to model elements and do not make sense at the XMI element level:

    • <xsd:attribute ref="id"/>
    • <xsd:attributeGroup ref="IdentityAttribs"/>
      <xsd:attributeGroup ref="LinkAttribs"/>
      <xsd:attribute name="type" type="xsd:QName" use="optional" form="qualified"/>
  • Reported: XMI 2.1.1 — Wed, 25 May 2011 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Delete these attributes from the document and the XMI.xsd file.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section 6.5.:

  • Key: XMI24-135
  • Legacy Issue Number: 15869
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Section 6.5.: The text “The values of the Properties are serialized as a single string separated (by default) by commas.” Is only true if the tag org.omg.xmi.flattenStructuredDatatypes is true– as per issue 8884

  • Reported: XMI 2.1.1 — Thu, 2 Dec 2010 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Explain that the XMIObjectElement syntax can be used, and refer to the earlier description from 8884

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Section 6.5.2 – nil=’true’ is only used if org.omg.xmi.includeNils = ‘true’

  • Key: XMI24-134
  • Legacy Issue Number: 15868
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Section 6.5.2 – nil=’true’ is only used if org.omg.xmi.includeNils = ‘true’

  • Reported: XMI 2.1.1 — Thu, 2 Dec 2010 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Clarify as proposed

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Section 6.5.2

  • Key: XMI24-133
  • Legacy Issue Number: 15867
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Section 6.5.2 – should state that “The value of an EnumerationLiteral is its name” (as opposed to …an Enumeration…).

  • Reported: XMI 2.1.1 — Thu, 2 Dec 2010 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace as proposed.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Section 6, rule 2n

  • Key: XMI24-132
  • Legacy Issue Number: 15866
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Section 6, rule 2n: should remove the type/Qname preceding the URI – this is never used for hrefs.

  • Reported: XMI 2.1.1 — Thu, 2 Dec 2010 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    As proposed.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Section 4.11.3 needs better clarification

  • Key: XMI24-131
  • Legacy Issue Number: 15865
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Section 4.11.3 needs to better clarify what happens if both element and attribute are both true as per 9675

  • Reported: XMI 2.1.1 — Thu, 2 Dec 2010 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    As per suggestion. Also qualify the tag names.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Section 4.5.3 states that the XMI element is ‘typically not present’

  • Key: XMI24-130
  • Legacy Issue Number: 15864
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Section 4.5.3 states that the XMI element is ‘typically not present’ which is not really true and gives the wrong impression. And in fact it is needed for the documentation elements.

  • Reported: XMI 2.1.1 — Thu, 2 Dec 2010 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Adapt the wording.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Section 5.2.2:

  • Key: XMI24-129
  • Legacy Issue Number: 15863
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Section 5.2.2: The elements for documentation must be included within in the “XMI” complexType; Also XMIPackage should be removed as a consequence of Issue 9694. More generally section 5.2.2 duplicates both 4.5.3 (which has the schema presented section by section) and the separate machine readable CMI.xsd file and hence introduces lots of room for error – so should be removed

  • Reported: XMI 2.1.1 — Thu, 2 Dec 2010 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Delete the Schema part of 5.2.2.
    The documentation elements cannot be included in the complex type for XMI since they would violate the ‘unique particle attribution rule’ since the XMI element also has a xsd:any element. However there is confusion cause by the existence of doth these elements and the elements with upper case: which are only valid if used as top level elements.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Section 5.2.1, rule 5:

  • Key: XMI24-128
  • Legacy Issue Number: 15862
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Section 5.2.1, rule 5: Class Elements should only be included if the metaclass is non-abstract

  • Reported: XMI 2.1.1 — Thu, 2 Dec 2010 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Change as recommended

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Section 5.2.1 rules 4d to 4e

  • Key: XMI24-127
  • Legacy Issue Number: 15861
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Section 5.2.1 rules 4d to 4e: The text still use xmi:Any regardless of the new tag allowMetaModelExtensions - as applied to 4f by issue 15381. The text from that issue should be applied to these rules as well as 4f

  • Reported: XMI 2.1.1 — Thu, 2 Dec 2010 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Update the text as proposed. Also use a better term than ‘complex attribute’ in 4d. And remove redundant text at the end of 4e and 4f.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Section 5.2.1, rule 4b/4c

  • Key: XMI24-126
  • Legacy Issue Number: 15860
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Section 5.2.1, rule 4b/4c uses the phrase “regardless of whether they are marked as derived”. This contradicts the serialize tag and should be removed. Likewise bullet 1 of 6.5.3 implies a choice which does not exist

  • Reported: XMI 2.1.1 — Thu, 2 Dec 2010 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    These need to be reconciled with the serialize tag

  • Updated: Fri, 6 Mar 2015 23:15 GMT

The syntax in 6.2.1 allows URI in attributes, which is not mentioned or documented or used elsewhere

  • Key: XMI24-125
  • Legacy Issue Number: 15453
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    The syntax in 6.2.1 allows URI in attributes, which is not mentioned or documented or used elsewhere:

    2j:XMIReferenceAttribute ::= //xmiName// "=’"
    ( //refId// | 2n:URIref )+ "’"

    This option should be removed.

  • Reported: XMI 2.1.1 — Wed, 8 Sep 2010 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Remove the option as per the issue

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Specification makes frequent use of ‘attribute’ and ‘reference’ from MOF 1.4

  • Key: XMI24-123
  • Legacy Issue Number: 15410
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    MOF 2.x removed the distinction yet in many places the terms are still used.

    In many cases it does not make much difference but in production rule 4b in section 5.2 it states that ‘class attributes’ should precede ‘class references’.

    If the distinction is preserved the only sensible interpretation would be to define ‘class reference’ as ‘those Properties of a Class which are association ends – i.e. have association not empty.

  • Reported: XMI 2.1.1 — Fri, 6 Aug 2010 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Duplicate issue.

    Revised Text:
    None

    Disposition: Duplicate of 9653

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Production rule wrongly includes type on link elements

  • Key: XMI24-122
  • Legacy Issue Number: 15409
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Production rule 2c in section 6.4 is as follows:

    2c:XMIReferenceElement::= "<" xmiName (2g:TypeAttrib)? 2l:LinkAttribs "/>"

    However this does not make sense: the TypeAttrib is redundant with the xmi:type on the object referenced (making it fragile to change) and the spec says nothing about what happens if they are inconsistent or one may be the superclass of the other. In fact the text describing rule 2c says nothing about the use of 2g or the TypeAttrib:

    “2c. Use this production rule to serialize a reference to an object using an XML element. If you use identity

    attributes, the values of the identity attributes must match the values of the identity attributes for the object

    that is referenced.”

    Finally, none of the examples of use of href or idref in the document use the TypeAttrib e.g. example in 4.10.3 or 4.10.2.2.

    Proposed resolution: remove the use of 2g from rule 2c

  • Reported: XMI 2.1.1 — Fri, 6 Aug 2010 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Further to the issue, the XSD generated for References (rule 4e) (corrected by resolution to 11002) does not allow for xmi:type to be specified
    Note that if people want to ‘cache’ the type for whatever reason, that it can be done, as for any other property such as ‘name’, as per the following bullet of 4.10.1:
    “When acting as a proxy, XML attributes may be defined, but not contents. The XML attributes act as a cache that gives an indication if the link should be followed.”

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Change default of tag org.omg.xmi.contentType

  • Key: XMI24-121
  • Legacy Issue Number: 15382
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    This defaults to empty which means that in generated XML schemas there is no ComplexType generated! Which is inconsistent with practice and usefulness, and indeed the examples in the spec document.

    The default should be changed to ‘complex’. This affects Table 4.1 (note that this row duplicates ‘complex’ as a possible value) and rule 4 of 5.2.1.

  • Reported: XMI 2.1.1 — Sun, 25 Jul 2010 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Allow for ‘tight’ schemas

  • Key: XMI24-120
  • Legacy Issue Number: 15381
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    If a metamodel has multiple inheritance, XMI has no means to produce an XML Schema to restrict the target of a reference: it is always xsd:any.

    Though in theory a metamodel can be extended, it is rarely the case.

    Therefore there should be an option to produce an XSD that validates only instances of an unextended metamodel. In fact this should be the default.

    There should be a new Boolean XMI tag org.omg.xmi.allowMetamodelExtension which defaults to ‘false’

    This will affect section 4.8.5 and rules 4e and 4f of 5.2.1. And examples. If org.omg.xmi.allowMetamodelExtension is false (the default) then the type of the element will be a union of the metaclass typing the property and any subclass in the metamodel. Abstract classes will not be included.

  • Reported: XMI 2.1.1 — Sun, 25 Jul 2010 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    If a metamodel has multiple inheritance, XMI has no means to produce an XML Schema to restrict the target of a reference: it is always xsd:any.
    Though in theory a metamodel can be extended, it is rarely the case.
    Therefore there should be an option to produce an XSD that validates only instances of an unextended metamodel. In fact this should be the default.
    There should be a new Boolean XMI tag org.omg.xmi.allowMetamodelExtension which defaults to ‘false’

    This will affect section 4.8.5 and rules 4e and 4f of 5.2.1. And examples.
    If org.omg.xmi.allowMetamodelExtension is false (the default) then the type of the element will be a union of the metaclass typing the property and any subclass in the metamodel. Abstract classes will not be included.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Missing rules for production of document by Extent or Object Containment

  • Key: XMI24-119
  • Legacy Issue Number: 15309
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    XMI 1.x contained rules for which elements to include in an export (sections 5.3.2 and 5.3.3 of formal/02-01-01). This aspect is entirely missing from XMI 2.x.

  • Reported: XMI 2.1.1 — Fri, 25 Jun 2010 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    XMI 1.x contained rules for which elements to include in an export (sections 5.3.2 and 5.3.3 of formal/02-01-01). This aspect is entirely missing from XMI 2.x.

    Revised Text:
    This aspect is covered in the description of the export operation in the MOF Facility and Object Lifecycle specification.

    Disposition: Closed – No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Unclear XSD production for external metamodels

  • Key: XMI24-118
  • Legacy Issue Number: 15308
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    The XMI production rules do not cover the case where a metamodel references elements in other metamodels (e.g. through a Generalization or the type of a Property/Association). Though the Document production rules provide for the use of hrefs, this is not covered in the XSD production e.g. I would expect an xsd:import element (note that MOF does not require packageImports for this case).

  • Reported: XMI 2.1.1 — Fri, 25 Jun 2010 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The use of Imports is covered in the resolution of 9692.

    Revised Text:
    (see resolution for issue 9692)

    Disposition: Closed – Duplicate to / merged with 9692

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Unclear order of property production

  • Key: XMI24-117
  • Legacy Issue Number: 15307
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    When org.xmi.isOrdered is true, it’s not clear what the exact order of properties must be for an element: the spec just refers to the ‘order of elements in the MOF metamodel’ – however both the superclasses and the packagedElement properties are unordered do there is no order that can be used.

  • Reported: XMI 2.1.1 — Fri, 25 Jun 2010 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The precise order is important for cases such as the textual comparison of model files

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Deprecate/remove Chapter 7

  • Key: XMI24-116
  • Legacy Issue Number: 15306
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Chapter 7 (Production of MOF from XML) is insubstantial and has not been implemented. It has nothing to do with the purpose of XMI – as indicated by the examples which are in terms of application models not metamodels. Its presence diminishes the spec as a whole.

  • Reported: XMI 2.1.1 — Fri, 25 Jun 2010 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Remove Chapter 7.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

XMI does not allow the differentiation between "set to default" and "unset" states for properties

  • Key: XMI24-115
  • Legacy Issue Number: 14628
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    Tthe XMI spec clause 6.5.2 says:

    "Properties whose values are the default values are not serialized. "

    This contradicts the MOF spec, which differentiates between the "set to default" and "unset" states of Properties.

    A possible resolution is to change the statement to rather say:

    "Property values are serialized when their values are expliclity set (i.e. calling isSet() returns true) and not serialized otherwise."

  • Reported: XMI 2.1.1 — Wed, 11 Nov 2009 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    After much discussion the proposal is to clarify the MOF spec such that there will be no distinction between the default value having been implicitly set (on creation) or explicitly set. In other words, there is no need to track and persist the explicit ‘set’ action. And default values are not serialized in either case.

    On a related point, XMI allows the serialization of a property with a nil value to indicate ‘that it is empty e.g. <property1 xsi:nil=”true”/>. Also an empty element may be used. Both of these require that an XML element be used for the Property.
    However this should be made clearer and the rule for this in 2b is incorrect in using xmiName not “xsi” and not allowing empty elements.
    We should also clarify when the xsi declaration is needed.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Use of xmi:type

  • Key: XMI24-114
  • Legacy Issue Number: 12859
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Section 4.6.4. states:

    “The type attribute is used to specify the type of object being serialized, when the type is not known from the model. This can occur if the type of a reference has subclasses, for instance.”

    And Rule 2g in section 6.4.2 states:

    “If the class of the object cannot be determined unambiguously from the model, you must specify the class name using the “type” attribute.”

    In general it is never possible to determine a class unambiguously from the model – since any class may be extended with subclasses in model extensions – and many other aspects of XMI are designed to allow for this. The document itself is inconsistent as to whether the xmi:type property is optional: in 4.5.3 it is declared as optional, in 4.6.4 it is not.

    Furthermore, the fact that xmi:type is optional makes it impossible in many cases to determine the type of elements, especially if using an XML-based tool without access to the metamodel.

    Proposed resolution:

    -----------------------

    Replace the above quoted sentences with the following:

    4.6.4

    “The type attribute is used to specify the type of object being serialized.”

    6.4.2 2g

    “You must specify the class name using the “type” attribute.”

    In the example below Figure 6.6 replace:

    <Department id=“13”>

    <member name=“Glozic”/>

    <member name=“Andrews”/>

    </Department>

    With:

    <Department id=“13”>

    <member name=“Glozic” xmi:type=”Employee”/>

    <member name=“Andrews” xmi:type=”Employee”/>

    </Department>

  • Reported: XMI 2.1.1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace text as described below

  • Updated: Fri, 6 Mar 2015 20:59 GMT