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

XMI for MOF 2 (XMI 2.1) RTF — All Issues

  • Key: XMI24
  • Issues Count: 181
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
XMI24-181 Minor spelling mistakes XMI 2.5.1 open
XMI24-180 XMI composite opposite constraint overly restrictive XMI 2.4 XMI 2.4.1 Resolved closed
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-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-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-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-166 Section 7.1, 3rd Paragraph 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-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-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-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-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-132 Section 6, rule 2n 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-127 Section 5.2.1 rules 4d to 4e 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-131 Section 4.11.3 needs better clarification 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-71 Addition to section 4.10.1 XMI 2.1 XMI 2.4 Resolved closed
XMI24-70 4.10.1 the following bullet is misleading XMI 2.1 XMI 2.4 Resolved closed
XMI24-78 4.11, table 4.1: 'complex' is repeated in the list of values for contentTyp XMI 2.1 XMI 2.4 Resolved closed
XMI24-77 Section 4.11, table 4.1 XMI 2.1 XMI 2.4 Resolved closed
XMI24-81 table 4.1 the href attribute XMI 2.1 XMI 2.4 Resolved closed
XMI24-80 Section 4.11.2 XMI 2.1 XMI 2.4 Resolved closed
XMI24-75 Co.xml" is not a valid URI! I XMI 2.1 XMI 2.4 Resolved closed
XMI24-74 Section 4.10.2.2 XMI 2.1 XMI 2.4 Resolved closed
XMI24-73 Section 4.10.2.1 XMI 2.1 XMI 2.4 Resolved closed
XMI24-82 last bullet of 4.11.2 XMI 2.1 XMI 2.4 Resolved closed
XMI24-76 MOF2 does not have clustering XMI 2.1 XMI 2.4 Resolved closed
XMI24-79 tag names should be in bold or full name used XMI 2.1 XMI 2.4 Resolved closed
XMI24-72 Section 4.10.1 last bullet XMI 2.1 XMI 2.4 Resolved closed
XMI24-35 logic for use of position attributes in 4.5.6 and 4.12.2 is not clear XMI 2.1 XMI 2.4 Resolved closed
XMI24-29 4.10.3 is an example from UML 1.4 XMI 2.1 XMI 2.4 Resolved closed
XMI24-32 6.5 should be further clarified XMI 2.1 XMI 2.4 Resolved closed
XMI24-31 6.5.3 2nd row of table XMI 2.1 XMI 2.4 Resolved closed
XMI24-34 Figure 4.2 XMI 2.1 XMI 2.4 Resolved closed
XMI24-33 2.3.1 the first bullet is very vague XMI 2.1 XMI 2.4 Resolved closed
XMI24-37 differences section 4.5 should refer to 4.12 XMI 2.1 XMI 2.4 Resolved closed
XMI24-36 XSD fragment for difference elements in 4.5.6 XMI 2.1 XMI 2.4 Resolved closed
XMI24-40 4.3.3: in the following sentence the word 'lax' should be bold XMI 2.1 XMI 2.4 Resolved closed
XMI24-39 3.1 refers to 'XML Production of XML Schema' XMI 2.1 XMI 2.4 Resolved closed
XMI24-38 2.3.3 is unclear as to what's needed for conformance XMI 2.1 XMI 2.4 Resolved closed
XMI24-41 Section 4.3.1 XMI 2.1 XMI 2.4 Resolved closed
XMI24-30 4.10.3, line 4 of the example "Document 1" XMI 2.1 XMI 2.4 Resolved closed
XMI24-109 define a new XSD Type XMI 2.1 XMI 2.4 Resolved closed
XMI24-108 Fix on xmi:id attribute XMI 2.1 XMI 2.4 Resolved closed
XMI24-97 5.2 rule 7: define 'Unreferenced Association' in MOF2 terms XMI 2.1 XMI 2.4 Resolved closed
XMI24-96 5.2 rule 6 XMI 2.1 XMI 2.4 Resolved closed
XMI24-104 Section: 4.13.3 XMI 2.1 XMI 2.4 Resolved closed
XMI24-103 Section: 4.11.5 XMI 2.1 XMI 2.4 Resolved closed
XMI24-102 4.4 XMI Schema and Document Structure XMI 2.1 XMI 2.4 Resolved closed
XMI24-107 Missing XSD files XMI 2.1 XMI 2.4 Resolved closed
XMI24-106 timestamp XMI 2.1 XMI 2.4 Resolved closed
XMI24-100 Section 8 XMI 2.1 XMI 2.4 Deferred closed
XMI24-99 Section 7: the examples and rules use Attributes extensively not Properties XMI 2.1 XMI 2.4 Resolved closed
XMI24-98 5.2.2 refers to "XMI 2.0" and has wrong fixed declarations XMI 2.1 XMI 2.4 Resolved closed
XMI24-105 4.6.3 Version attribute XMI 2.1 XMI 2.4 Resolved closed
XMI24-101 Appendix A and references XMI 2.1 XMI 2.4 Resolved closed
XMI24-94 5.2 rule 1c XMI 2.1 XMI 2.4 Resolved closed
XMI24-93 4.12.4 the last XMI fragment XMI 2.1 XMI 2.4 Resolved closed
XMI24-91 Section 4.11.7 editorial XMI 2.1 XMI 2.4 Resolved closed
XMI24-90 Section 4.11.7 issue XMI 2.1 XMI 2.4 Resolved closed
XMI24-88 attribute Mountain::elevation XMI 2.1 XMI 2.4 Resolved closed
XMI24-87 remove xsd:annotation elements XMI 2.1 XMI 2.4 Resolved closed
XMI24-84 4.11.6, 4.11.7 XMI 2.1 XMI 2.4 Resolved closed
XMI24-83 4.11.3 is largely redundant with, and should be merged with, 4.11.5 XMI 2.1 XMI 2.4 Resolved closed
XMI24-95 5.2 rule 1b and 1h XMI 2.1 XMI 2.4 Resolved closed
XMI24-86 4.11.7 uses a type "GM_Curve£ which is not defined or described XMI 2.1 XMI 2.4 Resolved closed
XMI24-92 4.12.4 The example addition is not well-formed XMI 2.1 XMI 2.4 Resolved closed
XMI24-89 4.11.7:example should make clear whether this is a CMOF or EMOF metamodel XMI 2.1 XMI 2.4 Resolved closed
XMI24-85 4.11.7 has: xmlns:xmi="http://www.omg.org/XMI" which is wrong XMI 2.1 XMI 2.4 Resolved closed
XMI24-56 Statement in section 4.8.1 XMI 2.1 XMI 2.4 Resolved closed
XMI24-55 frequent mentions of MOF attributes and references as opposed to properties XMI 2.1 XMI 2.4 Resolved closed
XMI24-54 4.8.1 has "the schema generator must choose ... XMI 2.1 XMI 2.4 Resolved closed
XMI24-53 type attribute should always be required in serialized elements. XMI 2.1 XMI 2.4 Resolved closed
XMI24-51 Section 4.6.2 XMI 2.1 XMI 2.4 Resolved closed
XMI24-50 end of 4.6.1 XMI 2.1 XMI 2.4 Resolved closed
XMI24-52 Section 4.6.3 XMI 2.1 XMI 2.4 Resolved closed
XMI24-46 4.6.1, and elsewhere XMI 2.1 XMI 2.4 Resolved closed
XMI24-47 4.6.1: uuid should refer to the use of URIs XMI 2.1 XMI 2.4 Resolved closed
XMI24-43 Section 4.4 XMI 2.1 XMI 2.4 Resolved closed
XMI24-42 Section 4.3.3 XMI 2.1 XMI 2.4 Resolved closed
XMI24-49 4.5.3: the tag settings should include 'org.omg.xmi.attribute' = false XMI 2.1 XMI 2.4 Resolved closed
XMI24-48 Section 4.5.3 XMI 2.1 XMI 2.4 Resolved closed
XMI24-45 4.6.1: should descrieb what importer is expected to do with label attribute XMI 2.1 XMI 2.4 Resolved closed
XMI24-44 Section 4.5.1 XMI 2.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-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
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-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-112 Section: 4.8.5 XMI 2.1 XMI 2.4 Resolved closed
XMI24-111 Spec doesn't provide unified way to specify/represent link references XMI 2.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-110 section 4.6.2 XMI Issue: Attribute "href" type XMI 2.1 XMI 2.4 Resolved closed
XMI24-113 Section: 4.8.8 XMI 2.1 XMI 2.4 Resolved closed
XMI24-116 Deprecate/remove Chapter 7 XMI 2.1.1 XMI 2.4 Resolved closed
XMI24-65 Sections 4.8.l7, 6.5.3.1: syntax proposed is unusable XMI 2.1 XMI 2.4 Resolved closed
XMI24-64 Clarification in section 4.8.17 XMI 2.1 XMI 2.4 Resolved closed
XMI24-63 4.8.4 XMI 2.1 XMI 2.4 Resolved closed
XMI24-69 issue with section 4.10.1 XMI 2.1 XMI 2.4 Resolved closed
XMI24-68 Statement in section 4.9 XMI 2.1 XMI 2.4 Resolved closed
XMI24-60 Statement in section 4.8.4 XMI 2.1 XMI 2.4 Resolved closed
XMI24-59 Statement in section 4.8.2 XMI 2.1 XMI 2.4 Resolved closed
XMI24-58 XMI element is optional XMI 2.1 XMI 2.4 Resolved closed
XMI24-62 Section 4.8.4 issue XMI 2.1 XMI 2.4 Resolved closed
XMI24-61 Section 4.8.4 editorial XMI 2.1 XMI 2.4 Resolved closed
XMI24-57 4.8.1 The example should be made consistent XMI 2.1 XMI 2.4 Resolved closed
XMI24-67 xmi:type XMI 2.1 XMI 2.4 Resolved closed
XMI24-66 Section 4.8.8 XMI 2.1 XMI 2.4 Resolved closed
XMI24-28 Section 4.5.4 XMI 2.1 XMI 2.4 Resolved closed
XMI24-15 Section: 8 XMI 2.0 XMI 2.4 Resolved closed
XMI24-14 opaque content XMI 2.0 XMI 2.4 Resolved closed
XMI24-17 Unclear serialization of derived data XMI 2.0 XMI 2.4 Resolved closed
XMI24-16 Section: 9 XMI 2.0 XMI 2.4 Resolved closed
XMI24-18 Impractical representation of structured datatypes XMI 2.0 XMI 2.4 Resolved closed
XMI24-13 Section 2.2.1, rule 6f XMI 2.0 XMI 2.4 Resolved closed
XMI24-12 Missing rule for generating type or element declarations XMI 2.0 XMI 2.4 Resolved closed
XMI24-22 section 4.5.3 XMI 2.1 XMI 2.4 Resolved closed
XMI24-21 what, if anything, is normative in XMI 2.1 XMI 2.1 XMI 2.4 Resolved closed
XMI24-24 Section 6.4.1 5j:Extension XMI 2.1 XMI 2.4 Resolved closed
XMI24-23 timestamp attribute XMI 2.1 XMI 2.4 Resolved closed
XMI24-20 section 4.3.1 (Required XML Declarations), XMI 2.1 XMI 2.4 Resolved closed
XMI24-19 Section: 4.4 XMI 2.1 XMI 2.4 Resolved closed
XMI24-27 Section 4.5.2 XMI 2.1 XMI 2.4 Resolved closed
XMI24-26 Section: 4.9.3 XMI 2.1 XMI 2.4 Resolved closed
XMI24-25 Urgent issue on XMI 2.1 -inconsistency between XMI metamodel and quoted XSD XMI 2.1 XMI 2.4 Resolved closed
XMI24-11 Type specification of MOF attributes XMI 2.0 XMI 2.4 Resolved closed
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-9 [MOF2] and [UML2] not further specified in the document 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-1 Which type of name should be used XMI 2.0 open
XMI24-3 XMI issue - root elements for XMI Schemas XMI 2.4 open
XMI24-2 metamodel for XML Schema XMI 2.1 open
XMI24-6 Revise XMI examples in 9.4 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-7 No XML-Schema for UML-XMI XMI 2.4 open
XMI24-4 Name transformation XMI 2.4 open
XMI24-124 Extension is only referenced from 1a. However it certainly should be valid within an XMIObjectElement. XMI 2.4 open

