XML Metadata Interchange Avatar
  1. OMG Specification

XML Metadata Interchange — All Issues

  • Acronym: XMI
  • Issues Count: 232
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
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
XMI21-27 MagicDraw's XMI namespace URI XMI 2.1 XMI 2.1.1 Resolved closed
XMI21-26 element /xmi:XMI/xmi:Documentation/@xmi:Exporter XMI 2.1 XMI 2.1.1 Resolved closed
XMI21-25 include an explicit attributeFormDefault setting for the XML Schema XMI 2.1 XMI 2.1.1 Resolved closed
XMI11-99 MOF and UML DTDs XMI 1.0 XMI 1.1 Resolved closed
XMI11-98 Reference to ""restrictions"" is unclear." XMI 1.0 XMI 1.1 Resolved closed
XMI13-21 XMI Schema FTF issue - referenceless composition does not export components XMI 1.2 XMI 1.3 Resolved closed
XMI13-20 Default Value of contentType Tag Should Be Nil XMI 1.2 XMI 1.3 Resolved closed
XMI13-19 Type Declaration Unnecessarily Duplicated XMI 1.2 XMI 1.3 Resolved closed
XMI13-22 XMI Schema FTF issue - Major changes in SOAP encoding rules XMI 1.2 XMI 1.3 Resolved closed
XMI13-18 Full compliance with XLink XMI 1.2 XMI 1.3 Resolved closed
XMI13-14 Use separate attribute for XMI vs data 'version' XMI 1.2 XMI 1.3 Resolved closed
XMI13-16 Section 9.2.1 of the XMI production of XML Schema XMI 1.2 XMI 1.3 Resolved closed
XMI13-17 Unclear software compliance XMI 1.2 XMI 1.3 Resolved closed
XMI13-15 Wrong cardinality in Schema for Difference.container reference XMI 1.2 XMI 1.3 Resolved closed
XMI13-10 Describe Tags further XMI 1.2 XMI 1.3 Resolved closed
XMI13-12 Level of required support for XPointer XMI 1.2 XMI 1.3 Resolved closed
XMI13-11 Clarify Management of Tags in MOF Models XMI 1.2 XMI 1.3 Resolved closed
XMI13-13 Namespace logical identifiers should include version XMI 1.2 XMI 1.3 Resolved closed
XMI13-9 Clearer support for data as well as metadata XMI 1.2 XMI 1.3 Resolved closed
XMI13-8 Generating both Attributes and Elements for MOF attributes/references XMI 1.2 XMI 1.3 Resolved closed
XMI13-7 Combined document structure unclear XMI 1.2 XMI 1.3 Resolved closed
XMI13-6 Keeping pace with XMI 1.x and MOF 1.x XMI 1.2 XMI 1.3 Resolved closed
XMI13-5 Update Section 9.3.1 to reference Chapter 4 XMI 1.2 XMI 1.3 Resolved closed
XMI13-4 Aggregations are Undifferentiated XMI 1.2 XMI 1.3 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
XMI11-94 Multiple Inheritance hard to handle in XMI XMI 1.0 XMI 1.1 Resolved closed
XMI11-97 . XMI has specific rules for attribute ordering. Can this be relaxed? XMI 1.0 XMI 1.1 Resolved closed
XMI11-96 Is it valid to use alternative DTD generation rules? XMI 1.0 XMI 1.1 Resolved closed
XMI11-95 How should null values be transmitted XMI 1.0 XMI 1.1 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
XMI12-108 General inconsistencies between EBNF and pseudo-code in Chapter 7 XMI 1.1 XMI 1.2 Resolved closed
XMI12-107 Element name based on feature instead of class XMI 1.1 XMI 1.2 Resolved closed
XMI12-100 Question of XML element declarations XMI 1.1 XMI 1.2 Resolved closed
XMI12-99 "Define ""short name""" XMI 1.1 XMI 1.2 Resolved closed
XMI12-103 Use of UUIDs and MOF UUIDs needs expansion. XMI 1.1 XMI 1.2 Resolved closed
XMI12-102 OCL and pseudo-code not updated XMI 1.1 XMI 1.2 Resolved closed
XMI12-97 Clarify multiplicity in the XML element declaration. XMI 1.1 XMI 1.2 Resolved closed
XMI12-96 Clarify multiplicity in the XML element declaration. XMI 1.1 XMI 1.2 Resolved closed
XMI12-106 Nested classes XMI 1.1 XMI 1.2 Resolved closed
XMI12-105 Backwards compatibility XMI 1.1 XMI 1.2 Resolved closed
XMI12-104 MOF and UML tagged value alignment. XMI 1.1 XMI 1.2 Resolved closed
XMI12-95 Clarify of fixed DTD declarations requirement. XMI 1.1 XMI 1.2 Resolved closed
XMI12-101 OCL and pseudo-code not updated XMI 1.1 XMI 1.2 Resolved closed
XMI12-98 Pseudo-code for GetReferenceMultiplcity needs updating. XMI 1.1 XMI 1.2 Resolved closed
XMI12-119 How does an XMI document represent multi-valued attribute values? XMI 1.1 XMI 1.2 Resolved closed
XMI12-118 More multiplicity inconsistencies in DTD ruleset 1 XMI 1.1 XMI 1.2 Resolved closed
XMI12-120 Encoding of "any" values in XMI XMI 1.1 XMI 1.2 Resolved closed
XMI12-122 Encoding a union value that has no field value. XMI 1.1 XMI 1.2 Resolved closed
XMI12-121 DTD productions for names of Classes in nested Packages XMI 1.1 XMI 1.2 Resolved closed
XMI12-111 Why do we need 3 XMI DTD rulesets? XMI 1.1 XMI 1.2 Resolved closed
XMI12-110 Multiplicities inconsistency in the DTD rulesets XMI 1.1 XMI 1.2 Resolved closed
XMI12-114 Which Classes doe PkgClasses include? XMI 1.1 XMI 1.2 Resolved closed
XMI12-113 Description of ClassReferences and ClassCompositions productions XMI 1.1 XMI 1.2 Resolved closed
XMI12-117 DTD attributes for AssociationEnds in un-referenced Associations XMI 1.1 XMI 1.2 Resolved closed
XMI12-116 Does PkgContents include XMI.extension? XMI 1.1 XMI 1.2 Resolved closed
XMI12-115 Does PkgPackages contain nested Packages from super-Packages? XMI 1.1 XMI 1.2 Resolved closed
XMI12-109 Multi-valued Attributes in the simple DTD ruleset XMI 1.1 XMI 1.2 Resolved closed
XMI12-112 Inconsistencies in ClassElementDef for DTD ruleset 1 XMI 1.1 XMI 1.2 Resolved closed
XMI12-94 P 9-175, question regarding EBNF XMI 1.1 XMI 1.2 Resolved closed
XMI12-128 Explain Possible Uses of Entity Definitions in XMI DTDs XMI 1.1 XMI 1.2 Resolved closed
XMI12-126 Completeness of TypeCode and Any support XMI 1.1 XMI 1.2 Resolved closed
XMI12-125 XMI handling of type info for CORBA any -- too complex XMI 1.1 XMI 1.2 Resolved closed
XMI12-124 Representing object references in an XMI document XMI 1.1 XMI 1.2 Resolved closed
XMI12-123 Representing type information for CORBA anys XMI 1.1 XMI 1.2 Resolved closed
XMI12-127 Update XMI 1.2 to reflect MOF 1.4 updates XMI 1.1 XMI 1.2 Resolved closed

Issues Descriptions

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

MagicDraw's XMI namespace URI

  • Key: XMI21-27
  • Legacy Issue Number: 10774
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It looks like there is a small bug in MagicDraw’s implementation of XMI.

    MagicDraw's XMI namespace URI is http://schema.omg.org/spec/XMI/2.1

    In the standard the OMG has http://www.omg.org/XMI

    The URIs are different and incompatible. My MagicDraw version is 12 Enterprise. The version of the OMG XMI specification is:
    http://www.omg.org/docs/formal/05-09-01.pdf. This is OMG XMI v2.1.

    The suspected bug is registered with MagicDraw

  • Reported: XMI 2.1 — Thu, 15 Feb 2007 05:00 GMT
  • Disposition: Resolved — XMI 2.1.1
  • Disposition Summary:

    No Data Available

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

element /xmi:XMI/xmi:Documentation/@xmi:Exporter

  • Key: XMI21-26
  • Legacy Issue Number: 10773
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There is another bug in the XMI:

    The element /xmi:XMI/xmi:Documentation/@xmi:Exporter should be in lower case according to the OMG XMI v2.1 specification. The element should be renamed "exporter".

    This can be verified at http://www.omg.org/docs/formal/05-09-01.pdf on indicated page 11 (page 23 of the PDF).

    The same bug is present for /xmi:XMI/xmi:Documentation/@xmi:ExporterVersion, which also needs turning into lower case.

    This bug seems prevalent throughout the MagicDraw XMI.

  • Reported: XMI 2.1 — Thu, 15 Feb 2007 05:00 GMT
  • Disposition: Resolved — XMI 2.1.1
  • Disposition Summary:

    No Data Available

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

include an explicit attributeFormDefault setting for the XML Schema

  • Key: XMI21-25
  • Legacy Issue Number: 10772
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The OMG XMI v2.1 specification does not include an explicit attributeFormDefault setting for the XML Schema. According to the XML Schema definition this means the attribute form defaults to "unqualified".
    http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-schema

    However MagicDraw XMI files have qualified attributes. The MagicDraw XMI files are therefore invalid against the XMI Schema. IMHO this may be a bug.

    For example this: <xmi:Extension xmi:Extender="MagicDraw UML 12.0"
    xmi:ExtenderID="MagicDraw UML 12.0">

    Should be this: <xmi:Extension Extender="MagicDraw UML 12.0"
    ExtenderID="MagicDraw UML 12.0">

  • Reported: XMI 2.1 — Thu, 15 Feb 2007 05:00 GMT
  • Disposition: Resolved — XMI 2.1.1
  • Disposition Summary:

    No Data Available

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

MOF and UML DTDs

  • Key: XMI11-99
  • Legacy Issue Number: 4393
  • Status: closed  
  • Source: International Business Machines ( Mr. Tim Grose)
  • Summary:

    I propose that the XMI RTF not regenerate UML and MOF DTDs, for the
    following reasons:

    1) UML 1.1 and MOF 1.1 are now out of date.
    2) Both the UML RTF and the MOF RTF are now creating their own DTDs, so it
    is not appropriate for the XMI RTF to continue to create them.

  • Reported: XMI 1.0 — Tue, 3 Jul 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.1
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 19:58 GMT

Reference to ""restrictions"" is unclear."

  • Key: XMI11-98
  • Legacy Issue Number: 3828
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    The second and third paragraphs in 6.6.1 define exactly how to use Namespaces in XMI DTDs and serve as both the restriction and the solution. Accept. Clarify to indicate that the following text is the definition of the restriction.

  • Reported: XMI 1.0 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.1
  • Disposition Summary:

    Accept. Clarify to indicate that the following text is the definition of the restriction.

  • Updated: Sat, 7 Mar 2015 19:58 GMT