Issues Descriptions

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

XMI composite opposite constraint overly restrictive

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

    Section 9.4.1 of the specification contains the following constraint:

    For Properties with isComposite=true, the opposite property is not serialized.

    While this is fine when objects are nested it doesn't make sense when an object is serialised as a root object. For example, stereotype extensions are mapped to composite associations. Stereotypes instances are serialised as root objects because the composite property is not owned by the extended class. To attach them to their extended object the 'base' property is serialised, but this is the opposite of a property with isComposite=true.

  • Reported: XMI 2.4 — Mon, 13 Jun 2011 04:00 GMT
  • Disposition: Resolved — XMI 2.4.1
  • Disposition Summary:

    The constraint should be made specific to where the composite property is itself the
    one used for nesting

  • Updated: Mon, 9 Mar 2015 04:15 GMT

There's inconsistent use of spacing within quotes

  • Key: XMI24-179
  • Legacy Issue Number: 15615
  • Status: closed  
  • Source: Adaptive ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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.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.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 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 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 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

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

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 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 ( Mr. 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 ( Dr. 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 ( Dr. 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: Dassault Systemes ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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, rule 2n

  • Key: XMI24-132
  • Legacy Issue Number: 15866
  • Status: closed  
  • Source: Adaptive ( Mr. 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 6.5.:

  • Key: XMI24-135
  • Legacy Issue Number: 15869
  • Status: closed  
  • Source: Adaptive ( Mr. 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 ( Mr. 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 ( Mr. 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 5.2.1 rules 4d to 4e

  • Key: XMI24-127
  • Legacy Issue Number: 15861
  • Status: closed  
  • Source: Adaptive ( Mr. 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 4.5.3 states that the XMI element is ‘typically not present’

  • Key: XMI24-130
  • Legacy Issue Number: 15864
  • Status: closed  
  • Source: Adaptive ( Mr. 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 ( Mr. 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 ( Mr. 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 4.11.3 needs better clarification

  • Key: XMI24-131
  • Legacy Issue Number: 15865
  • Status: closed  
  • Source: Adaptive ( Mr. 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 5.2.1, rule 4b/4c

  • Key: XMI24-126
  • Legacy Issue Number: 15860
  • Status: closed  
  • Source: Adaptive ( Mr. 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 ( Mr. 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

Addition to section 4.10.1

  • Key: XMI24-71
  • Legacy Issue Number: 9669
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.10.1 to the bullet "It is efficient practice for maximizing caching and encapsulation to use local proxies of the same element within a document to link to a single proxy that holds an external reference." add "This is particularly useful when referencing predefined DataTypes such as the PrimitiveTypes String, Integer etc."

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Add text as described below

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

4.10.1 the following bullet is misleading

  • Key: XMI24-70
  • Legacy Issue Number: 9668
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.10.1 the following bullet is misleading: "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." and should be reworded: "When acting as a proxy, XML attributes may be used, but not contents. The XML attributes act as a cache or guide that gives
    an indication of the element values if the link were to be followed: however there is no gurante that these cached values accurately represent the current values of the linked element

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace text as described below

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

4.11, table 4.1: 'complex' is repeated in the list of values for contentTyp

  • Key: XMI24-78
  • Legacy Issue Number: 9676
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.11, table 4.1: 'complex' is repeated in the list of values for contentType

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Delete text as described below.

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

Section 4.11, table 4.1

  • Key: XMI24-77
  • Legacy Issue Number: 9675
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.11, table 4.1: the definitions of the tags 'element' and 'attribute' do not state what happens if they are false. The fact that they both default to false implies that by default nothing gets serialized! In practice the normal behavior (documented elsewhere in the spec) is to create both elements and attributes where allowed - I think the explanations should state that 'attribute' means 'serialize only as an XML attribute (not as an element)'. This is borne out by 4.11.7 which states "The XMI 'element' tag can be used to signal that attributes can be serialized only as XML elements."
    And similarly for 'element'. In which case there should be the additional constraint that attribute and element cannot both be true.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace text as described below.

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

table 4.1 the href attribute

  • Key: XMI24-81
  • Legacy Issue Number: 9679
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In table 4.1 the href attribute is described thus "If true, use the href attribute rather than the idref
    attribute for links within a document". To be meaningful the following should be added "this also prohibits the use of XML attributes for class-typed properties". And 4.11.2 should add the constraint that if Href=true then attribute=false and element=true.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    As proposed, extend the href attribute description and add the constraint

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

Section 4.11.2

  • Key: XMI24-80
  • Legacy Issue Number: 9678
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In 4.11.2 the statement "If useSchemaExtensions is true, the MOF model must not have multiple inheritance." would be better expressed "If the MOF model has multiple inheritance then useSchemaExtensions must be false"

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace text as described below

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

Co.xml" is not a valid URI! I

  • Key: XMI24-75
  • Legacy Issue Number: 9673
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.10.2.2 has the example "<mgr xmi:id="mgr_1" href="Co.xml#emp_2"/>" however "Co.xml" is not a valid URI! It is use in several of the examples

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Correct URI syntax in examples

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

Section 4.10.2.2

  • Key: XMI24-74
  • Legacy Issue Number: 9672
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.10.2.2 states "Supporting links across documents is optional." however this is not mentioned in any other section including the compliance section. This sentrence should be deleted.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Agreed

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

Section 4.10.2.1

  • Key: XMI24-73
  • Legacy Issue Number: 9671
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.10.2.1 should also mention the use of XML attributes representign class-typed properties in the metamodel

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Rephrase section 4.10.2.1 to cover also class-typed properties

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

last bullet of 4.11.2

  • Key: XMI24-82
  • Legacy Issue Number: 9680
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The last bullet of 4.11.2 starts "If the isProperty tag is true, the" - this should refer to "idProperty". In the same bullet "The tagged property must have type Datatype." should be "The tagged property must be Datatype-typed."

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Change as suggested

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

MOF2 does not have clustering

  • Key: XMI24-76
  • Legacy Issue Number: 9674
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.11 states "Typically, the Tags could be in a separate Package and a
    'super' package could cluster this Tags package and the model package to drive the Schema generation." however MOF2 does not have clustering.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Improve the text

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

tag names should be in bold or full name used

  • Key: XMI24-79
  • Legacy Issue Number: 9677
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In 4.11.2, and elsewhere in the spec, tag names should be in bold, or the full name used e.g. org.omg.xmi.ordered

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Use long tag names, except in tables 4.1 and 4.2.

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

Section 4.10.1 last bullet

  • Key: XMI24-72
  • Legacy Issue Number: 9670
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.10.1 last bullet: "Association role elements typically contain proxies that link to the definitions of the classes that participate in the association." I do not understand this, and it is not practiced in any standard metamodels. Propose delting the bullet.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Delete last bullet of section 4.10.1.

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

logic for use of position attributes in 4.5.6 and 4.12.2 is not clear

  • Key: XMI24-35
  • Legacy Issue Number: 9632
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The logic for use of position attributes in 4.5.6 and 4.12.2 is not clear. For example it states "The default, -1, indicates to add the replacing elements at the end of the target element." however the model allows many target elements which may be distributed throughout - so the explanation does not make sense. Furthermore it's not clear what the effect of a positive value would be e.g. "5". This applies to Add as well as Replace. Even the text 'at the end of the target element' is not precise. I suspect the intent is to allow elements to be added in the sequence of others owned by a containing element but this is not at all clear.
    Position is for some reason defined as xsd:string in the XSD fragment - whereas it is declared as Integer in the XMI model.
    Also the purpose/effect of nested Difference elements is not explained.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    A further problem is that the example for Add in 12.2.4 does not make sense: there is no indication that the new Class should be related to the target via the ownedElement association: the addition should be represented as an ownedElement.

    And the Replace element is generally problematic in being able to specify both an element to be replaced and a position. Given that the intent was not to change the ‘content’ at all it also seems to be incompatible with various XMI options (e.g. serializing metamodel properties as contained XML elements would not work).

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

4.10.3 is an example from UML 1.4

  • Key: XMI24-29
  • Legacy Issue Number: 9626
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.10.3 is an example from UML 1.4: this should be updated for UML 2.1. UML 1.4 is not a valid example since it is not a MOF 2 metamodel - so outside the scope of the XMI 2.1 rules. Likewise 4.9.3, 4.12.4.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The example in 4.12.4 has been updated in the resolution to 9632. The other 2 examples listed need updating.

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

6.5 should be further clarified

  • Key: XMI24-32
  • Legacy Issue Number: 9629
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    6.5 should be further clarified to make clear that these rules, also apply to instances of Abstractions, EMOF and CMOF packages e.g. how to serialize instances of a CMOF metamodel such as UML - that is how to serialize UML models. In general 6.5 should be better integrated with 6.4: as it stands the rules for EMOF and CMOF seem an afterthought, whereas 6.4 is all about serializing EMOF or CMOF models.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The resolution to this issue should also reflect that MOF 2.4 is no longer based on Abstractions. Furthermore the rules for Abstractions in section 6.5.1 are all redundant since overridden by those for EMOF and CMOF

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

6.5.3 2nd row of table

  • Key: XMI24-31
  • Legacy Issue Number: 9628
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    6.5.3 2nd row of table starts "As Association": this should be "An Association",

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace text as described below

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

Figure 4.2

  • Key: XMI24-34
  • Legacy Issue Number: 9631
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In Figure 4.2 the XMI model references Object (from MOF) which should be MOF::Element

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Update Figure 4.2

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

2.3.1 the first bullet is very vague

  • Key: XMI24-33
  • Legacy Issue Number: 9630
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    2.3.1 the first bullet is very vague for a compliance point and requires rewording: The first sentence has no verb. The second sentence is too vague with respect to 'designated extension areas' and 'the nature of the extension' and 'where applicable' and 'where appropriate'.
    The second bullet does not say how the differences section is to be processed (and the differences section itself does not give that detail).

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Modify text as described below.

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

differences section 4.5 should refer to 4.12

  • Key: XMI24-37
  • Legacy Issue Number: 9634
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The differencs section 4.5 should refer to 4.12 for how the differences are to be processed

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Add text as described below

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

XSD fragment for difference elements in 4.5.6

  • Key: XMI24-36
  • Legacy Issue Number: 9633
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The XSD fragment for difference elements in 4.5.6 uses XSD:IDREFS for 'target' which does not allow reference to external elements using href. The intention is clearly to allow external refercnes: section 4.5.6 starts "The Add class represents an addition to a target set of objects in this document or other documents." And 4.12.4 has an example (which is not valid acordign to the XSD fragment).

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The issue refers only to the XML attribute form of target: and forgets that there is also an XML element which allows the use of href or xmi:idref via the inclusion of ObjectAttribs.

    Revised Text:

    • none-

    Disposition: Closed – No Change

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

4.3.3: in the following sentence the word 'lax' should be bold

  • Key: XMI24-40
  • Legacy Issue Number: 9638
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.3.3: in the following sentence the word 'lax' should be bold. "The processContents attribute is lax,"

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Bold the word lax in the text as described below.

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

3.1 refers to 'XML Production of XML Schema'

  • Key: XMI24-39
  • Legacy Issue Number: 9636
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    3.1 refers to 'XML Production of XML Schema' which was the name of an RFP/submission but not a formal specification

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Delete text as described below

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

2.3.3 is unclear as to what's needed for conformance

  • Key: XMI24-38
  • Legacy Issue Number: 9635
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    2.3.3 is unclear as to what's needed for conformance: the following seems t allow any/all of the usages listed. "Use of the normative XML Schema model by instantiation, code generation, invocation, or serialization". Furthermore the XMI specification says nothing about 'code generation' or 'invocation'. Finally the compliance point uses the term 'XML Schema Model' yet section 8 uses "XML Schema Infoset Model".

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    This compliance clause refers to things outside the scope of the MOF XMI Mapping.

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

Section 4.3.1

  • Key: XMI24-41
  • Legacy Issue Number: 9639
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.3.1 states "Some of these XML elements contain metadata about the metadata to be transferred, for example, the identity of the model associated with the metadata, the tool that generated the metadata, whether the metadata has been verified, etc." However the XMI spec has nothing about verification - so this last clause should be deleted.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    This is a duplicate of issue number 9293. Resolve with no change.

    Disposition: Merged / Duplicate

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

4.10.3, line 4 of the example "Document 1"

  • Key: XMI24-30
  • Legacy Issue Number: 9627
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.10.3, line 4 of the example "Document 1" has:

    <constrainedElement xmi:idref="idO1"/>

    This is not valid and requires a xmi:type attribute. Likewise for other such elements in the example.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The issue is wrong: xmi:type was never required for link elements, and from XMI 2.4 it is not even allowed.

    Revised Text:

    • none -

    Disposition: Closed – No Change

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

define a new XSD Type

  • Key: XMI24-109
  • Legacy Issue Number: 11002
  • Status: closed  
  • Source: International Business Machines ( Mr. Petko Chobantonov)
  • Summary:

    It will be useful to define a new XSD Type that can be used for reference properties instead of xmi:Any. The suggested definition is:

    <xsd:complexType name="LinkAttribs" >

    <xsd:attributeGroup ref="xmi:LinkAttribs"/>

    </xsd:complexType>

  • Reported: XMI 2.1 — Fri, 11 May 2007 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The text in 4.8.5 describing use of xmi:Any belongs in 4.8.6 for Composites – since only composites have nested elements.
    The suggestion for a new complex type is unnecessary since the Attribute Group linkAttribs already serves that purpose for non-composites.
    Production rule 4e needs to have xmi:Any removed.
    And the presence of min and maxOccurs needs to reflect the specification in the description of the tags in Table 4.1– if not specified they should be set to 0 and unbounded (the default for each is 1).

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

Fix on xmi:id attribute

  • Key: XMI24-108
  • Legacy Issue Number: 11001
  • Status: closed  
  • Source: International Business Machines ( Mr. Petko Chobantonov)
  • Summary:

    The XSD specification states that global attributes cannot be defined as optional. For more information:

    http://www.w3.org/TR/xmlschema-0/#Globals

    " In other words, global declarations cannot contain the attributes minOccurs, maxOccurs, or use."

  • Reported: XMI 2.1 — Fri, 11 May 2007 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Though the issue is correct with regard to global attributes in XSDs, XMI defines only one global attribute which is xmi:id and this does not use any of the prohibited minOccurs, maxOccurs or use in the published XMI.xsd file: however production rule 1g does have use=optional.

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

5.2 rule 7: define 'Unreferenced Association' in MOF2 terms

  • Key: XMI24-97
  • Legacy Issue Number: 9695
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    5.2 rule 7: define 'Unreferenced Association' in MOF2 terms

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    In addition the spec is missing a section in section 4.8 for “Association representation”
    MOF 2 does not have the MOF 1.x distinction between association ends and references. In any case, to support linking elements defined in other documents there is no need to restrict use of the Association syntax.

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

5.2 rule 6

  • Key: XMI24-96
  • Legacy Issue Number: 9694
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    5.2 rule 6 defines PackageElement which seems to have no purpose - such an element will never appear in an XMI file (there is nothing in section 6.4 for it).
    So this whole rule 6 and sub-rules 6a to 6h should be deleted.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Though a metamodel package defines elements, there is no need for an element for the package itself: there is never the need to exchange an instance of the package ‘UML’ as an XML element for example (as opposed to instances of uml:Model or uml:Package as defined by the UML metamodel). Furthermore there is nothing in section 4.8 covering ‘Package Representation’.

    Unlike MOF 1.x, MOF 2 does not support static features : this was one original reason for packageElements at earlier versions of MOF/XMI.

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

Section: 4.13.3

  • Key: XMI24-104
  • Legacy Issue Number: 10640
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    In steps 2 and 4 of the example in Section 4.13.3, the text refers to a tool assigning extenderIDs. However, in the subsequent XMI in steps 3 and 5, the values show up as uuids. Is this a mistake, or am I misinterpreting how extenderIDs are used?

  • Reported: XMI 2.1 — Fri, 2 Feb 2007 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Correct section 4.13.3

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

Section: 4.11.5

  • Key: XMI24-103
  • Legacy Issue Number: 10426
  • Status: closed  
  • Source: Eisenhut Informatik AG ( Claude Eisenhut)
  • Summary:

    The tagged values "ordered", "processContents" and "valueSeperator" are missing in table 4.2

  • Reported: XMI 2.1 — Wed, 1 Nov 2006 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Insert the missing tags in table 4.2

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

4.4 XMI Schema and Document Structure

  • Key: XMI24-102
  • Legacy Issue Number: 10112
  • Status: closed  
  • Source: - ( Christian Hujer)
  • Summary:

    Change 'Example: <? XML version="1.0" ?>' into 'Example: <?xml version="1.0"?>'. Conforming XML parsers will complain about the bogus '<? XML' with an error message like "missing PI target" or "invalid PI target" and stop processing. See http://www.w3.org/TR/2006/REC-xml11-20060816/#NT-XMLDecl and http://www.w3.org/TR/2006/REC-xml-20060816/#NT-XMLDecl Production: [23] XMLDecl ('xml' must be lowercase and there must not be any character, not even a whitespace character, between '<?' and 'xml') Change 'Example: <? XML version="1.0" ENCODING="UCS-2" ?>' into 'Example: <?xml version="1.0" encoding="ucs-2"?>'. Conforming XML parsers will complain about the bogus 'ENCODING' with an error message like "'?>' expected" and stop processing. See http://www.w3.org/TR/2006/REC-xml11-20060816/#NT-EncodingDecl and http://www.w3.org/TR/2006/REC-xml-20060816/#NT-EncodingDecl Production: [80] EncodingDecl The OMG spec should be clarified to prevent implementers from running into compatibility problems by violating a referenced spec (in this case XML). In case the uppercase notion was chosen for emphasis, look for alternatives like italics, oblique or bold. Additionally I suggest setting these code examples in a fixed width font.

  • Reported: XMI 2.1 — Fri, 18 Aug 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace text as described below

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

Missing XSD files

  • Key: XMI24-107
  • Legacy Issue Number: 11000
  • Status: closed  
  • Source: International Business Machines ( Mr. Petko Chobantonov)
  • Summary:

    No separate XSD file is distributed with the specification. Further this XSD should be available on the OMG servers. The specification contains XSD declarations for all XMI classes, but they are embedded in the text and it is not possible for XSD validation tools directly to use it

  • Reported: XMI 2.1 — Fri, 11 May 2007 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The XMI.xsd file was produced at version 2.1.1 and available on the OMG server. It will be updated as a normal part of producing the XMI 2.4 artifacts

    Revised Text:

    • none -

    Disposition: Closed – No Change

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

timestamp

  • Key: XMI24-106
  • Legacy Issue Number: 10659
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    The XMI specification index contains an entry for a timestamp that is widely implemented by vendors but the definition is missing from the specification. What is the definition?

  • Reported: XMI 2.1 — Mon, 12 Feb 2007 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    See resolution for Issue 9296.

    Revised Text:
    (See resolution for Issue 9296.)

    Disposition: Closed – Duplicate to 9296

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

Section 8

  • Key: XMI24-100
  • Legacy Issue Number: 9698
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 8: would be more usefully titled "The XML Schema Metamodel". An electronic version of this metamode is needed. It should reference a specific dated version of the XSD standard. The metamodel should specify the XMI tags required for serializatrion as XMI.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Deferred — XMI 2.4
  • Disposition Summary:

    The XML Schema metamodel will be moved into the IMM specification when it is adopted.

    Revised Text:

    • none -

    Disposition: Deferred

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

Section 7: the examples and rules use Attributes extensively not Properties

  • Key: XMI24-99
  • Legacy Issue Number: 9697
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 7: the examples and rules use Attributes extensively not Properties

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Change “Attribute” to “Property”

    Revised Text:
    Changes for section 7 merged into changes defined by resolution to Issue 9653.

    Disposition: Closed – Duplicate / Related to 9653

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

5.2.2 refers to "XMI 2.0" and has wrong fixed declarations

  • Key: XMI24-98
  • Legacy Issue Number: 9696
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    5.2.2 refers to "XMI 2.0" and has wrong fixed declarations that are inconsistent with the XMI model and have wrong xmlns and targetNamespace.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace text as described below.

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

4.6.3 Version attribute

  • Key: XMI24-105
  • Legacy Issue Number: 10658
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Please can one of our OMG members report this back to the OMG. Comparing these two pages from the XMI v2.1 specification it is apparent that the attribute “version” is “2.0” in on part of the specification and “2.1” in another

  • Reported: XMI 2.1 — Mon, 12 Feb 2007 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Handled by resolution to issue 9650 (deleting the version attribute)

    Revised Text:
    (See resolution to 9650)

    Disposition: Closed – Duplicate to 9650

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

Appendix A and references

  • Key: XMI24-101
  • Legacy Issue Number: 9699
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Appendix A refers to XML Schema as a 'proposed' recommendation, UML 2.0 as 'an in progress standard' and MOF 2 likewise. Should not need to reference XMI 2.0. Should separate normative references.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Superseded by the resolution for issue 9649

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

5.2 rule 1c

  • Key: XMI24-94
  • Legacy Issue Number: 9692
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    5.2 rule 1c states "1c. If the schema has a target namespace, the targetNamespace attribute is present." This rule does not make sense as a rule for generating a schema! The rule must say what determines whether a targetNamespace is generated and what its value is (e.g. based on a property of the metamodel or a Tag).
    Likewise rule 1d.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The issue is correct.

    It makes sense to use imports for needed declarations from other metamodels which will be in other namespaces through the nature of XMI: hence the syntax should refer to Imports only rather than ‘ImportsAndIncludes’

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

4.12.4 the last XMI fragment

  • Key: XMI24-93
  • Legacy Issue Number: 9691
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.12.4 the last XMI fragment (after the Replace) is wrong: 4.5.6 states "The Replace class represents the deletion of the target set of objects and the addition of the objects referred to in the replacement attribute." So the delete of the original ppp will also delete the newly added class c2 befor e the addition of the new ppp. So the result will be:
    <xmi:XMI version="2.1" xmlns:UML="http://schema.omg.org/spec/UML/1.4"
    xmlns:xmi="http://schema.omg.org/spec/XMI/2.1">
    <UML:Package xmi:id="ppp" xmi:label="p2"/>
    </xmi:XMI>

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The example is completely replaced by resolution of 9632.

    Revised Text:

    Disposition: Closed – Duplicate, Resolved by 9632

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

Section 4.11.7 editorial

  • Key: XMI24-91
  • Legacy Issue Number: 9689
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.11.7: the sentence "the validator would not recognized the additional attributes in Road and River" should use "recognize".

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    It can be useful to be able to indicate that an XSD primitive attribute is used to define the type of an attribute of a class. Perhaps some tools do not offer this capability, and each tool that does offer this capability may have its own way of doing it. We should provide the information about the stereotype so readers of the document have a hint that may give a clue for how to do it with their chosen tool.

    Replace text as described below.

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

Section 4.11.7 issue

  • Key: XMI24-90
  • Legacy Issue Number: 9688
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.11.7: the sentence "This could be addressed by including datatype 'Date' in the model (in Rose as a class with
    stereotype <<primitive>> or <<alias>>)" is outdated in its mention of Rose and <<alias>>.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    It can be useful to be able to indicate that an XSD primitive attribute is used to define the type of an attribute of a class. Perhaps some tools do not offer this capability, and each tool that does offer this capability may have its own way of doing it. We should provide the information about the stereotype so readers of the document have a hint that may give a clue for how to do it with their chosen tool.

    Replace text as described below

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

attribute Mountain::elevation

  • Key: XMI24-88
  • Legacy Issue Number: 9686
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.11.7: the attribute Mountain::elevation has been declared as type xsd:string despite being defined as an Integer. It has been changed to xsd:int in the 'improved' schema though with no explanation. The built in Primitive Integer has its xsd type defined as xsd:int so this should be in the default example also.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace text as described below

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

remove xsd:annotation elements

  • Key: XMI24-87
  • Legacy Issue Number: 9685
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.11.7 contains several xsd:annotation elements which are neither required nor described as an option by the spec. They should be removed

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Delete text as described below.

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

4.11.6, 4.11.7

  • Key: XMI24-84
  • Legacy Issue Number: 9682
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.11.6, 4.11.7 has: schemaLocation="xmi20.xsd"
    which is wrong for XMI 2.1.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace text as described below

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

4.11.3 is largely redundant with, and should be merged with, 4.11.5

  • Key: XMI24-83
  • Legacy Issue Number: 9681
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.11.3 is largely redundant with, and should be merged with, 4.11.5

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Merge 4.11.3 (partially) into 4.11.5; correct table 4.2 in 4.11.5.

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

5.2 rule 1b and 1h

  • Key: XMI24-95
  • Legacy Issue Number: 9693
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    5.2 rule 1b and 1h: should refer to 'namespace prefix' not 'namespace name' - both in the EBNF and the description. likewise the equivalent rules in section 6.4.1: rules 1b, 1e-h

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Namespace prefix is much better. All of the sections mentioned should be changed. Replace text as described below

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

4.11.7 uses a type "GM_Curve£ which is not defined or described

  • Key: XMI24-86
  • Legacy Issue Number: 9684
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.11.7 uses a type "GM_Curve£ which is not defined or described. It is for some reason represented as xsd:strign in the XSD. Likewise CharacterString

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The purpose of section 4.11.7 is to provide an example of a customized xsd. It is true that GM_Curve is not defined but the objective is achieved because the corresponding xsd:element in the example has a type of "xsd:string

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

4.12.4 The example addition is not well-formed

  • Key: XMI24-92
  • Legacy Issue Number: 9690
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.12.4 The example addition is not well-formed - it does not specify that the Class is to be added as an ownedElement of the Package:
    <difference xmi:type="xmi:Add" addition="Class_1">
    <target href="original.xml#ppp"/>
    </difference>

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    This is covered by the resolution for issue 9632.

    Revised Text:
    (see resolution for issue 9632)

    Disposition: Closed – Duplicate of 9632

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

4.11.7:example should make clear whether this is a CMOF or EMOF metamodel

  • Key: XMI24-89
  • Legacy Issue Number: 9687
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.11.7: the example should make clear whether this is a CMOF or EMOF metamodel

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Add clarification this is EMOF

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

4.11.7 has: xmlns:xmi="http://www.omg.org/XMI" which is wrong

  • Key: XMI24-85
  • Legacy Issue Number: 9683
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.11.7 has: xmlns:xmi="http://www.omg.org/XMI" which is wrong

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    This has been fixed in the current version of the specification. Resolve with no change.

    Disposition: Closed – No Change

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

Statement in section 4.8.1

  • Key: XMI24-56
  • Legacy Issue Number: 9654
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.8.1 states "each tag in XML has its own namespace." which is not technically correct - 'naming context' would be btter than 'namespace'

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Change as proposed

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

frequent mentions of MOF attributes and references as opposed to properties

  • Key: XMI24-55
  • Legacy Issue Number: 9653
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    There are still frequent mentions of MOF attributes and references as opposed to properties. For example 4.8.1 has several mentions such as "model attributes and references is the short name of the attribute or reference." And 4.8.5 is actually titled 'Reference representation' (4.8.4 should be "DataType-typed Properties' and 4.8.5 should be 'Class-typed Properties"). The text needs to be qualified also - for example "For multi-valued Properties, no XML attributes are declared; each value is encoded as an XML element." is wrong if the property is Class-typed.
    4.8.6: Should use "Class-typed Property" instead of "association roles".
    4.8.8: "AssociationEnds with references" should be "Class-typed properties"
    4.11.4: "You may choose features (MOF attribute or reference)"
    4.11.4: "The feature is a multi-valued attribute, or

    • The feature is an attribute whose type is not a simple data type." (note that in the last clause 'simple data type' is not a well-defined term).
      4.11.5: "and for attributes and association ends belonging to the class. For example, the element tag applies to attributes and association ends. If the element tag is set to true for a class, the class itself is not affected, but each attribute and association end belonging to the class is treated as if the element tag were set to true for all of them."
      5.2 rule 2 has "Associations without References," and rule 3 has "based on the attributes and references". Rule 4 contains numerous rules for Attributes and References.
      6.4.2 likewise
  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Clarify as proposed

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

4.8.1 has "the schema generator must choose ...

  • Key: XMI24-54
  • Legacy Issue Number: 9652
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.8.1 has "the schema generator must choose one or more namespace URIs that uniquely identify the XML namespaces in the model." The reference to 'choose' is incorrect - the URI is detrmined by the mandatory org.omg.xmi.nsURI tag.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    There is no “choice” – the schema generator is obligated to use the URI specified by the mandatory org.omg.xmi.nsURI tag.

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

type attribute should always be required in serialized elements.

  • Key: XMI24-53
  • Legacy Issue Number: 9651
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In order to allow XMI to be resilient to extensions then it is not possible to guarantee the target type of any property. Therefore the type attribute should always be required in serialized elements.
    Proposed resolution:
    a) 4.6.4 replace "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" with "The type attribute is used to specify the type of object being serialized. Although in some cases the type is known from the model, this attribute is required to allow for the target type to be extended with further subclasses."
    b) 4.6.4 replace <xsd:attribute name="type" type="xsd:QName" use="optional"
    form="qualified"/> with <xsd:attribute name="type" type="xsd:QName" form="qualified"/>

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    This is a duplicate of issue 12859. Close no change.

    Disposition: Merged / Duplicate

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

Section 4.6.2

  • Key: XMI24-51
  • Legacy Issue Number: 9649
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.6.2 contains "The id attribute value can be specified using a special URI form for XPointers defined in the XLink and XPointer recommendations." These specs need to be included as Normative references. More detail and examples should be given as to how the generic XML capabilities are applied to XMI and the id/uuid/URI.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The need to define normative references, as required by this issue, highlighted the inconsistency of the front parts of the document with the formal structure needed by ISO.

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

end of 4.6.1

  • Key: XMI24-50
  • Legacy Issue Number: 9648
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The end of 4.6.1 has "The MOF refID() is often used as the uuid in XMI implementations." MOF2 does not have this operation: instead the URI capabilities of MOF 2 Core and Facility specs should be referenced.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The refID() function is from MOF 1.x and does no .longer exist in MOF 2.

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

Section 4.6.3

  • Key: XMI24-52
  • Legacy Issue Number: 9650
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.6.3 contains "The version attribute is required only when the XMI version cannot be determined from a parent XML element:" however this is inconsistent with the earlier statement that the version attribute is not required at all since the XMI nsURI determines the version.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The authoritative XMI version number is part of the namespace URI. Therefore the version attribute is redundant and might even introduce wrong information. Remove the version attribute from the whole specification

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

4.6.1, and elsewhere

  • Key: XMI24-46
  • Legacy Issue Number: 9644
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    21) 4.6.1, and elsewhere: should relate the 'id' and uuid' attributes to the 'Property::isId' and Package::id properties in the MOF2 Core spec. These are mentioned nowhere in the XMI spec. In fact it seems that the org.omg.xmi.idProperty tag is redundant with Property::isId.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Change as recommended, though these Property::isId and Package::uri are in UML2.4 now.
    Note: this change must be applied to sections 4.6.2, 5.2.2 and the XMI.xsd file.

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

4.6.1: uuid should refer to the use of URIs

  • Key: XMI24-47
  • Legacy Issue Number: 9645
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.6.1: uuid should refer to the use of URIs, as defined in MOF2 Core, rather than the DCE form of identifier. The DCE standard is no longer relevant in Appendix A.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The MOF Facility and Object Lifecycle specification provides detailed instructions how to generate URIs to be used as uuids.

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

Section 4.4

  • Key: XMI24-43
  • Legacy Issue Number: 9641
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.4 has "An XML document containing only XMI information will have XMI as the root element of the document." And 4.5.3 has first sentence "The top level XML element for XMI documents containing only XMI data is the XMI element." These are not consistent with the rest of the document and practice: for example later in 4.5.3 has: "The XMI element need not be the root element of an XML document; you can include it inside any XML element that was not serialized according to this specification. If a document contains only XMI information, the XMI element is typically not present when there is only a single top-level object."

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Add text as described below

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

Section 4.3.3

  • Key: XMI24-42
  • Legacy Issue Number: 9640
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.3.3 includes "One use of the extension mechanism might be to associate display information for a particular tool
    with the model class represented by the XML element. Another use might be to transmit data that represents extensions
    to a model." This is no longer a good example since the Diagram Interchange standard provides the proper means to represent dislay information.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Delete text as described below

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

4.5.3: the tag settings should include 'org.omg.xmi.attribute' = false

  • Key: XMI24-49
  • Legacy Issue Number: 9647
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.5.3: the tag settings should include 'org.omg.xmi.attribute' = false (to match the XSD fragments included). The Tags should be in the XMI file for the XMI metamodel

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Add text as described below

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

Section 4.5.3

  • Key: XMI24-48
  • Legacy Issue Number: 9646
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.5.3 contains the sentence "The serialization of the XMI element is special--it is defined by the XML Document Production rules in Chapter 8." which is wrong and should be deleted: for exampel it is inconsistent with the previous paragraph in 4.5.3 "Since the XMI model is an instance of MOF, it can be serialized using the same rules as any other MOF model, with one exception."

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Delete the 7th paragraph in section 4.5.3, which currently begins with the words “The serialization of the XMI element …”.

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

4.6.1: should descrieb what importer is expected to do with label attribute

  • Key: XMI24-45
  • Legacy Issue Number: 9643
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    .6.1: should descrieb what an importer is expected to do with the label attribute. The label attribute should be n the XMI model as should id and uuid.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Ignore the label.

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

Section 4.5.1

  • Key: XMI24-44
  • Legacy Issue Number: 9642
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.5.1: should state that there is a standard file XMI.xsd (with an OMG document number) that contains the elements for the XMI model and the elements referred to here: "In addition, there are attribute declarations and attributeGroup declarations that must be imported."

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace the last sentence in the first paragraph of section 4.5.1which current reads:
    The version of this XMI specification is 2.1, and its XMI namespace is “http://schema.omg.org/spec/XMI/2.1.”
    with:
    The version of this XMI specification is 2.1.1, and its XMI namespace is “http://schema.omg.org/spec/XMI/2.1.1", and the XSD file can be found at "http://schema.omg.org/spec/XMI/20071001/07-10-06.xsd."

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

Allow for ‘tight’ schemas

  • Key: XMI24-120
  • Legacy Issue Number: 15381
  • Status: closed  
  • Source: Adaptive ( Mr. 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 ( Mr. 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

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 ( Dr. 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 ( Mr. 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

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

  • Key: XMI24-123
  • Legacy Issue Number: 15410
  • Status: closed  
  • Source: Adaptive ( Mr. 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 ( Mr. 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

Unclear XSD production for external metamodels

  • Key: XMI24-118
  • Legacy Issue Number: 15308
  • Status: closed  
  • Source: Adaptive ( Mr. 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 ( Mr. 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

Section: 4.8.5

  • Key: XMI24-112
  • Legacy Issue Number: 11512
  • Status: closed  
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

    The reference representation of property should not provide the choice between attribute and element. This prevent from using a standard referencing scheme such as XLINK as XLINK cannot be managed as a single attribute. The lack of formal unification of reference representation of properties prevents interoperability between XMI specifications that uses multiple xml documents.

  • Reported: XMI 2.1 — Wed, 26 Sep 2007 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    This will break too many existing implementations. Close no change.

    Disposition: Closed – No Change

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

Spec doesn't provide unified way to specify/represent link references

  • Key: XMI24-111
  • Legacy Issue Number: 11511
  • Status: closed  
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

    The specification doesn't provide a unified way to specify and represent link references. It is currently possible to use ieth IDREF or href. Furthermore, no standard URI representation is made mandatory. The lack of mandatory reference scheme prevents to ensure interoperability when xmi models are organized in multiple xml files

  • Reported: XMI 2.1 — Wed, 26 Sep 2007 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The MOF Facility and Object Lifecycle spec does provide a standard scheme though this is not mandatory. It is referenced from the resolution for 9645.

    Revised Text:

    • none -

    Disposition: Closed – No Change

  • 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 ( Mr. 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

section 4.6.2 XMI Issue: Attribute "href" type

  • Key: XMI24-110
  • Legacy Issue Number: 11006
  • Status: closed  
  • Source: International Business Machines ( Mr. Petko Chobantonov)
  • Summary:

    The section 4.6.2 "Linking attributes" defines the attribute "href" with type "xsd:string". Having in mind that semantics of "href" it will be a better choice to use "xsd:anyURI"

  • Reported: XMI 2.1 — Tue, 15 May 2007 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Change as suggested

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

Section: 4.8.8

  • Key: XMI24-113
  • Legacy Issue Number: 11513
  • Status: closed  
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

    The representation of multiple inheritance prevents from using XSD extension mechanism. As a results, it is impossible to serialize properties which have an abstract type, the sub-type of which having multiple super-type. This is a major issue as it prevents from building a proper, sharable XSD stack.

  • Reported: XMI 2.1 — Wed, 26 Sep 2007 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    XML does not support multiple inheritance and there is nothing we can do about it. Close no change.

    Disposition: Closed – No Change

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

Deprecate/remove Chapter 7

  • Key: XMI24-116
  • Legacy Issue Number: 15306
  • Status: closed  
  • Source: Adaptive ( Mr. 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

Sections 4.8.l7, 6.5.3.1: syntax proposed is unusable

  • Key: XMI24-65
  • Legacy Issue Number: 9663
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.8.l7, 6.5.3.1: the syntax proposed for stringifying structured datatypes is ambiguous and not usable. It's ambiguous since there is no way to tell when the list of values for one multivalued property ends and another starts (the examples all have single-valued properties). If we have a DataType TwoShapes with properties s1: Point[2..*] and s2: Point[2..*] then with the proposed serialization a value such as (1,2,3,4,5,6,7,8,9,10,11,12) is not separable into s1 and s2 values.
    Furthermore it ignores the names of the properties. And has no value for EMOF as claimed: a more natural representation of a structured DataType would be as a class in EMOF. Therefore there should at least be the option to serialize the values using a class-like approach. In fact section 4.14 does state that "MOF complex data types are treated as MOF classes with each field treated as a MOF attribute with a primitive type mapped to XML schema." So for the Point example this would be:
    <TwoPointsOnAGraph>
    <point1 x="0" y="0"/>
    <point1 x="1" y="5"/>
    </TwoPointsOnAGraph>
    and for the Area example would be:
    <aRectangle>
    <area>
    <point1 x="0" y="5"/>
    <point1 x="4" y="0"/>
    </area>
    </aRectangle>

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Resolved by the resolution to issue 8884.

    Revised Text:
    (see resolution to issue 8884)

    Disposition: Closed – Duplicate to issue 8884

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

Clarification in section 4.8.17

  • Key: XMI24-64
  • Legacy Issue Number: 9662
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.8.l7 should make clear that it does not apply to Enumerations and Primitives (which are subclasses of DataType). In this section datatype should be properly written DataType.
    The sentence "In the instance document, the value of the datatype appears as character content." is not generally correct as shown by the example of Point in this section.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Resolution included in resolution to 8884. In addition, change the one sentence mentioned in the issue.

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

4.8.4

  • Key: XMI24-63
  • Legacy Issue Number: 9661
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.8.4 has:
    "For properties with default values, the default value should be the XML string representation to be placed in the schema.
    Default values for properties should be specified in schemas with care since XML allows the processor reading the
    document the option of not processing a schema as an optional optimization. When tools skip processing the schema, they
    do not obtain the default value of XML attributes. Instead, they would have to know the default value from understanding
    the model."
    This largely dates from MOF 1.x which did not have default values (but XMI allowed them to be specified in the XSD). Therefore the 'with care' proviso no longer applies and so the text should be:
    "For Properties with default values, the XML string representation is placed in the schema."
    In fact this makes the tag org.omg.defaultValue redundant (and potewntially in conflict with the metanmodel) - the tag should be removed from the spec (e.g. in table 4.1).

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Follow proposal and remove the “with caution provision” and remove tag org.omg.xmi.defaultValue.
    Furthermore the org.omg.org.fixedValue tag is pointless – it was only ever used for xmi:version which has been deleted by another resolution.

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

issue with section 4.10.1

  • Key: XMI24-69
  • Legacy Issue Number: 9667
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.10.1 has the following bullet. "Links are always to elements of the same type or subclasses of that type. Restricting proxies to reference the same
    element type reduces complexity, enhances reliability and type safety, and promotes caching. In XMI 2, subclasses are
    also allowed, to permit more flexibility in combining models." This seems to state a principle and then state that it's not applied to XMI 2: why not just delete it?

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Delete text as described below

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

Statement in section 4.9

  • Key: XMI24-68
  • Legacy Issue Number: 9666
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.9 states "In XMI 2, a schema generator can decide whether to support the exchange of model fragments." This should be predicatble and e.g. controlled by tags in the metamodel

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace text as described below

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

Statement in section 4.8.4

  • Key: XMI24-60
  • Legacy Issue Number: 9658
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.8.4 states "then by default XML attributes are declared for them as well as XML elements. The reasons for this
    encoding choice are several, including: the values to be exchanged may be very large values and unsuitable for XML
    18 MOF 2.0/XMI Mapping Specification, v2.1 attributes". This reads as if the reasons are for the XML attribute encoding choice (which it is not). Should say "The reasons for the XML element coding choice...".

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace text as described below

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

Statement in section 4.8.2

  • Key: XMI24-59
  • Legacy Issue Number: 9657
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.8.2 states "By default, XMI produces schemas that ignore multiplicities also." This should refer to "XMI 2".

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Change as proposed

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

XMI element is optional

  • Key: XMI24-58
  • Legacy Issue Number: 9656
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.8.1 Includes: "The logical URI is placed in the namespace declaration of the XMI element in XML documents that contain instances of the model." However the XMI element is optional.

  • Reported: XMI 2.1 — Wed, 10 May 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Since the top-level element is not necessarily the XMI element, replace “XMI” with “top level”.

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

Section 4.8.4 issue

  • Key: XMI24-62
  • Legacy Issue Number: 9660
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.8.4 has "where enumName is the name of the enumeration type, and v1 and v2 are the enumeration literals." This should be "where enumName is the name of the Enumeration, and v1 and v2 are the names of the EnumerationLiterals."

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace text as described below

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

Section 4.8.4 editorial

  • Key: XMI24-61
  • Legacy Issue Number: 9659
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.8.4 has "For properties whose types are primitive types (for example, string)". The last word should be String (capital S).

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace text as described below

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

4.8.1 The example should be made consistent

  • Key: XMI24-57
  • Legacy Issue Number: 9655
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.8.1 The example should be made consistent with the actual URI and prefix for UML2. And the structure ('feature' and Attribute are wrong)

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Correct the example.

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

xmi:type

  • Key: XMI24-67
  • Legacy Issue Number: 9665
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.8.8 Should say that because of the typical inability to use Schema inheritance then xmi:type rather than xsi:type is generally used

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Extend the last sentence of the first paragraph in the spirit proposed

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

Section 4.8.8

  • Key: XMI24-66
  • Legacy Issue Number: 9664
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    4.8.8 Should say "more control to the metamodeler" rather than "to the end user"

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Section 4.8.9, not 4.8.8. Change as proposed.

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

Section 4.5.4

  • Key: XMI24-28
  • Legacy Issue Number: 9625
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 4.5.4 has: "The extenderID is an optional internal ID from the extending tool. "
    This should be more specific: it should state that the id must allow the element to be uniquely located within that tool.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Add text as described below

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

Section: 8

  • Key: XMI24-15
  • Legacy Issue Number: 8437
  • Status: closed  
  • Source: Technolution ( Mick Baggen)
  • Summary:

    The document MOF 2.0 XMI Mapping (ptc/04-06-11) contains some (typographical) errors in the EBNF for XML Schema Production (Chapter 8). The proposed corrections are listed below: 1g. XMIFixedAttribs ::= ( "<xsd:attribute ref=’xmi:id’" "use=’optional’>" | "<xsd:attribute name=’" //Id attrib name// "’" "type=’xsd:ID’ use=’optional’>") "<xsd:attributeGroup ref=’xmi:ObjectAttribs’/>" 4. ClassTypeDef ::= "<xsd:complexType name=’" //Name of Class// "’" ("mixed=’true’")? ">" ( "<xsd:complexContent>" "<xsd:extension base=’" 4a:ClassTypeName "’")? ("<xsd:choice minOccurs=’0’ maxOccurs=’unbounded’>" | "<xsd:sequence>")? ( 4b:ClassContents | "<xsd:any minOccurs=’0’ maxOccurs=’unbounded’ processContents=’" // ProcessContents Value // "’/>")? ("</xsd:choice>" | "</xsd:sequence>")? 4g:ClassAttListItems ( "</xsd:extension>" "</xsd:complexContent>" )? "</xsd:complexType>" 7a. AssnElmtName ::= 1h:Namespace //Name of association// 8. EnumSchema ::= "<xsd:simpleType name=’" 8a:EnumTypeName "’>" "<xsd:restriction base=’xsd:string’>" 8c:EnumLiterals "</xsd:restriction>" "</xsd:simpleType>" Futhermore, production rule 4i contains a reference to QName. This is neither a rule nor a terminal/placeholder. Please clarify. Regards, Mick Baggen Principal Consultant Technolution

  • Reported: XMI 2.0 — Wed, 2 Mar 2005 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    This is now section 5.2.1. There are more syntax errors in the EBNF rules than pointed out in the original issue, and the current formatting of the EBNF rules in the document allows ambiguous interpretation. Therefore, most EBNF rules in section 5.2.1 will be replaced.

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

opaque content

  • Key: XMI24-14
  • Legacy Issue Number: 8321
  • Status: closed  
  • Source: BAE Systems ( Pete Kirkham)
  • Summary:

    Inside UML and SysML, there are cases where opaque content occurs as strings. In particular, in the body of comments and constraint expressions. In SysML it is suggested that MathML be used for parametric constraints, similarly Z can be used instead of OCL. MathML is an XML language, and Z may be interchanged using ZedML, an XML language. In comments, it would be nice to allow XHTML for formatting rich text. At the moment, these are all possible by escaping the XML in the opaque string which ends up in an attribute value: <Unable to render embedded object: File (XMI SYSTEM "http://schema.omg.org/spec/XMI/2.1" [ <!ENTITY math "http://www.w3.org/1998/Math/MathML"> <!ENTITY modelica "http://www.modelica.org/documents/ModelicaSpec21.pdf">]> <xmi:XMI xmlns:UML="http://schema.omg.org/spec/UML/1.4" xmlns:SysML="http://schema.omg.org/spec/SysML/0.9" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"> <Documentation> <shortDescription>Some queries on parametric constraints in SysML.</shortDescription> </Documentation> <UML:Model name="BaseLibrary" xmi:id="z0"> <ownedElement xmi:type="UML:Package" xmi:label="BasicPhysics" xmi:id="z1"> <ownedElement xmi:type="SysML:ParamConstraint" xmi:label="NewtonsSecondLawOfMotion"> <ownedElement xmi:type="SysML:Parameter" xmi:label="F" type="Force"/> <ownedElement xmi:type="SysML:Parameter" xmi:label="m" type="Mass"/> <ownedElement xmi:type="SysML:Parameter" xmi:label="a" type="Acceleration"/> <ownedElement xmi:type="UML:Constraint" constrainedElement"> <) not found.-- SysML suggests MathML as a constraint language, but the body of a constraint is defined as a string, so XMI maps it to a xsd:string. This means XML literals such as MathML have to be escaped. This complicates general XML tool based queries of the model. -> <specification xmi:type="UML:OpaqueExpression" language="&math;" body=" <math xmlns="&math;"e;> <apply> <eq/> <ci>F</ci> <apply> <times/> <ci>m</ci> <ci>a</ci> </apply> </apply> </math> </math> "/> </specification> <Unable to render embedded object: File (type="UML:Expression" symbol="&math;#eq"> <operand xmi:type="UML:Expression" symbol="F"/> <operand xmi:type="UML:Expression" symbol="&math;#times"> <operand xmi:type="UML:Expression" symbol="m"/> <operand xmi:type="UML:Expression" symbol="a"/> </operand> </specification> <) not found.- In UML2 specification is multiplicity [0..1]; is there no mechanism for specifications in multiple languages? You /could/ use an 'one-of-n' Expression on these, but that sort of implies the expressions may be evaluated, rather than 'choose the one you can evaluate in your context', which is what you can do with XPath and the language attribute. Should you define multiple constraints in such cases, even though it's the same constraint, expressed in a manner to be processed by different tools? -> <specification xmi:type="UML:OpaqueExpression" language="&modelica;" body="F = m * a"/> </ownedElement> </ownedElement> </ownedElement> </UML:Model> </xmi:XMI> If you are post-processing the XMI using standard XML technologies (XPath, XSLT, XQuery), it is far better to have XML as nested elements rather than escaped strings even using XMI's option for having a <body> element will still require the content to be xsd:string. Can the mapping be changed so that opaque content is string or any element() from a different namespace, allowing MathML and ZedML to be used as opaque constraints and XHTML etc. as comments without breaking the way XML is intended to work? The data value is opaque anyway, and converting XML to escaped XML inside XML is reduces generic tool support and adds no value. This may need to effect the UML core too- changing the type of the opaque string to OpaqueString rather than string; alternatively a tag 'org.omg.xmi.parsedContent' could be added to indicate the string (assumed to be a valid XML document fragement) is serialised as parsed XML content rather than unparsed content. It is understood that Extension elements allow xsd:any content, but in these cases the structured content is the actual value of the attribute as an opaque string, rather than an extension to the model - the body of the contstraint is the MathML, just as much as it would be if it were OCL, rather than the MathML being additional, vendor specific data. Pete

  • Reported: XMI 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Note: The sample XMI in the issue is not valid in that it shows instances of SysML stereotypes nested within their owning UML elements. Furthermore, as the issue later acknowledges, XMI allows properties to be serialized as XML elements instead of XML attributes: this can be forced by setting org.omg.xmi.attribute to true at either the property or Class or package/profile level.

    The issue asks: “In UML2 specification is multiplicity [0..1]; is there no mechanism for specifications in multiple languages? “
    Though not an XMI question, the answer is ‘yes’: in Finalization of UML 2.0, OpaqueExpression::body and OpaqueExpression::language were made multi-valued.

    The substantive issue is how to allow nesting of other XML in the attribute value.
    This can be achieved by using xsd:anyType as the value of the org.omg.xmi.schemaType property. This validates the following:
    <body>
    <math xmlns="math">
    <apply>
    <eq/>
    <ci>F</ci>
    <apply>
    <times/>
    <ci>m</ci>
    <ci>a</ci>
    </apply>
    </apply>
    </math>
    </body>

    This Tag could even be added to the UML metamodel by the SysML Profile XMI to change the serialization specifically for SysML (though this would risk interoperability with UML tools).

    Revised Text:

    • none -

    Disposition: Closed – No Change

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

Unclear serialization of derived data

  • Key: XMI24-17
  • Legacy Issue Number: 8795
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 9.5.3 on p64 has a bullet:
    "Addition to Rule 1 for the EMOF package: in some well-defined cases, derived information has a more compact form than (and should be serialized instead of) the information it is derived from. Examples from the UML2 superstructure are multiplicity and generalization."

    and on p65 has the following bullet:

    "No special serialization rules need to be defined for subsetted Properties. Following EMOF rule 1, when one of the subsetted or subsetting Properties is derived, it is not serialized by default. Properties that are not derived are serialized."

    However the referenced EMOF rule 1 was removed from the XMI submission prior to adoption (it is there in ad/02-12-07): it was in (what is now) section 9.5.2 as the first bullet under the table and stated:
    "• Derived information is not serialized."

    So as things stand the specification does not hang together, since there are references to a non-existent rule. And subsetted properties would always be serialized (unless a tag is used to override)

    In general it does not make sense to serialize derived information since it bloats the file, is redundant, and in the bulk of cases derived Properties are readOnly so cannot be used on import anyway. So the rule from the original submission seems to be make sense - especially as there is the ability to override the default. Not having the rule means that all the derived Properties in UML (for example) would have to be explicitly tagged with serialize=false.

    With respect to the 'well defined cases' where derived is serialized, it should be made clear that it is up to the metamodel definition (e.g. UML) to do the efinition of which derived properties are to be serialized. It is misleading to refer to specifiy examples which may or may not be correct (at time of writing UML does not do this).

    Proposed resolution
    ----------------------------

    1. Reinstate the missing rule by adding a new first bullet in section 9.5.2:

    "• Derived information is not serialized."

    2. In section 9.5.2 replace the bullet:

    "Addition to Rule 1 for the EMOF package: in some well-defined cases, derived information has a more compact form than (and should be serialized instead of) the information it is derived from. Examples from the UML2 superstructure are multiplicity and generalization."

    With

    "Additional to the first bullet in rules for the EMOF package: for some metamodels, it may be desirable to serialize particular derived Properties, since the derived form has a more compact form than (and should be serialized instead of) the information it is derived from. In this case the default behavior can be overridden by setting the serialize tag to 'true' for the derived property and to 'false' for the base Property (or Properties). However this step should be taken with caution since it also requires the derived property to be writeable (isReadOnly=false) and, to be able to import the information, it must be possible to reverse-derive the base information from the derived form."

    3. Section 2.9.8, replace

    "The serialization tag is provided to optionally suppress derived data."

    with:

    "The serialize tag is provided to optionally include derived data."

    4. Section 2.12.1, in the entry for serialize, replace 'boolean' by 'string' in column 2, 'true' by' non-derived' in column 3 and in column 4 replace:

    "If false, suppresses serialization of the MOF construct. Typically applied to derived features."

    with:

    "If 'non-derived' then the MOF construct is serialized unless it is derived. 'true' forces the construct to be serilized regardless of wheher it is derived; and 'false' suppresses the it regardless."

    5. Rule 2h on page 61. Replace:

    "You must not serialize an attribute or reference at all if the value of the org.omg.xmi.serialize tag is "false"."

    With:

    "You must not serialize an attribute or reference at all if the value of the org.omg.xmi.serialize tag is "false"; or the value of that tag is "non-derived" and the attribute or reference has isDerived="true"."

  • Reported: XMI 2.0 — Sun, 22 May 2005 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    This has already been resolved and completed in a previous RTF. Close no change.

    Disposition: Closed – No Change

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

Section: 9

  • Key: XMI24-16
  • Legacy Issue Number: 8438
  • Status: closed  
  • Source: Technolution ( Mick Baggen)
  • Summary:

    The document MOF 2.0 XMI Mapping (ptc/04-06-11) contains some (typographical) errors in the EBNF for XML Document Production (Chapter 9). The proposed corrections are listed below: 1a:XMI ::= "<" 1b:XMINamespace "XMI" 1c:StartAttribs ">" ( 2a:XMIObjectElement)* ( 3:Extension )* "</" 1b:XMINamespace "XMI>" 1b:XMINamespace ::= (1h:NsName ":") ? 1e:Namespaces ::= 1f:XMINamespaceDecl ? ( "xmlns:" 1h:NsName "=’" 1i:NsURI "’" )* 1f:XMINamespaceDecl ::= "xmlns=’http://www.omg.org/XMI’" | "xmlns:" 1h:NsName "=’http://www.omg.org/XMI’" 1g:Namespace ::= ( 1h:NsName ":" )? 2h:FeatureAttrib ::= 2i:XMIValueAttribute | 2j:XMIReferenceAttribute 3:Extension ::= "<" 1b:XMINamespace "extension" (" extender=’" // extender // "’")? (" extenderID=’" // extenderID // "’")? ">" // Extension elements // "</" 1b:XMINamespace "extension>" Furthermore, the notation for placeholders throughout the document is inconsistent. Chapter 8 uses text in enclosed double slashes (//placeholder//), whereas in Chapter 9 (without any introduction) placeholders are shown in italics. Please clarify or correct.

  • Reported: XMI 2.0 — Wed, 2 Mar 2005 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    This is now section 6.4.1. There are more errors in the EBNF rules than pointed out in the original issue, and the current formatting of the EBNF rules in the document allows ambiguous interpretation. Therefore, all EBNF rules in section 6.4.1 will be replaced, and the missing rule “3. Extension” added.

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

Impractical representation of structured datatypes

  • Key: XMI24-18
  • Legacy Issue Number: 8884
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 7.8.7 and example in 9.5.3.1 state that structured datatypes should be represented in a 'flattened' structure as a sequence of strings separated by commas in an XML attribute. Though the rules for the representation are very informally specified through examples only, the normative text saying only: "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 valueSeparator tag."

    This is impractical for several reasons:

    • it does not allow string values that may contain quotes or commas: although the separator may be changed at the attribute level this is not very helpful and there is no means of escaping the separator character;
    • it breaks other XMI rules (for example a multivalued property is forced to use the XML element form and not the XML attribute form);
    • it breaks principles of composability - the same value will appear quite differently if nested in a structure than if it appeared as a property value in its own right;
    • it is against guidelines for designing XML structures and is inconvenient to process using most XML technologies. Indeed it is against the whole principle of XML which is for self-identifying structures and is very fragile to metamodel changes;
    • it fails if any of the properties of the structure have multiplicity of other than 1..1. For example for a DataType PersonName with properties: title [0..1] forenames[1..*] lastName[1] suffixes[0..*] it would be impossible to parse the string e.g. "Duke, John, William, London, Squire";
    • it's trying to optimize the wrong thing: human readability rather than computer processability;
    • it introduces an arbitrary inconsistency with XMI 2.0;

    Proposed change

    Retain the current flattened XMI 2.1 format only as a special option triggered using a new tag org.omg.xmi.flattenStructuredDataTypes (which should default to "false"). This should be restricted in use only for structures whose properties (including nested properties) all have multiplicity of 1..1.

    The default should be to use the XMI 2.0 format for structures: the text should be taken from section 3.5.1 of the XMI 2.0 spec formal/05-05-01.

  • Reported: XMI 2.0 — Tue, 28 Jun 2005 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The serialization of structured datatypes as flattened strings is inconvenient at minimum, but frequently ambiguous so that it cannot be parsed back into correct value assignments to the corresponding fields of the structured datatype. Revert to the class-like serialization of XMI 2.0 and allow flattening only for non-nested structured datatypes with field multiplicity [1..1] as a special case, controlled by a new tag org.omg.xmi.flattenStructuredDataTypes, which shall default to false.

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

Section 2.2.1, rule 6f

  • Key: XMI24-13
  • Legacy Issue Number: 7604
  • Status: closed  
  • Source: ISIS ( Matt Emerson)
  • Summary:

    This problem is preventing me from implementing an XMI 2.0 Schema generator for a MOF 1.4 metamodeling environment. In Section 2.2.1, rule 6f, nested Package elements contained within the complexType definitions of their encapsulating Packages refer to global Package element definitions using the namespace-qualified name of the nested Package. But global Package elements are never associated with their namespace-qualified names, so the reference cannot be resolved. Rule 6a, which defines namespace-qualified Package names, only gets used a single time during schema generation: in rule 6f. This makes it impossible to correctly generate a schema from a metamodel which includes nested Packages.

  • Reported: XMI 2.0 — Tue, 27 Jul 2004 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    As per the resolution to 9694, PackageElements serve no purpose and so this can also clear up this issue – by deleting the whole of rule 6 in section 5.2.

    Revised Text:
    (see resolution of issue 9694)

    Disposition: Closed – Duplicate / Related to 9694

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

Missing rule for generating type or element declarations

  • Key: XMI24-12
  • Legacy Issue Number: 7603
  • Status: closed  
  • Source: ISIS ( Matt Emerson)
  • Summary:

    This problem is preventing me from implementing an XMI 2.0 Schema generator for a MOF 1.4 metamodeling environment. XMI 2.0 Schema: There is no rule for generating type or element declarations for Classifiers nested inside of a Class. MOF Classes don’t get corresponding XMI namespaces. XMI 2.0 seems to ignore the fact that MOF Classes define Namespaces. It is completely valid in MOF to have a Class A which contains an Attribute B and a Class C, where Class C serves as the type of Attribute B. You could also replace ‘Class C’ with any DataType subtype – say ‘CollectionType C’. However, there is no rule for declaring types or elements for nested Classifiers, so the specification does not say how to declare the type of serialized Attribute B. Even if there were a rule for type and element declarations for Classifiers nested within a Class, the nsPrefix and nsURI tags only apply to Packages. Since Classes don’t define XMI namespaces, any nested Classifiers are going to suffer from name collision. If you look at the Eclipse Modeling Framework, you can see how implementers of MDA standards have gotten around this. The MOF-based EMF metamodeling language (ECORE) simply doesn't allow nested Classifiers or DataType subtypes other than EnumerationTypes and PrimitiveTypes. XMI 2.0 is supposed to be designed with MOF 1.4 in mind, so I shouldn't have to limit my metamodeling environment to a subset of the expressive power of MOF just for the purpose of XMI metamodel interchange.

  • Reported: XMI 2.0 — Tue, 27 Jul 2004 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Resolution:
    MOF has never permitted nested classes in metamodels: Class::nestedClassifier was added in UML superstructure. For MOF 2.4 which is based on Superstructure, an explicit constraint was added, as part of MOF Issue 15398, that for metamodels Class::nestedClassifier must be empty. Hence no XMI rule is needed for these.

    Revised Text:

    • none -

    Disposition: Closed – No Change

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

section 4.5.3

  • Key: XMI24-22
  • Legacy Issue Number: 9295
  • Status: closed  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    In section 4.5.3, a paragraph is dedicated to describing a problem with the xmi version:

    Since the XMI model is an instance of MOF, it can be serialized using the same rules as any other MOF model, with one exception. Using the default serialization rules would result in the XMI version attribute appearing twice in XMI elements: once directly from the XMI version attribute, and once through the inclusion of the ObjectAttribs group. Therefore, the version attribute that belongs to the ObjectAttribs attribute group must be excluded from the XMI type declaration. See Section 6.4.1, “Overall Document Structure,” on page 58” for details on how the XMI class is serialized.

    However, in section 4.5.1, it was stated:

    In addition, there are attribute declarations and attributeGroup declarations that must be imported. These include the id attribute, and the IdentityAttribs, LinkAttribs, and ObjectAttribs attribute groups. These constructs are not defined in the XMI model.

    These two statements are inconsistent.

  • Reported: XMI 2.1 — Mon, 23 Jan 2006 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The resolution of issue 9650 removes the version attribute, as the XMI version is always included in the XMI namespace URI. This renders this issue obsolete (duplicate).

    Revised Text:
    (see resolution of issue 9650)

    Disposition: Closed – Duplicate to issue 9650

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

what, if anything, is normative in XMI 2.1

  • Key: XMI24-21
  • Legacy Issue Number: 9294
  • Status: closed  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    In the conformance section of 05-09-01, all mandatory conformance points are given in terms of the rules (for schema and document production) defined in the specification. Are these rules the extent of the normative part of the specification?

    In particular, there is a reference in 05-09-01 (section 2.3.3) to "Use of the normative XML Schema model by instantiation,…" It is unclear what "XML Schema model" refers to. Should there not be a reference to (what I presume to be) the XML Schema standard(s), thush leaving the sum total of the normative nature of the spec the rule sets mentioned above? Or, if the intent is to name the XMI Schema Infoset model in Chapter 8 as normative, why isn't the proper name used, along with a section reference?

    Finally, there are fragments of an XSD file for XMI in section 4. Why is there no XMI.XSD file disseminated by the OMG? I suppose one could put together such a file by copying the text from the spec, but why bother?

  • Reported: XMI 2.1 — Fri, 27 Jan 2006 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    XMI Schemas must be equivalent to those generated by the XMI Schema production rules specified in this document.
    Equivalence means that XMI documents that are valid under a schema produced by the XMI Schema production rules
    would be valid in a conforming XMI Schema and that those XMI documents that are not valid under a schema produced
    by the XMI Schema production rules are not valid in a conforming XMI Schema.

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

Section 6.4.1 5j:Extension

  • Key: XMI24-24
  • Legacy Issue Number: 9396
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    I have a question regarding XMI 2.1 specification, document formal/05-09-01
    I'm not certain that you are the right people to answer, but I'll try.

    Here it is.

    Section 6.4.1. Overall document structure (in EBNF rules production)
    refers to 5j:Extension, however this element is never mentioned in the document. It was defined in XMI 2.0 formal/05-05-01.

    Here is the fragment:

    1a:XMI ::= "<" 1b:XMINamespace .....
    ...
    ( 5j:Extension )*
    ...

    Is this an error in the document, or should we use the 5j:Extension from XMI 2.0 ?

  • Reported: XMI 2.1 — Mon, 13 Feb 2006 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace text as described below

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

timestamp attribute

  • Key: XMI24-23
  • Legacy Issue Number: 9296
  • Status: closed  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    As late as a draft of XMI 1.3 that I have, there were two attributes of the XMI element, verified and timestamp which disappeared from the XMI element in XMI 2.0 and were not restored in XMI 2.1. I'm not sure how useful the verified attribute was, but I have always found the timestamp attribute to be extremely useful in determining the provenance of XMI documents and have set it on my XMI 1.1 exports (most notably the Unisys Rose XMI Addin). I find it very annoying that it is missing from XMI 2.1.

  • Reported: XMI 2.1 — Mon, 23 Jan 2006 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    The RTF consider this as a valuable argument

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

section 4.3.1 (Required XML Declarations),

  • Key: XMI24-20
  • Legacy Issue Number: 9293
  • Status: closed  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    In the referenced document, section 4.3.1 (Required XML Declarations), the text:

    Some of these XML elements contain metadata about the metadata to be transferred, for example, the identity of the model associated with the metadata, ..., whether the metadata has been verified, etc.

    This text is not aligned with either the model classes defined in section 4.5.2 (XMI Model Classes) or the implicit XMI XSD defined in section 4.5.5 (Documentation). The reason for this is that information about the model, metamodel, verification, etc, appears to have been dropped from earlier versions of XMI. My preference would be to restore it (to the extent that it makes sense in the UML2/MOF2 world), but at the least the sections should be aligned.

  • Reported: XMI 2.1 — Fri, 27 Jan 2006 05:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Delete text as described below

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

Section: 4.4

  • Key: XMI24-19
  • Legacy Issue Number: 9074
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    In section 4.4, the XML header is incorrect. Instead of <? XML version=”1.0” ?> it should be <?xml version="1.0"?> and instead of <? XML version=”1.0” ENCODING=”UCS-2” ?> it should be <?xml version="1.0" encoding="ISO-10646-UCS-2"?> Rationale: The W3C XML recommendation specifies in production 23, that there is no space between <? and XML, and that XML is to be written in lower case. In production 80, encoding is specified as lower case. Section 4.3.3 specifies that ISO-10646-UCS-2 should be used to denote UCS-2. If possible, QUOTATION MARK should be used in the PDF file for the quoting the parameter values.

  • Reported: XMI 2.1 — Tue, 4 Oct 2005 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    This is a duplicate of issue number 10112. Resolve with no change.

    Disposition: Merged / Duplicate

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

Section 4.5.2

  • Key: XMI24-27
  • Legacy Issue Number: 9624
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The String datatype is the data type for strings in the MOF model with XML Schema data type of "http://www.w3.org/2001/ XMLSchema#string." The Integer datatype is the data type for integers in the MOF model with XML Schema data type of "http://www.w3.org/2001/XMLSchema#integer."

    This should instead reference the PrimitiveTypes package used by MOF Core and UML Infra.

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    Replace text as described below

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

Section: 4.9.3

  • Key: XMI24-26
  • Legacy Issue Number: 9557
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The example shows two elements with tags ownedElement which are of types UML:Class and UML:Datatype. Since XML presumes that the tag defines the type it is difficult to see how ownedElement could be defined using XSD. I suggest allowing something like the following as an option: <UML:Model name="model1" xmi:id="id1"> <UML:Class xmi:role="ownedElement" name="class1" xmi:id="id2"> <UML:Attribute xmi:role="feature" name="attribute1" type="type1"/> </UML:Class> <UML:Datatype xmi:role="ownedElement" name="Integer" xmi:id="type1"/> </UML:Model> This would eliminate the need to define an element in XSD, and the need to wait for attributes to determine type when using SAX. And, since an XSL style sheet to convert between to two forms is a trivial exercise, impact should be minimal.

  • Reported: XMI 2.1 — Wed, 12 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    This proposed enhancement would break backward compatibility. Close no change.

    Disposition: Closed – No Change

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

Urgent issue on XMI 2.1 -inconsistency between XMI metamodel and quoted XSD

  • Key: XMI24-25
  • Legacy Issue Number: 9512
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This references formal/05-09-01.
    It is urgent since it represents inconsistencies in the specification - a resolution of which is required in order to avoid randomly inconsistent and non-interoperable implementations.

    This version of the specification includes a metamodel for the XMI element, in section 4.5, so that its serialization can use the same metamodel-driven rules as any other metamodel element. In fact section 4.5.1 states "When the XMI model is generated as an XML Schema following the XMI schema production rules, the result is a set of XML element and attribute declarations. ".
    However section 5.2.2 contains 'Fixed Schema Declarations' that are inconsistent with this, and in fact seem to be carried over unchanged from XMI 2.0 (as indicated by the fixed version number:
    <xsd:attribute name="version" type="xsd:string" use="optional" fixed="2.0" form="qualified"/>

    In addition to the wrong version number the XMI element in 5.2.2 is missing the metamodel properties XMI::documentation, XMI:difference and XMI::extension.
    Also the fact that only XML elements are used should be reflected.

    Proposed resolution
    Fix the specification to match the XMI metamodel. This should also have XMI tags added to reflect the serialization of the XMI properties as elements only. The missing XMI.xsd file should be produced as a separate file and made available as both an OMG document and at the correct URL. The fragments of this XSD that appear in the document need to be changed.

  • Reported: XMI 2.1 — Wed, 5 Apr 2006 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    This issue was resolved in version 2.1.1. Close no change.

    Disposition: Closed – No Change

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

Type specification of MOF attributes

  • Key: XMI24-11
  • Legacy Issue Number: 7602
  • Status: closed  
  • Source: ISIS ( Matt Emerson)
  • Summary:

    This issue is preventing me from implementing an XMI 2.0 Schema generator for a MOF 1.4 metamodeling environment. The specification contradicts itself regarding the type specification of MOF Attributes. >From section 1.8.4: “The XML element corresponding to the attribute is declared in the content of the complexType corresponding to the class that owns the attribute. The type specification is either an XML schema data type, an enumeration data type, or a class from the metamodel.” Then, in section 2.2.1, rule 4d: “The type is “xsd:string” for simple attributes, the name of an enumeration for enumerated attributes, or part of the value of the org.omg.xmi.schemaType tag, if present.” I have no idea what the specification means by “simple attribute” (the phrase appears just that one time in the entire document), but the two statements above are clearly out of sync and confusing. Also, the type of an attribute might be something other than a metamodel Class, PrimitiveType, or EnumerationType in MOF 1.4: it might for example be a CollectionType or an AliasType. Rules are provided for serializing these other DataType subtypes as Classes, but they themselves are not metamodel Classes.

  • Reported: XMI 2.0 — Tue, 27 Jul 2004 04:00 GMT
  • Disposition: Resolved — XMI 2.4
  • Disposition Summary:

    (now sections 4.8.4 and 5.2.1)
    “simple attribute” is actually a well established term, meaning an attribute which can be represented as a single value.

    Also the MOF 1.4 types mentioned in the issue: CollectionType and AliasType are no longer present in MOF 2.x

    See resolution for issue 8884 regarding structured DataTypes.

    Revised Text:

    • none -

    Proposed Disposition: Closed – No Change

  • 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 ( Dr. Nicolas F. Rouquette)
  • Summary:

    Canonical XMI, ptc/2013-08-28, states that xmi:uuid must be always present (B2, #5) except for values that are datatypes (B2, #7).
    What does "values that are datatypes" in B2 #7 mean?

    Are auxiliary XML elements like mofext:Tag and stereotype instances considered "values that are datatypes" ?

    If not, then according to B2 #5, these auxiliary XML elements must have identification attributes (xmi:id and xmi:uuid).

    Historically, the OMG used rather arbitrary conventions for producing the xmi:id of mofext:Tag — not a big deal because nobody really refers to them. However, these arbitrary conventions break the repeatability and reproducibility of Canonical XMI!

    The Canonical XMI document production rules in B4 are incomplete: they should be augmented to specify the serialization, identification and ordering of auxiliary XML elements.

    Consider augmenting the Canonical XMI specification B6 with the following rules:

    Generate the xmi:id and xmi:uuid for mofext:Tag by appending "_mofext.Tag" to the xmi:id and xmi:uuid respectively of the referenced element.

    Generate the xmi:id and xmi:uuid for stereotype instances by concatenating the xmi:id and xmi:uuid respectively of the stereotype with that of the element on which the stereotype is applied.

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

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

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

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

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

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

  • Key: XMI24-8
  • Legacy Issue Number: 18838
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. 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

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

XMI issue - root elements for XMI Schemas

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

    At the moment every metaclass has a XML element generated, allowing it to be the root of any interchange.

    While this flexibility might be useful in some cases, it clogs up the XSD with elements that will never get used in practice.

    Proposed resolution:

    Define two boolean XMI Tags:

    1. To define whether root elements should be restricted: org.omg.xmi.restrictRoots (defaults to true)

    2. To mark classifiers (classes or associations) as being potential roots: org.omg.xmi.rootElement (defaults to false)

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

metamodel for XML Schema

  • Key: XMI24-2
  • Legacy Issue Number: 9637
  • Status: open  
  • Source: Adaptive ( Mr. 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

Revise XMI examples in 9.4

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

    These examples in the XMI spec s have nothing to do with modeling but are related to Departments and stoplights.

    Furthermore they do not show xmi:ids and xmi:types.

    They should also illustrate some of the more sophisticated cases such as that introduced by Issue 16330.

    Finally, the Figures in Section 9.4 are all labeled Figure 1

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

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

  • Key: XMI24-5
  • Legacy Issue Number: 16257
  • Status: open  
  • Source: Adaptive ( Mr. 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

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

Name transformation

  • Key: XMI24-4
  • Legacy Issue Number: 15887
  • Status: open  
  • Source: Adaptive ( Mr. 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

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

  • Key: XMI24-124
  • Legacy Issue Number: 15613
  • Status: open  
  • Source: Adaptive ( Mr. 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