XMI Schema FTF issue - referenceless composition does not export components

  • Key: XMI13-21
  • Legacy Issue Number: 5321
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This I think brings the spec into line with what implementations do in
    practice!

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

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

    Proposed Resolution
    -------------------

    1. Change the description of production rule 2a in 6.3.2 (p6-101) from:
    "The content elements are the XML representations of top level objects,
    classifier level attributes, and other links."
    To:
    "The contents are the XML representations of top level objects, classifier
    level attributes, and other links. The top level objects will include those
    which have a composite link with no reference from the composite to
    component."

    2. Add a new sentence after the first to rule 5 in 6.3.2 (p6-107) changing
    the start of the rule from:
    "The contents of an object are the attributes, references, and compositions
    that are serialized as XML elements, as well as the extensions."
    To:
    "The contents of an object are the attributes, references, and compositions
    that are serialized as XML elements, as well as the extensions. Note that
    'contents' (component objects which are reached via composite links) without
    a composite reference are not subject to this production rule and so not
    written as nested elements: instead they are written as top-level elements."

  • Reported: XMI 1.2 — Wed, 22 May 2002 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see below

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Default Value of contentType Tag Should Be Nil

  • Key: XMI13-20
  • Legacy Issue Number: 5233
  • Status: closed  
  • Source: International Business Machines ( Mr. Tim Grose)
  • Summary:

    Currently, the XML schema generation rules for references and compositions
    indicate that the elements corresponding to these MOF constructs can have
    any content and any attributes, unless the useSchemaExtensions tag is true,
    or the contentType tag is complex.

    The default value of the contentType tag is complex. This means that
    elements corresponding to references and compositions are set to the schema
    type corresponding to the MOF class that is their type in default XMI 2.0
    schemas.

    For example, if there is a MOF model with a class Container that is related
    via a composition relationship to a class called Part, and the Container
    class has a reference called part, the relevant part of the Container type
    is the following by default:

    <xsd:complexType name="Container">
    ...
    <element name="part" type="Part"/>
    ...
    </xsd:complexType>

    If the class Part has subclasses, Part1 and Part2, each of which has local
    attributes and references, the default declaration of Container is as
    above. Also, the types in a schema corresponding to Part1 and Part2 are not
    related by schema extension, since the default value of useSchemaExtensions
    is false.

    However, documents in which Part1 or Part2 are serialized in the "part"
    element (and values of the local attributes and references are serialized
    for them), do not validate with the default schema, because they are not of
    type "Part". I believe that default XMI 2.0 schemas should validate
    documents with either Part, Part1, or Part2 serialized in the "part"
    element.

    To avoid this problem, I propose that the default value of the contentType
    tag be no value (nil), rather than complex.

    I believe we intended that the type of elements such as "part" would allow
    any content in default XMI 2.0 schemas, and if someone knows about XML
    schemas, that person can use the XMI tags to create schemas that are more
    restrictive than the default schemas.

  • Reported: XMI 1.2 — Fri, 26 Apr 2002 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Type Declaration Unnecessarily Duplicated

  • Key: XMI13-19
  • Legacy Issue Number: 5090
  • Status: closed  
  • Source: International Business Machines ( Mr. Tim Grose)
  • Summary:

    n the XMI 2.0 specification, the default schema production rules require
    each reference to include an anonymous type:

    <xsd:complexType>
    <xsd:choice minOccurs="0" maxOccurs="unbounded">
    <xsd:any processContents="skip"/>
    </xsd:choice>
    <xsd:anyAttribute processContents="skip"/>
    </xsd:complexType>

    This results in large schemas and does not take advantage of the ability to
    reuse types. Why not put a type in the fixed declarations schema and reuse
    it instead?

  • Reported: XMI 1.2 — Mon, 25 Mar 2002 05:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    Add a type called Any to the XMI namespace

  • Updated: Sat, 7 Mar 2015 04:37 GMT

XMI Schema FTF issue - Major changes in SOAP encoding rules

  • Key: XMI13-22
  • Legacy Issue Number: 5325
  • Status: closed  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    The W3C XML Protocol Working Group has made available a SOAP
    Version 1.2 Part 2: Adjuncts Editors' Copy dated May 14 2002. In this new
    version of the spec, the section describing the SOAP encoding rules has
    changed dramatically from the December 2001 version. At least some of the
    XMI Production of XML Schema references to the SOAP encoding are invalid.
    For example, they have replaced "href" with "ref" that apparently does not
    support URIs as values. There may be more changes; it will take some time
    to digest in its new form.

    Proposed resolution: Remove references to SOAP in the XMI Production of
    XML Schema specification. In a later revision, we can add corrected
    references back in.

  • Reported: XMI 1.2 — Thu, 23 May 2002 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Full compliance with XLink

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

    Now XLink is a W3C Recommendation, compliance is sensible. The aim should be
    that the XMI links can be procesed/managed by a generic XLInk processor. See
    Dave Carlson book 'Modeling Application with XML' (p135) for suggestions.

  • Reported: XMI 1.2 — Tue, 20 Nov 2001 05:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Use separate attribute for XMI vs data 'version'

  • Key: XMI13-14
  • Legacy Issue Number: 4641
  • Status: closed  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    4.5.3 Why not avoid the clash with the other "version" attribute by giving
    them different names e.g. "xmiversion"?

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Section 9.2.1 of the XMI production of XML Schema

  • Key: XMI13-16
  • Legacy Issue Number: 4663
  • Status: closed  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    Section 9.2.1 of the XMI production of XML Schema has two sentences. The
    second sentence does not make sense as written.

  • Reported: XMI 1.2 — Mon, 5 Nov 2001 05:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    Clarify.

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Unclear software compliance

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

    Chapter 9 refers largely to the conformance of XMI Schemas and Documents and
    little regarding what it means for a software implementation/tool to be
    conformant (except points in 9.3 though it's not clear from their form).
    See similar issues for XMI 1.3 for suggested resolutions.

  • Reported: XMI 1.2 — Tue, 20 Nov 2001 05:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    See revised text

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Wrong cardinality in Schema for Difference.container reference

  • Key: XMI13-15
  • Legacy Issue Number: 4643
  • Status: closed  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    4.5.7: The schema appears to allow multiple values (xsd:IDREFS) for the
    'container' reference whereas the model is 0..1.

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Describe Tags further

  • Key: XMI13-10
  • Legacy Issue Number: 4636
  • Status: closed  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    In general it would be useful to enhance the summary table in 4.10.1 to
    indicate the MOF constructs to which they apply. In general it would be
    useful to use the Profile notation introduced in UML 1.4: as if it were a
    "XMI Profile for MOF". It would be useful to do this at the MOF level and
    not confuse it with the use of UML.
    It would also be useful to indicate which tags expand and which contract
    the set of allowed output.

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    add a section to summarize the scope of each tag, and the constructs affected.

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Level of required support for XPointer

  • Key: XMI13-12
  • Legacy Issue Number: 4639
  • Status: closed  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    It's not clear from section 4.9.2 exactly what the set of valid choices is:
    it should clarify the intention that any Xlink functionality is available
    and this section is offering some guidance. (However start of 4.9 states
    that Xlink is not required as a prerequisite).
    Support for full XPointer capabilities potentially places too great a
    burden on XMI importers (e.g. it could require a repository to support
    Xpointer as a query language): some level of optionality should be
    specified.

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Clarify Management of Tags in MOF Models

  • Key: XMI13-11
  • Legacy Issue Number: 4637
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Section 4.7.2 states that "enforceMin(Max)imumMultiplicity" should be
    attached to the MOF metamodel. This does not seem appropriate: the required
    validation is most likely to vary by import context, not be static for
    every application of the metamodel. The potential alternative of having a
    set of 'validation options' that can be specified as part of the import
    operation is that these options also affect the schema generated and need
    to be available to tools.
    The submitters have in mind use of separately packaged tag sets separate
    from the metamodel: these ideas should be explained.
    The specification should also explain a simple way for tools to know
    exactly what are the options used in an XMI document.

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    Clarify by adding text

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Namespace logical identifiers should include version

  • Key: XMI13-13
  • Legacy Issue Number: 4640
  • Status: closed  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    4.7.1: if the logical namespace name is meant to be persistent and
    unchanging then surely it should include the version number. And arguably
    the XMI version since the namespace will differ between 1.1 and 2.0. (e.g.
    UML="org.omg/standards/UML/1.4/xmi2.0").

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    In the examples in section 4.7.1, use the new OMG directory structure

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Clearer support for data as well as metadata

  • Key: XMI13-9
  • Legacy Issue Number: 4635
  • Status: closed  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    Despite the 'Metadata' in its name, XMI has often been proposed as a
    model-driven approach to XML for Data interchange: this is also reflected
    in the car-related examples in the submission and indeed in the RFP
    (section 6.1.1).
    Is this valid and if so should it be reflected in the evaluation or even
    the name of the standard?
    For example, in 4.5.6 it should also be explained how the (Meta)Model
    elements are to be used (if at all) when the XMI file is being used for
    instance data (e.g. actual cars as opposed to the model for cars). I
    presume that the MetaModel element would refer to the Cars model and the
    Model element would somehow describe this set of cars (e.g. "Cars in the
    company car pool as of 1/1/2001"). It might be better if these element
    names were not wedded to the 4-layer approach: more generally "Model" would
    be better worded "Content" and "MetaModel" would be better named "Model"
    (i.e. the metadata for the content).
    It would help if the M2, M1, and M0 examples were given for the same model.

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Generating both Attributes and Elements for MOF attributes/references

  • Key: XMI13-8
  • Legacy Issue Number: 4634
  • Status: closed  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    Section 4.7.4 generates both XML attribute and XML element definitions for
    appropriate MOF attributes - regardless of the MOF tag (or the default
    value) rom the metamodel.

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    Add references to the "attribute", and "element" tags in section 4.10.1.

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Combined document structure unclear

  • Key: XMI13-7
  • Legacy Issue Number: 4633
  • Status: closed  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    Though the document does say it builds on XMI 1.1 it's not clear how the 2
    specs are to be read together; neither does it seem complete as a new
    replacement XMI specification (e.g. it's missing some of the introduction
    and usage scenarios that are in the 1.1 spec). [NB should it not build on
    the "formal/" XMI 1.1 specification not the submitted one?]
    Neither the cumbersome name for the specification (which should be changed)
    and the headings used for the document do not help: for example section 4
    applies to XMI 2.0 schemas only.
    It might have been clearer to have 2 separate specifications: an add-on to
    XMI 1.1 that just added XMI 1.1-compliant Schema generation. And,
    separately, a complete stand-alone specification for XMI 2.0.

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Keeping pace with XMI 1.x and MOF 1.x

  • Key: XMI13-6
  • Legacy Issue Number: 4612
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    XMI for XML Schemas should attempt to keep up with agreed issue resolutions
    from XMI and MOF. This should not only include substantive changes but
    relevant interpretations and clarifications.
    In the short term there will be existing adopted changes in XMI 1.2 and MOF
    1.4.

    One option might be to keep a 'shadow' list of XMI/MOF resolved issues with
    an indication of whether there is an impact on XMI/XMI for XML Schemas and
    an indication of progress for the latter.

  • Reported: XMI 1.2 — Tue, 9 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Update Section 9.3.1 to reference Chapter 4

  • Key: XMI13-5
  • Legacy Issue Number: 4608
  • Status: closed  
  • Source: International Business Machines ( Dr. Stephen Brodsky, Ph.D)
  • Summary:

    This issue was raised by Peter Walker from Sub during his Architecture
    Board evaluation of XMI Production of XML Schema. This is the only issue
    raised by the AB.

    Section 9.3.1 refers to Sections 6.5, 6.9, and 6.10. These sections should
    be 4.5, 4.9, and 4.10. Also, Jeff Mischkinsky suggested that the titles of
    the referenced sections be included in the revised text.

  • Reported: XMI 1.2 — Mon, 8 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Aggregations are Undifferentiated

  • Key: XMI13-4
  • Legacy Issue Number: 4597
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Applying Production Rule 5i in 6.3.5 does not result in any indication as to
    the actual association/reference being used. If the example were extended to
    add another composite reference from Department to Employee called
    casualWorkers then there would be no way to differentiate casual workers
    from employees for a department in the XMI document.

  • Reported: XMI 1.2 — Sun, 7 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    The example (6-10) has a typo in it.

  • Updated: Sat, 7 Mar 2015 04:37 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

Multiple Inheritance hard to handle in XMI

  • Key: XMI11-94
  • Legacy Issue Number: 2854
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: THe background it is the use of XMI for interchange of warehouse
    information. The person prototyping
    the exchange is Brain Volpi so if you have follow on questions, please
    copy him since I am on vacation for the next two weeks.

    1. We are using UML to define the meta models and the created the DTD"s
    and document streams.

    • our model contains multiple inheritance which is hard to handle
      in XMI. Does anyone have any
      comments or suggestion on the mapping to XMI we should consider.
    • our model contains UML interface definitions which we have mapped
      into abstract classes
      any comments on a better way to do this?
    • UML has ordered associations and we are currently assuming the
      XMI stream will always be
      in the correct order. Is this valid?
  • Reported: XMI 1.0 — Fri, 20 Aug 1999 04:00 GMT
  • Disposition: Resolved — XMI 1.1
  • Disposition Summary:

    resolved in XMI 1.1 RTF

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

. XMI has specific rules for attribute ordering. Can this be relaxed?

  • Key: XMI11-97
  • Legacy Issue Number: 2857
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 4. XMI has specific rules for attribute ordering. Can this be relaxed?

  • Reported: XMI 1.0 — Fri, 20 Aug 1999 04:00 GMT
  • Disposition: Resolved — XMI 1.1
  • Disposition Summary:

    resolved in XMI 1.1 RTF

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

Is it valid to use alternative DTD generation rules?

  • Key: XMI11-96
  • Legacy Issue Number: 2856
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 3. XMI uses containment rules to drive the document generation process.
    Is it valid to use alternative
    DTD generation rules that allow for reference semantics where we can
    use bi-directional references
    instead of the single direction references you are limited to with
    containment. We need roles at both
    ends.

  • Reported: XMI 1.0 — Fri, 20 Aug 1999 04:00 GMT
  • Disposition: Resolved — XMI 1.1
  • Disposition Summary:

    resolved in XMI 1.1 RTF

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

How should null values be transmitted

  • Key: XMI11-95
  • Legacy Issue Number: 2855
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2. How should null values be transmitted. Currently we don"t transmit
    them. This is really the issue of
    partial models versus null values that Steve raised in the original
    submission discussions.

  • Reported: XMI 1.0 — Fri, 20 Aug 1999 04:00 GMT
  • Disposition: Resolved — XMI 1.1
  • Disposition Summary:

    resolved in XMI 1.1 RTF

  • 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

General inconsistencies between EBNF and pseudo-code in Chapter 7

  • Key: XMI12-108
  • Legacy Issue Number: 3866
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    1) The pseudo-code specification in 7.2.2 contains embedded EBNF, that
    is quite distinct from the earlier EBNF. It uses different lexical
    conventions (e.g. 'S' and 'Q' meta-syntactic elements), the productions
    have different numbering, and the non-terminal symbols are different.
    The two sets of EBNF should be identical.

    2) All "," comma separated lists defined in the pseudo-code should be
    replaced with "|" separated lists.

    3) Multiplicities for XML elements affect the DTD according to the
    pseudo-code, but not according to the EBNF. The text of 6.6.5 (last
    para) implies that the EBNF is correct. Fix the pseudo-code.

    4) In the pseudo-code, it is unclear whether the phrase "parent Package"
    means the Package containing the given Package, or a Package this
    Package inherits from, or both. For example, in the description and
    pseudo-code for GetClassLevelAttributes.

  • Reported: XMI 1.1 — Tue, 19 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

Element name based on feature instead of class

  • Key: XMI12-107
  • Legacy Issue Number: 3854
  • Status: closed  
  • Source: International Business Machines ( Dr. Stephen Brodsky, Ph.D)
  • Summary:

    Would allow more flexible customization of XMI serialization by supporting both of the most common serialization preferences.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Close, no change

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

Question of XML element declarations

  • Key: XMI12-100
  • Legacy Issue Number: 3830
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Question if both XML element and XML attribute declarations are meant to be defined. No change. The declarations present in the text are intentional.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    No change. The declarations present in the text are intentional

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

"Define ""short name"""

  • Key: XMI12-99
  • Legacy Issue Number: 3829
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    "Section 6.6.1, the first sentence of the first full paragraph on p-67 uses the term ""short name""" "Accept. Omit the reference to ""short name."" "

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Accept. Replace "short name" with "name".

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

Use of UUIDs and MOF UUIDs needs expansion.

  • Key: XMI12-103
  • Legacy Issue Number: 3833
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    . Item 20/2924 of XMI 1.1 RTF was not fully completed. Apply to sections 6.5.1 and rule 7e of document production. Accept. Clarify the use of UUIDs.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    see above

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

OCL and pseudo-code not updated

  • Key: XMI12-102
  • Legacy Issue Number: 3832
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    "The OCL and pseudo-code ""maintained for reference"" are not updated to XMI 1.1. Example, Section 9.5.4" .

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

Clarify multiplicity in the XML element declaration.

  • Key: XMI12-97
  • Legacy Issue Number: 3825
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    "The reference in the ""except"" clause of ""Association Specification"" in section 6.6.6 is not consistent with ""Containment Specification"" in section 6.6.7." Accept. The except clause will be dropped.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    The except clause will be dropped.

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

Clarify multiplicity in the XML element declaration.

  • Key: XMI12-96
  • Legacy Issue Number: 3824
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    "The reference in the ""except"" clause of ""Association Specification"" in section 6.6.6 is to text that was removed." Accept. The except clause will be dropped.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    The except clause will be dropped

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

Nested classes

  • Key: XMI12-106
  • Legacy Issue Number: 3853
  • Status: closed  
  • Source: International Business Machines ( Mr. Tim Grose)
  • Summary:

    Nested classes currently do not follow the even/odd standard progression of element nesting. Add an intermediary element.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Close, no change

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

Backwards compatibility

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

    The XMI RTF meeting in Mesa had consensus that the extra declarations for element attributes for backwards compatibility with XMI 1.0 are no longer needed.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    see above

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

MOF and UML tagged value alignment.

  • Key: XMI12-104
  • Legacy Issue Number: 3834
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    No change. This is a DTD initialValue which differs from UML's initial value

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

Clarify of fixed DTD declarations requirement.

  • Key: XMI12-95
  • Legacy Issue Number: 3823
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Fixed DTD declarations for CORBA need to be clarified in 6.2.2 compared to 6.5.18 and 7.5. "Accept - see AB issues sheet. Clarify to indicate only the required elements in section 7.5."

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    see above

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

OCL and pseudo-code not updated

  • Key: XMI12-101
  • Legacy Issue Number: 3831
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    "The OCL and pseudo-code ""maintained for reference"" are not updated to XMI 1.1. Example, Section 7.2.2" Accept. The OCL and pseuo-code will be removed.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

Pseudo-code for GetReferenceMultiplcity needs updating.

  • Key: XMI12-98
  • Legacy Issue Number: 3826
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Multiplicity should match 6.6.2. EBNF takes precedence. Accept. The Pseudo-code will be dropped.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete pseudo-code.

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

How does an XMI document represent multi-valued attribute values?

  • Key: XMI12-119
  • Legacy Issue Number: 3902
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    How does an XMI 1.1 document represent multi-valued attribute values?
    For example, suppose we have an attribute "foo" with type == 'string'
    and multiplicity of '0..*'. How do you represent this attributes
    value when it contains multiple strings; e.g.

    {'string1', 'string2'}?

    There seem to be three different answers according to Chapter 9.
    The EBNF on page 9-205 is unclear, but it seems to be saying that it
    would look something like:

    <pkg.cls.foo>
    <pkg.cls.foo> string1 </pkg.cls.foo>
    <pkg.cls.foo> string2 </pkg.cls.foo>
    </pkg.cls.foo>

    though the following could be valid also:

    <pkg.cls.foo>
    <pkg.cls.foo> string1
    <pkg.cls.foo> string2 </pkg.cls.foo>
    </pkg.cls.foo>
    </pkg.cls.foo>

    The EBNF on pages 9-217 and 9-221 seems to say:

    <pkg.cls.foo> string1 string2 </pkg.cls.foo>

    This leaves us with a problem in distinguishing {'string1', 'string2'}

    from

    {'string1 string2'}

    .

    On OCL on pages 9-217 and 9-221 seems to say:

    <pkg.cls.foo>
    <XMI.seqItem> string1 </XMI.seqItem>
    <XMI.seqItem> string2 </XMI.seqItem>
    </pkg.cls.foo>

  • Reported: XMI 1.1 — Fri, 22 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    see above

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

More multiplicity inconsistencies in DTD ruleset 1

  • Key: XMI12-118
  • Legacy Issue Number: 3900
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    There are inconsistencies between the EBNF and pseudo-code with respect
    to handling of multiplicities in EBNF productions 6f, 9c, 9d and 12c.
    Typically the EBNF us a '|' separated list and the pseudo-code uses ','
    or a mixture of '|' and ','.

  • Reported: XMI 1.1 — Fri, 22 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

Encoding of "any" values in XMI

  • Key: XMI12-120
  • Legacy Issue Number: 3953
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The XMI document production rules for the encoding of CORBA "any" values
    have the following problems:

    1) The EBNF rules added in XMI 1.1 (page 9-205 of ad/99-10-02) say
    *nothing* about how to encode an "any" value ... or a TypeCode for
    that matter.

    2) The encoding of TypeCode information for an Any value is different
    from the encoding of a bare TypeCode value. IMO, this is an
    unnecessary optimisation (saves only a few bytes over referring
    to TypeCodes by some kind of idref). It has the disadvantage
    of making implementation more complex.

    3) The TypeId production is a bit broken:

    a) A literal reading of the AnyValue and TypeId productions
    says that an "any" value can be encoded with no type
    information. In fact, the 'empty' third case of the
    TypeId should be deleted ... or better, the TypeRef
    production should be folded in.

    b) The second branch of the TypeId production uses a "xmi.name"
    attribute to refer to a TypeCode via its fully-qualified
    DataType name. I don't know how an XMI document consumer
    is going to resolve such a reference. Please explain!

    Wouldn't it be better to use the TypeCode repository id?

    c) In the second branch again, if a TypeCode is identified
    by an "xmi.name" attribute, the "xmi.kind" attribute is
    redundant.

    4) The CorbaTypeName production (9.5.10.2) is incompletely
    specified. It says "deduce pattern from above" ... but I can
    think of more than one plausible "pattern".

  • Reported: XMI 1.1 — Mon, 16 Oct 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Close with no action because of updates to MOF 1.4 datatypes

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

Encoding a union value that has no field value.

  • Key: XMI12-122
  • Legacy Issue Number: 4001
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    Consider the following CORBA union type:

    union Foo switch(long)

    { case 1: boolean one; case 2: char two; }

    ;

    The production rules in 9.5.7.4 and 9.5.9.9 do not say how a "Foo" value
    should be encoded in an XML document when the discriminator is (say) zero.
    (The OCL for 9.5.9.9 will give an exception in CORBA 2.3 in this case.)

    Should the Foo value be encoded in XMI as:

    <XMI.unionDiscrim>0</XMI.unionDiscrim>

    or

    <XMI.unionDiscrim>0</XMI.unionDiscrim>
    <XMI.field></XMI.field>

    or something else?

  • Reported: XMI 1.1 — Fri, 27 Oct 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Close with no action because of updates to MOF 1.4 datatypes.

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

DTD productions for names of Classes in nested Packages

  • Key: XMI12-121
  • Legacy Issue Number: 3990
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    There is an inconsistency between the EBNF and pseudocode that
    generates DTD element declarations for Classes. According to
    the EBNF (production 6a) the element name is the "name of Class"
    preceded by an optional namespace. According to the EBNF, the
    element name is a the qualified Class name.

    There are two issues:

    1) If we follow the EBNF and use an unqualified name, there is
    a risk of name collision when there are Classes in nested Packages.

    2) If we follow the pseudo-code, we lose the namespace prefix.

  • Reported: XMI 1.1 — Tue, 24 Oct 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    see above

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

Why do we need 3 XMI DTD rulesets?

  • Key: XMI12-111
  • Legacy Issue Number: 3885
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The XMI spec currently defines 3 rulesets for generating DTDs for
    meta-models. The rulesets give different DTDs, but they are all intended
    to match (i.e. be capable of validating) the document production rules
    in Chapter 9.

    Given that the 3 kinds of DTDs are equivalent, why do we need them all?
    The point of XMI is the interchange of metadata, not the generation of
    pretty DTDs. Indeed, the XMI DTD compliance section (11.2.1) makes
    it clear that any DTD that expands to the same form is compliant.

    I suggest we just delete the compact DTD rulesets, and leave the
    implementation of "pretty" DTDs as an exercise for the implementor
    to undertake ... or not. The alternative is that we must ensure that
    any changes / corrections are made to the simple ruleset are made to
    the other two rulesets.

  • Reported: XMI 1.1 — Thu, 21 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Remove DTD rule sets 2 and 3 in chapter 4

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

Multiplicities inconsistency in the DTD rulesets

  • Key: XMI12-110
  • Legacy Issue Number: 3880
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The pseudo-code in DTD ruleset 1 for Attributes and References generates
    DTDs in which '?', '+' or '*' may be generated depending on the
    element's
    multiplicity. The earlier EBNF uses '*' only.

  • Reported: XMI 1.1 — Wed, 20 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

Which Classes doe PkgClasses include?

  • Key: XMI12-114
  • Legacy Issue Number: 3892
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    There is a discrepancy between the text describing EBNF production 9e
    and the corresponding pseudo-code. According to the EBNF description,
    only Classes directly contained by this Package or Classes directly
    contained by this Package's direct and indirect super-Packages are
    included. According to the pseudo-code (e.g. GetPackageClasses on
    page 7-113), Classes from containing Packages and their super-Packages
    are also included.

  • Reported: XMI 1.1 — Fri, 22 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    see above

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

Description of ClassReferences and ClassCompositions productions

  • Key: XMI12-113
  • Legacy Issue Number: 3891
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    This relates to productions in DTD ruleset 1

    1) In 6f, what on earth is "an ownedElement of a Class"? This is not
    a recognisable MOF meta-modelling concept.

    2) In 6f, what subclasses need to be included? Those declared in
    this
    Package? In nested Packages? In Packages that import, cluster
    or inherit this Package? More?

    3) In 6e, how come you don't also include names of subclasses of the
    types of the References?

  • Reported: XMI 1.1 — Fri, 22 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

DTD attributes for AssociationEnds in un-referenced Associations

  • Key: XMI12-117
  • Legacy Issue Number: 3895
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    According to EBNF productions 11c & 1a, an AssociationEnd in an
    un-referenced
    Association is represented as "%XMI.element.att;%XMI.link.att".
    According
    to the pseudo-code, it is just "%XMI.link.att".

  • Reported: XMI 1.1 — Fri, 22 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

Does PkgContents include XMI.extension?

  • Key: XMI12-116
  • Legacy Issue Number: 3894
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    This relates to DTD ruleset 1 production 9c. According to the EBNF, the
    XMI.extension element is present in the Package contents. According to
    the pseudo-code (p 7-100) it is not included.

  • Reported: XMI 1.1 — Fri, 22 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

Does PkgPackages contain nested Packages from super-Packages?

  • Key: XMI12-115
  • Legacy Issue Number: 3893
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    There is a discrepancy between the text describing production 9g of DTD
    ruleset 1, the pseudo-code for getContainedPackages and its description.
    The first two say that PkgPackages contains any nested Packages from
    super-Packages, but the description for getContainedPackages does not
    mention this.

    Also, it is not crystal clear what "nested Packages" means in 9g (and
    by extension in other places). It should mean all Packages that
    are directly or indirectly contained by a Package., but this needs to
    be spelled out somewhere.

  • Reported: XMI 1.1 — Fri, 22 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    see above

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

Multi-valued Attributes in the simple DTD ruleset

  • Key: XMI12-109
  • Legacy Issue Number: 3876
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The EBNF (4d, 4f) and pseudo-code for Attribute contents in the simple
    DTD ruleset seem to support multi-valued Attributes in different ways.
    In the EBNF, "attribute contents" have an enclosing "( )*" in the two
    cases that matter. By contrast, in the pseudo-code, the "( )*" 's are
    sometimes present and sometimes absent.

    I think the EBNF is probably correct.

    There are also some minor meta-syntax errors in the pseudo-code;
    e.g. missing quotes.

  • Reported: XMI 1.1 — Wed, 20 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

Inconsistencies in ClassElementDef for DTD ruleset 1

  • Key: XMI12-112
  • Legacy Issue Number: 3888
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The EBNF seems to be generating "|" separated lists for the
    contents of a Class, but the pseudo-code generates "," separated lists.
    This seems to occur with the attribute and reference lists as well
    as the overall contents list.

    In the pseudo-code, 'GetAllReferences' returns all References, but the
    EBNF excludes those References whose exposedEnd is composite.

  • Reported: XMI 1.1 — Thu, 21 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

P 9-175, question regarding EBNF

  • Key: XMI12-94
  • Legacy Issue Number: 3822
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the XMI spec, on page 9-175, it says that EmbeddedObject serves as an alternative to ObjectAsElement for cases where an identifier is not required (i.e. the object participates in no links). However, the EBNF says that an ObjectAsElement is included between the tags (The OCL uses ObjectContents). Can I assume that this is a problem with the XMI spec, and that it should be ObjectContents?"

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete pseudo-code (section 6.4).

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

Explain Possible Uses of Entity Definitions in XMI DTDs

  • Key: XMI12-128
  • Legacy Issue Number: 4432
  • Status: closed  
  • Source: International Business Machines ( Mr. Tim Grose)
  • Summary:

    Since the DTD rule sets 2 and 3 have been removed, along with the
    pseudo-code, a discussion of the possible uses of entity definitions in XMI
    DTDs should be included in the specification to help people implement XMI
    DTD generation.

  • Reported: XMI 1.1 — Mon, 30 Jul 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    see above

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

Completeness of TypeCode and Any support

  • Key: XMI12-126
  • Legacy Issue Number: 4122
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The "fixed elements" for XMI.CorbaTypeCode in sections 6.5.18 & 7.5 are buggy.
    There is no element for the "unsigned long long" TypeCode, and the element
    for the "fixed" TypeCode is not allowed in XMI.CorbaTypeCode.

    In addition, we should consider extending XMI's support of TypeCodes and
    Anys to cover the "value" types added in CORBA 2.3. [We don't need to
    handle Attributes with "value" types at this stage because MOF doesn't
    support this in meta-models.]

    Editorial: The "fixed" DataType DTD elements appear BOTH in section
    6.5.18 and in section 7.5. Could we replace the former with a reference
    to the latter?

  • Reported: XMI 1.1 — Thu, 14 Dec 2000 05:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Close with no action because of updates to MOF 1.4 datatypes

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

XMI handling of type info for CORBA any -- too complex

  • Key: XMI12-125
  • Legacy Issue Number: 4045
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    In trying to implement the production rules for representing CORBA anys in XMI
    document, I've concluded that the current definition is unnecessarily complex.
    This impacts on the producer and consumers of XMI documents in (I believe)
    unforseen ways.

    Currently, the TypeCode information for an 'any' can be represented in a
    number of ways according to 9.5.7.12 & 9.5.8.1:

    1) If the type is primitive, it is represented by the 'xmi.kind'
    [or 'xmi.type' according to 6.5.18] attribute of the XMI.any element.

    2) Otherwise, if the type is defined in the source meta-model, it is
    represented by the "xmi.name" attribute. This gives a qualified
    name of a DataType in the meta-model.

    3) Otherwise, the type is represented as an "href" attribute. This
    presumably must link to an XMI.CorbaTypeCode element elsewhere
    in the current document or in another one. [The spec doesn't say
    this, but this interpretation makes sense.]

    The first case works, though it does mean that simple types are represented
    differently depending on their context (see 9.5.8.15). [This is not good,
    but it isn't hard to handle.]

    The second case is rather problematical:

    • The XMI.any will also have an "xmi.kind" attribute, but this attribute
      won't be correct for a CORBA any whose type is a tk_alias.
    • More importantly, generating and resolving the qualified name
      requires that the producer and consumer to have the meta-model
      at their disposal at runtime. Or at least to know the mapping
      between DataType qualified names and TypeCodes.
    • Mapping from TypeCodes to qualified names is expensive because
      the standard CORBA TypeCode API does not provide a hash function.
    • Finally, it is unclear what model of "equality" of TypeCodes
      should be used. This is significant because the MOF does tricky
      things with repository ids in embedded TypeCode values that
      mean that the TypeCodes in a meta-model won't be identical to
      the TypeCodes generated by an IDL compiler and used in a typical
      CORBA any value.

    The third case could also be problematical if the XMI.CorbaTypeCode elements
    are defined in a separate document. If the documents get separated, it
    is no longer possible to correctly interpret the XMI.any values. This
    particularly significant given that the contents of an XMI.any element
    do not give much type information.

    Finally, it is not clear what should happen if a producer encounters an IOR for
    instance of a Class in an any. Probably it should treat this via case 3) but
    the spec doesn't state this explicitly.

    My recommendation would be to redefine the XMI.any element to contain an
    XMI.CorbaTypeCode element, and redefine XMI.CorbaTypeCode so that it has
    three forms; i.e.

    XMI.CorbaTypeCode xmi.kind="kind" / // where tc.kind() is simple
    // or unbounded string

    and

    XMI.CorbaTypeCode xmi.idref="some id" /

    and

    XMI.CorbaTypeCode xmi.id="some id" typecode state /XMI.CorbaTypeCode

    This should make both Anys and TypeCodes easier / safer to handle in a wider
    range of XMI implementation and runtime contexts.

    The percentage expansion of the resulting XMI document should be insignificant
    unless the transmitted metadata is mostly CORBA any values.

  • Reported: XMI 1.1 — Wed, 15 Nov 2000 05:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Close with no action because of updates to MOF 1.4 datatypes

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

Representing object references in an XMI document

  • Key: XMI12-124
  • Legacy Issue Number: 4044
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    Suppose that a meta-model is declared as follows:

    package Foo {
    class Bar

    { attribute CORBA::Object baz; }

    ;
    };

    According to the XMI document production rules, the value of the "baz"
    attribute should be encoded using the ObjectReference production (9.4.5.2).
    This says that if the object is part of the model (e.g. an instance of
    some Class defined by the meta-model), the value is encoded as:

    XMI.reference xmi.idref="some_id" /

    Otherwise it is encoded as

    XMI.reference href="some_URL" /

    Unfortunately, the latter does not work because there is no legal URL
    representation for a CORBA Object reference, and you can't represent
    a CORBA Object reference in some other XMI document.

    I think the fix is to provide a third alternative:

    XMI.reference stringified-CORBA-IOR /XMI.reference

  • Reported: XMI 1.1 — Wed, 15 Nov 2000 05:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Close with no action because of updates to MOF 1.4 datatypes

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

Representing type information for CORBA anys

  • Key: XMI12-123
  • Legacy Issue Number: 4043
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    If I understand 9.5.7.10 correctly, it says that the type information for an
    Any may be partly or fully represented by "xmi.kind", "xmi.id" and "href" XML
    attributes of the XMI.any element. However, according to the fixed element
    declarations in 6.5.18, the "XMI.any" element cannot have an "xmi.kind" or (I
    think) "xmi.id" attributes. Instead, it has attributes "href", "xmi.idref",
    "xmi.name" and "xmi.type".

    Which attributes should be used?

  • Reported: XMI 1.1 — Wed, 15 Nov 2000 05:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Close with no action because of updates to MOF 1.4 datatypes

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

Update XMI 1.2 to reflect MOF 1.4 updates

  • Key: XMI12-127
  • Legacy Issue Number: 4417
  • Status: closed  
  • Source: International Business Machines ( Dr. Stephen Brodsky, Ph.D)
  • Summary:

    MOF 1.4 has had the final RTF votes. There are changes to MOF 1.4 that
    result in updates to XMI 1.2. In particular, the data type simplification
    in MOF 1.4 will lead to improvements for XMI 1.2.

  • Reported: XMI 1.1 — Mon, 23 Jul 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    see above

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