XML Metadata Interchange Avatar
  1. OMG Specification

XML Metadata Interchange — All Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
XMI26-6 Normative document references not found XMI 2.5.1 open
XMI24-181 Minor spelling mistakes XMI 2.5.1 open
XMI26-5 The processContent attribute should be "lax" in the official XMI.xsd XMI 2.5 open
XMI26-2 9.4.1 serialization of a composite property typed by a class XMI 2.5 open
XMI26-1 9.4.1 serialization of a null-valued property typed by an enumeration or primitive type XMI 2.5 open
XMI26-4 XMI spec lacks support for profiles XMI 2.5 open
XMI26-3 9.4.1 serialization of a property typed by a structured datatype XMI 2.5 open
XMI12-7 3.6.4 Inheritance Specification XMI 1.1 open
XMI12-11 XMI 1.2 Issue - Association elements with references XMI 1.1 open
XMI12-4 DTD's (01-04-03) for XMI 1.2 XMI 1.1 open
XMI12-3 Invalid example model encoding XML XMI 1.1 open
XMI12-5 3.6.5 Attribute Specification XMI 1.1 open
XMI12-10 "3.6.1 Namespace Qualified XML Element Names" XMI 1.1 open
XMI12-8 General question to "3.6.4 Inheritance Specification" XMI 1.1 open
XMI12-2 Empty Fragment Identifier in Link XMI 1.1 open
XMI12-1 Urgent XMI 2.0 issue: XML Schema Production XMI 1.1 open
XMI12-6 3.6.4 Inheritance Specification XMI 1.1 open
XMI12-9 XMI issue - referenceless composition does not export components XMI 1.1 open
XMI12-43 Production by Package Extent Example in 00-12-05 XMI 1.1 open
XMI12-57 EmbeddedObject is misused XMI 1.1 open
XMI12-52 Minor bug / typo in handling of References XMI 1.1 open
XMI12-54 EBNF incomplete for Attributes with complex types XMI 1.1 open
XMI12-47 Inconsistencies for classifier-level Attributes XMI 1.1 open
XMI12-34 Specification addresses only generation not consumption (medium) XMI 1.1 open
XMI12-48 Anomalies with References and ordered Associations. XMI 1.1 open
XMI12-42 Include derived attributes and references in rule 6d in DTD production XMI 1.1 open
XMI12-45 UML: Using public identifiers to denote DTDs XMI 1.1 open
XMI12-40 Section 5.3 still uses old datatypes XMI 1.1 open
XMI12-53 Include Derived Attributes and References of Derived Associations XMI 1.1 open
XMI12-55 Garbled descriptions in ObjectAsElement (page 9-204) XMI 1.1 open
XMI12-60 How to represent a "null" for a Class-valued Attribute? XMI 1.1 open
XMI12-30 Tool interchange recommendation insufficient (major) XMI 1.1 open
XMI12-14 Problem with namespaces XMI 1.1 open
XMI12-28 XMI: No way to specify the meta-meta-metamodel XMI 1.1 open
XMI12-18 MOF structured types missing from XMI 1.2 XMI 1.1 open
XMI12-20 XMI issue - xmi.exporterId inconsistently used and undefined XMI 1.1 open
XMI12-26 Unclear URI format XMI 1.1 open
XMI12-46 bi-directional References and redundancy XMI 1.1 open
XMI12-35 Problems with section on Linking XMI 1.1 open
XMI12-37 Directory structure for OMG standard XMI documents and DTDs XMI 1.1 open
XMI12-33 Effect of xmi.import is unclear (medium) XMI 1.1 open
XMI12-39 Incomplete rules for non-Primitive Datatype values XMI 1.1 open
XMI12-58 DTD element content and multiplicities versus compliance. XMI 1.1 open
XMI12-56 Association elements when no immediate references XMI 1.1 open
XMI12-12 org.omg.xmi.enumerationUnprefix XMI 1.1 open
XMI12-31 Nonexistent '' used (minor) XMI 1.1 open
XMI12-15 XMI 1.2: Missing class scope in <7m:AttName>, pp. 6-6? XMI 1.1 open
XMI12-25 Appendix A, Example , the example is not valid UML. XMI 1.1 open
XMI12-17 What IS this "General Datatype Mechanism" anyway? XMI 1.1 open
XMI12-21 Unclear software compliance - see also issues 3887 and 3889 XMI 1.1 open
XMI12-23 Outmoded use of '|' as separator XMI 1.1 open
XMI12-19 [xmi] xmi.label / xmi:label XMI 1.1 open
XMI12-27 XMI does not document the tag used to determine XML Namespace XMI 1.1 open
XMI12-50 Reconsider XML attribute encoding of values in XMI 1.1 XMI 1.1 open
XMI12-51 Encoding of strings and characters in XMI documents XMI 1.1 open
XMI12-49 XML attribute encoding of values underspecified XMI 1.1 open
XMI12-44 Composition Association problems XMI 1.1 open
XMI12-36 Clarify that references to external documents can be virtual (minor) XMI 1.1 open
XMI12-38 Example in A.5 is misleading XMI 1.1 open
XMI12-41 XMI document production rule 7c issue XMI 1.1 open
XMI12-61 DTD rules unclear for attributes of subclasses. XMI 1.1 open
XMI12-59 Document production rules for "un-Referenced" Associations. XMI 1.1 open
XMI12-32 Example 4 in A.5 is obscure (minor) XMI 1.1 open
XMI12-13 propose a new tag to be applied to metamodels XMI 1.1 open
XMI12-29 Adoption of XLink specification (minor) XMI 1.1 open
XMI12-16 What is the idea of encoding package contents? XMI 1.1 open
XMI12-22 OMG XML Metadata Interchange issue XMI 1.1 open
XMI12-24 UML conversion to MOF out of scope XMI 1.1 open
XMI21-4 Revise 7.13.2 XMI Document Exchange with Multiple Tools XMI 2.0 open
XMI21-2 section 8.2.1 on page 46 (editorial) XMI 2.0 open
XMI21-3 XMI 2.0 terminology XMI 2.0 open
XMI21-8 Mandatory Extensions when enforceMinimumMultiplicity is true XMI 2.0 open
XMI21-5 section 8.2.1 on page 44 (editorial) XMI 2.0 open
XMI21-7 XMI for TypeLibrary::Objects::Object is Unspecified XMI 1.3 open
XMI12-90 AssociationEnds without references XMI 1.1 open
XMI12-62 "Inputs" that define an XMI metadata interchange format. XMI 1.1 open
XMI12-64 Miss-stated XMI compliance points. XMI 1.1 open
XMI12-71 Editorial: remove unnecessary hitorical references. XMI 1.1 open
XMI12-69 Bug in pseudo-code for PackageDTD XMI 1.1 open
XMI12-67 The "complete" approach to XMI data types must be optional XMI 1.1 open
XMI12-74 XMI Tags XMI 1.1 open
XMI12-76 XMI.reference suppression XMI 1.1 open
XMI12-82 Example C Multiplicity XMI 1.1 open
XMI12-85 Usage of XMI for GIS ISO 19118/TC211 XMI 1.1 open
XMI12-86 XMI cross-version compatibility XMI 1.1 open
XMI21-11 ISSUE: XMI for MOF 2 does not reflect MOF 2 model XMI 1.3 open
XMI21-9 ISSUE: XMI for MOF 2 should address models, not just metamodels XMI 1.3 open
XMI21-6 section 8.2.1 on page 46 (editorial) XMI 2.0 open
XMI21-1 section 7.10.2.2(.2) on page 23 (editorial) XMI 2.0 open
XMI12-89 Documentation of References in section 6.6 XMI 1.1 open
XMI12-63 XMI MOF Subset" optional compliance point. XMI 1.1 open
XMI12-70 Section 6.12 needs rewriting. XMI 1.1 open
XMI12-66 Editorial: Fix up the cross-references. XMI 1.1 open
XMI12-68 DTD generation rules for composed Packages. XMI 1.1 open
XMI12-72 DTD production clarifications for nested Packages XMI 1.1 open
XMI12-75 Status of pseudo-code in Chapter 7 XMI 1.1 open
XMI12-79 XMI.content declaration XMI 1.1 open
XMI12-77 Allow suppression of reference serialization XMI 1.1 open
XMI12-80 Containment as links XMI 1.1 open
XMI12-83 QName for XML attribute values XMI 1.1 open
XMI12-84 Appendix C example XMI 1.1 open
XMI21-10 XMI for MOF 2 defines tagged values XMI 1.3 open
XMI12-87 Open DTD content for subclasses XMI 1.1 open
XMI12-88 Examples with references confusing. XMI 1.1 open
XMI12-92 Reference to deleted text on fully qualified names. XMI 1.1 open
XMI12-93 Element Identification Attributes XMI 1.1 open
XMI12-73 The UML and MOF DTD appendices are poor examples. XMI 1.1 open
XMI12-65 DTD generation for DataTypes with typecode.kind == tk_alias XMI 1.1 open
XMI12-78 Specifying Attributes vs Elements XMI 1.1 open
XMI12-81 Additional examples XMI 1.1 open
XMI12-91 Typo in applicability scenarios XMI 1.1 open
XMI24-180 XMI composite opposite constraint overly restrictive XMI 2.4 XMI 2.4.1 Resolved closed
MOF24-59 no documented standard serializiation of MOF 1.4 as an XMI 2.0 schema XMI 2.0 MOF 2.0 Transfered 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-101 Examples are instances of non-MOF metamodels (medium) XMI 1.0 open
XMI11-100 MOF and UML tagged value alignment. XMI 1.0 open
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
XMI13-3 XMI Schema Issue - representation for Associations XMI 1.2 open
XMI13-2 Introduce extenderVersion XMI 1.2 open
XMI13-1 More use of schema structural constraints XMI 1.2 open
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
XMI24-10 Canonical XMI (ptc/2013-08-28): need rules for generating xmi:id and xmi:uuid for auxiliary XML elements XMI 2.4 open
XMI24-9 [MOF2] and [UML2] not further specified in the document XMI 2.4 open
XMI24-8 MOF/XMI schemaType is incorrectly defined relative to its use and its scope is too restrictive XMI 2.4 open
XMI24-1 Which type of name should be used XMI 2.0 open
XMI24-3 XMI issue - root elements for XMI Schemas XMI 2.4 open
XMI24-2 metamodel for XML Schema XMI 2.1 open
XMI24-6 Revise XMI examples in 9.4 XMI 2.4 open
XMI24-5 XMI should include a name transformation algorithm to convert names e.g. replace spaces by ‘_’ XMI 2.4 open
XMI24-7 No XML-Schema for UML-XMI XMI 2.4 open
XMI24-4 Name transformation XMI 2.4 open
XMI24-124 Extension is only referenced from 1a. However it certainly should be valid within an XMIObjectElement. XMI 2.4 open
XMI21-20 Remarks to chapter "3.4.3 Derived Types and References" in XMI Spec. , v 2 XMI 1.3 open
XMI21-19 Are xlinks legal? XMI 1.3 open
XMI21-12 XMI 2.0 issue: Proxies and Multiplicities XMI 1.3 open
XMI21-15 Incosistent XMI namespace URL XMI 1.3 open
XMI21-14 More type safety in generated schemas XMI 1.3 open
XMI21-13 Schema production rule 4d clarification request XMI 1.3 open
XMI21-18 tag value constraint in chapter 1.11.2 XMI 2.0 open
XMI21-17 Schema production rule for 'ClassReferences' (4.e) XMI 1.3 open
XMI21-16 The ClassAttribRef Production Rule (4i) can be enhanced XMI 2.0 open
XMI21-24 How to serialize values of the PrimitiveType UnlimitedNatural XMI 2.1 open
XMI21-23 Page: 60 XMI 2.1 open
XMI21-22 Page: 58 XMI 2.1 open
XMI21-21 How are attributes and compositions inherited? XMI 2.0 open
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
UML25-629 15.3.11 State (from BehaviorStateMachines, ProtocolStateMachines) XMI 1.0 UML 2.5 Resolved closed
UML25-620 15.3.14 Transition (from BehaviorStateMachines) XMI 1.0 UML 2.5 Resolved closed
UML22-534 In normative XMI file for the metamodel, no Associations have a name. XMI 2.0 UML 2.1 Resolved closed
UML22-533 UML 2 Super/Interactions/Constraints for create messages XMI 2.0 UML 2.1 Resolved closed
UML22-536 UML2 Infra/11.5.1/Invalid reference to Attribute class XMI 2.0 UML 2.1 Resolved closed
UML22-475 Sending a signal after a delay XMI 1.3 UML 2.1.2 Resolved closed
UML22-474 Does visibility apply to creating an destroying links? XMI 1.2 UML 2.1 Resolved closed
UML22-520 UML 1.5 table of contents XMI 2.0 UML 2.1 Resolved closed
UML14-558 Components / provided and required interfaces -- derived or subsets XMI 2.0 UML 1.4.2 Resolved closed
UML14-554 "Physical" Metamodel Package Structure (uml-rtf) XMI 1.1 UML 1.4.2 Resolved closed
UML14-556 TaggedValue in TaggedValue XMI 1.3 UML 1.4.2 Resolved closed
UML14-555 Ambiguous semantics of classifier ownerscope XMI 1.2 UML 1.4.2 Resolved closed
UML14-471 UML2 super/notation/Keywords XMI 2.0 UML 1.4.2 Resolved closed
UML14-470 Appendix B/Standard Stereotypes too heavyweight and incompletely defined XMI 2.0 UML 1.4.2 Resolved closed
UML14-480 UML 2 Super / Interactions / incorrect multiplicity for PartDecomposition XMI 2.0 UML 1.4.2 Resolved closed
UML14-479 The contents of the Interfaces package is shown in Figure 51 XMI 2.0 UML 1.4.2 Resolved closed
UML14-482 UML 2 Super / Interactions / navigability of enclosingOperation XMI 2.0 UML 1.4.2 Resolved closed
UML14-481 UML 2 Super / Dependencies / Abstraction should have an optional mapping XMI 2.0 UML 1.4.2 Resolved closed
UML14-478 UML 2 Super / Templates / subsetting templateParameter XMI 2.0 UML 1.4.2 Resolved closed
UML14-477 UML 2 Super / General / Idenitfy sections specifying run-time semantics XMI 2.0 UML 1.4.2 Resolved closed
UML14-476 UML 2 Super / Classes / XMI 2.0 UML 1.4.2 Resolved closed
UML14-473 importedMember property XMI 2.0 UML 1.4.2 Resolved closed
UML14-475 UML 2 Super / Interactions / Two typos XMI 2.0 UML 1.4.2 Resolved closed
UML14-474 missing closing bracket XMI 2.0 UML 1.4.2 Resolved closed
UML14-472 "• value : InstanceSpecification XMI 2.0 UML 1.4.2 Resolved closed
UML14-543 UML2 Super / Classes / Operation constraints XMI 2.0 UML 1.4.2 Resolved closed
UML14-542 UML2 Super / ordering of association ends XMI 2.0 UML 1.4.2 Resolved closed
UML14-541 Q re Parameter XMI 2.0 UML 1.4.2 Resolved closed
UML14-537 UML2 super/interactions XMI 2.0 UML 1.4.2 Resolved closed
UML14-536 UML 2 Super / Templates / invalid multiplicity XMI 2.0 UML 1.4.2 Resolved closed
UML14-535 UML 2 Super / Profiles / problem with name collisions XMI 2.0 UML 1.4.2 Resolved closed
UML14-547 Question about Enumeration and EnumerationLiteral XMI 2.0 UML 1.4.2 Resolved closed
UML14-540 UML 2 Super / missing owners of concepts XMI 2.0 UML 1.4.2 Resolved closed
UML14-539 UML 2 Super / state machines / state should be a namespace XMI 2.0 UML 1.4.2 Resolved closed
UML14-538 UML 2 Super/Connector XMI 2.0 UML 1.4.2 Resolved closed
UML14-546 UML2 Super / Common Behavior / Trigger should be a named element XMI 2.0 UML 1.4.2 Resolved closed
UML14-545 UML2 Super / Use cases / navigation from subject to use case XMI 2.0 UML 1.4.2 Resolved closed
UML14-544 UML 2 Super / General / superclass pointers XMI 2.0 UML 1.4.2 Resolved closed
UML14-534 transition is simply never enabled XMI 2.0 UML 1.4.2 Resolved closed
UML14-533 UML Sequence diagram XMI 2.0 UML 1.4.2 Resolved closed
UML14-493 UseCase - Constraint for non-circular include relation XMI 2.0 UML 1.4.2 Resolved closed
UML14-492 What level of MOF 2.0 is the metamodel for UML 2.0? XMI 2.0 UML 1.4.2 Resolved closed
UML14-484 UML 2 Super / Realize keyword-stereotype XMI 2.0 UML 1.4.2 Resolved closed
UML14-483 UML 2 Super / Classes / Properties owned by properties XMI 2.0 UML 1.4.2 Resolved closed
UML14-489 Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 367 XMI 2.0 UML 1.4.2 Resolved closed
UML14-488 Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 366 XMI 2.0 UML 1.4.2 Resolved closed
UML14-487 Inconsistent labeling of tables in Section 12.4, Activities.Diagrams p365 XMI 2.0 UML 1.4.2 Resolved closed
UML14-486 UML 2 Super / Deployments / Invalid cross-references XMI 2.0 UML 1.4.2 Resolved closed
UML14-495 UML 2 Super / use cases / incorrect table title XMI 2.0 UML 1.4.2 Resolved closed
UML14-494 UseCase - Include - Constraint for irreflexivity XMI 2.0 UML 1.4.2 Resolved closed
UML14-485 UML 2 Super / Classes / Dependency should not be abstract XMI 2.0 UML 1.4.2 Resolved closed
UML14-496 UML2 superstructur: actor XMI 2.0 UML 1.4.2 Resolved closed
UML14-491 UML 2 Super / General / specialization labeling convention XMI 2.0 UML 1.4.2 Resolved closed
UML14-490 Typo in Collaboration Diagram figure XMI 2.0 UML 1.4.2 Resolved closed
UML14-518 adopt a single notation to specify text strings used in the notation XMI 2.0 UML 1.4.2 Resolved closed
UML14-517 Appendix A of the superstructure spec XMI 2.0 UML 1.4.2 Resolved closed
UML14-516 UML 2 Super / Activities / Fig.192 constraint duplicated XMI 2.0 UML 1.4.2 Resolved closed
UML14-515 Ambiguous semantics of isStatic - resubmission of issue 4446 XMI 2.0 UML 1.4.2 Resolved closed
UML14-514 UML 2 Super / Interactions / Invalid subsetting for enclosingOperand XMI 2.0 UML 1.4.2 Resolved closed
UML14-513 UML 2 Super / Classes / makesVisible () operation incorrect XMI 2.0 UML 1.4.2 Resolved closed
UML14-512 Super and Infra / Kernel-Classifiers / incorrect hasVisibilityOf definition XMI 2.0 UML 1.4.2 Resolved closed
UML14-526 Operations and derived attributes XMI 2.0 UML 1.4.2 Resolved closed
UML14-525 use of stereotypes XMI 2.0 UML 1.4.2 Resolved closed
UML14-524 UML 2 Super / Appendix A / Typos XMI 2.0 UML 1.4.2 Resolved closed
UML14-523 UML 2 Super/Interactions/Alternative with all false guards XMI 2.0 UML 1.4.2 Resolved closed
UML14-522 UML 2 Super / General / Classes chapter organization XMI 2.0 UML 1.4.2 Resolved closed
UML14-521 UML 2 Super / State machines / incorrect navigation specifications XMI 2.0 UML 1.4.2 Resolved closed
UML14-520 UML 2 Super / General / consistent formatting conventions XMI 2.0 UML 1.4.2 Resolved closed
UML14-519 UML 2 Super / General / Dcoument conventions XMI 2.0 UML 1.4.2 Resolved closed
UML14-528 Activity Diagrams: Relax Traverse-to-Completion semantics XMI 2.0 UML 1.4.2 Resolved closed
UML14-530 UML2 super/Deployments/CommunicationPath XMI 2.0 UML 1.4.2 Resolved closed
UML14-529 State machines / name of transitions association end XMI 2.0 UML 1.4.2 Resolved closed
UML14-532 UML2 Super/Composite Structure XMI 2.0 UML 1.4.2 Resolved closed
UML14-531 UML 1 activities XMI 2.0 UML 1.4.2 Resolved closed
UML14-527 Composite Structures, 03-08-02.pdf XMI 2.0 UML 1.4.2 Resolved closed
UML14-511 Ambiguous example of a local action on a Lifeline in Figures 334, 335 XMI 2.0 UML 1.4.2 Resolved closed
UML14-510 ambiguous definition of the scope of a break CombinedFragment XMI 2.0 UML 1.4.2 Resolved closed
UML14-509 UML 2 Super/Interactions/inconsistent spelling for InteractionOperator XMI 2.0 UML 1.4.2 Resolved closed
UML14-502 Ambiguous sentence and typo in description of EventOccurence XMI 2.0 UML 1.4.2 Resolved closed
UML14-501 graphic nodes for state invariant and continuation are not always distingui XMI 2.0 UML 1.4.2 Resolved closed
UML14-498 Ambiguous semantics of isStatic XMI 2.0 UML 1.4.2 Resolved closed
UML14-497 self-activation notation in Sequence diagrams missing XMI 2.0 UML 1.4.2 Resolved closed
UML14-505 UML 2 Super/Interactions/rationale subsections not informative XMI 2.0 UML 1.4.2 Resolved closed
UML14-504 UML 2 Super/Interactions/incorrect grammar for XMI 2.0 UML 1.4.2 Resolved closed
UML14-507 word "execute" in definition of alternative CombinedFragment is ambiguous XMI 2.0 UML 1.4.2 Resolved closed
UML14-506 UML 2 Super/Interactions/Ambiguous description of state invariants XMI 2.0 UML 1.4.2 Resolved closed
UML14-500 UML 2 Super/Interactions/incorrect text and table title for Table 19 XMI 2.0 UML 1.4.2 Resolved closed
UML14-499 UML 2 Super/Interactions/incorrect text before Table 14 XMI 2.0 UML 1.4.2 Resolved closed
UML14-503 UML 2 Super/Interactions/incorrect spelling of EventOccurence XMI 2.0 UML 1.4.2 Resolved closed
UML14-508 text differs from metamodel for critical region InteractionOperator XMI 2.0 UML 1.4.2 Resolved closed
UML14-61 Predefined datatypes XMI 1.2 UML 1.4.2 Resolved closed
UML14-60 The definition of Multiplicity in Datatypes does not list the range associa XMI 1.2 UML 1.4.2 Resolved closed
UML14-65 Component notation: logical compartments XMI 1.2 UML 1.4.2 Resolved closed
UML14-64 Exceptions do not correspond to common usage XMI 1.2 UML 1.4.2 Resolved closed
UML14-59 Ambiguous semantics of classifier targetscope XMI 1.2 UML 1.4.2 Resolved closed
UML14-63 Event => Event Specification XMI 1.2 UML 1.4.2 Resolved closed
UML14-62 The text and OCL of rule #5 for Method do not say the same thing. XMI 1.2 UML 1.4.2 Resolved closed
UML14-37 Another State machine issue XMI 1.1 UML 1.4.2 Resolved closed
UML14-36 Data Types Misplaced in the "Physical" Metamodel (uml-rtf) XMI 1.1 UML 1.4.2 Resolved closed
UML14-30 Inheritance violation in "Auxiliary Elements" XMI 1.0 UML 1.4.2 Resolved closed
UML14-33 class EnumerationLiteral issue XMI 1.0 UML 1.4.2 Resolved closed
UML14-35 Operations and Constraints Missing from "Physical" Metamodels XMI 1.1 UML 1.4.2 Resolved closed
UML14-31 Incomplete Inheritance Specification XMI 1.0 UML 1.4.2 Resolved closed
UML14-32 Datatypes: Expression XMI 1.0 UML 1.4.2 Resolved closed
UML14-34 Interfaces on Nodes XMI 1.0 UML 1.4.2 Resolved closed
UML14-38 UML RTF 1.4 Issue: Dynamic concurrency arguments XMI 1.1 UML 1.4.2 Resolved closed
UML14-39 UML RTF 1.4 Issue: Parallel action iteration XMI 1.1 UML 1.4.2 Resolved closed
UML14-82 UML 1.4: ClassifierRole contents problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-81 UML 1.4: Node, Artifact, Package and Model contents problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-89 Suggest that alternate syntax used in section 6.5.5 be adopted thoughout XMI 1.3 UML 1.4.2 Resolved closed
UML14-88 Invalid XMI.link.atts in UML 1.4 DTD XMI 1.3 UML 1.4.2 Resolved closed
UML14-95 UML 1.4.1 should use MOF 1.4 XMI 1.3 UML 1.4.2 Resolved closed
UML14-94 Add action for invoking an activity XMI 1.3 UML 1.4.2 Resolved closed
UML14-84 UML 1.4: Wrong target for StateMachine.top association XMI 1.3 UML 1.4.2 Resolved closed
UML14-83 UML 1.4: AttributeLink containment error XMI 1.3 UML 1.4.2 Resolved closed
UML14-87 Definitions in glossary don't conform to any standard for definitions XMI 1.3 UML 1.4.2 Resolved closed
UML14-86 Composite relationship between Event and StateMachine XMI 1.3 UML 1.4.2 Resolved closed
UML14-92 Simplify inputs/outputs of procedures XMI 1.3 UML 1.4.2 Resolved closed
UML14-91 match/correspond clarfication XMI 1.3 UML 1.4.2 Resolved closed
UML14-93 StartStateMachine clarification XMI 1.3 UML 1.4.2 Resolved closed
UML14-90 Namespace.contents XMI 1.3 UML 1.4.2 Resolved closed
UML14-85 Adding events to the class definition XMI 1.3 UML 1.4.2 Resolved closed
UML14-17 Parametrizable model elements not shown XMI 1.0 UML 1.4.2 Resolved closed
UML14-119 Inconsistency regarding guards on forks XMI 1.3 UML 1.4.2 Resolved closed
UML14-118 spelling of the word Use Case XMI 1.3 UML 1.4.2 Resolved closed
UML14-110 There is an unnecessary condition in rule 1 of the Namespace element XMI 1.3 UML 1.4.2 Resolved closed
UML14-109 Rule 6 of the Method element isn't formulated well XMI 1.3 UML 1.4.2 Resolved closed
UML14-115 There is a misprint in rule 2 of the Object element: “Stimuli” instead of “ XMI 1.3 UML 1.4.2 Resolved closed
UML14-114 There are misprints with numeration of rules of the Instance element XMI 1.3 UML 1.4.2 Resolved closed
UML14-112 there is something wrong with rule 3 of the Trace element XMI 1.3 UML 1.4.2 Resolved closed
UML14-120 The first sentence is not consistent with figure 2-9 on page 2-17 XMI 1.3 UML 1.4.2 Resolved closed
UML14-113 Wrong alphabetical order: DataValue section should be before DestroyAction XMI 1.3 UML 1.4.2 Resolved closed
UML14-111 Add rule to Namespace element XMI 1.3 UML 1.4.2 Resolved closed
UML14-116 There is a misprint in rule 1 of the SubsystemInstance element XMI 1.3 UML 1.4.2 Resolved closed
UML14-117 font sizes XMI 1.3 UML 1.4.2 Resolved closed
UML14-67 Optimize Instance data values XMI 1.2 UML 1.4.2 Resolved closed
UML14-66 Component notation: showing delegation of messages XMI 1.2 UML 1.4.2 Resolved closed
UML14-75 UML 1.4: State containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-74 UML 1.4: Action problem in Collaborations XMI 1.3 UML 1.4.2 Resolved closed
UML14-80 UML 1.4: Event containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-79 UML 1.4: Stimulus containment XMI 1.3 UML 1.4.2 Resolved closed
UML14-77 UML 1.4: Transition containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-76 UML 1.4: ExtensionPoint containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-78 UML 1.4: Feature containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-73 UML 1.4: Action containment error XMI 1.3 UML 1.4.2 Resolved closed
UML14-19 Guard in current metamodel can be replaced by Constraint with stereotype XMI 1.0 UML 1.4.2 Resolved closed
UML14-18 Need for notation for dealing with evolution of UML models XMI 1.0 UML 1.4.2 Resolved closed
UML14-25 Missing OCL XMI 1.0 UML 1.4.2 Resolved closed
UML14-24 OCL needs to be added XMI 1.0 UML 1.4.2 Resolved closed
UML14-26 ElementOwnership XMI 1.0 UML 1.4.2 Resolved closed
UML14-28 extension to the notation for a transition XMI 1.0 UML 1.4.2 Resolved closed
UML14-23 Page 19 semantic doc. name XMI 1.0 UML 1.4.2 Resolved closed
UML14-22 UML 1.1.section 4.2:editorial XMI 1.0 UML 1.4.2 Resolved closed
UML14-27 User-defined symbols for tagged values and properties XMI 1.0 UML 1.4.2 Resolved closed
UML14-29 Associate a predicate with a state XMI 1.0 UML 1.4.2 Resolved closed
UML14-21 Figure 7 p. 43 of the UML semantics guide XMI 1.0 UML 1.4.2 Resolved closed
UML14-20 AssociationEnd needs ownerScope XMI 1.0 UML 1.4.2 Resolved closed
UML14-100 Initial state for composite states - OCL example and missing constraint XMI 1.3 UML 1.4.2 Resolved closed
UML14-99 UML 1.4 - Partition relates to nothing XMI 1.3 UML 1.4.2 Resolved closed
UML14-104 In v1.4, section 3.84.1 the paragraph on semantics XMI 1.3 UML 1.4.2 Resolved closed
UML14-103 Section 2.13.4.3 XMI 1.3 UML 1.4.2 Resolved closed
UML14-101 UML Issue - Inconsistency between UML 1.3 XMI and DTD XMI 1.3 UML 1.4.2 Resolved closed
UML14-107 Section number duplicated XMI 1.3 UML 1.4.2 Resolved closed
UML14-106 Section 3.90.2.2 XMI 1.3 UML 1.4.2 Resolved closed
UML14-97 Well-formedness rules 4 and 6 on 2.12.3.4 PseudoState XMI 1.3 UML 1.4.2 Resolved closed
UML14-96 A_context_raisedSignal XMI 1.3 UML 1.4.2 Resolved closed
UML14-102 How does one indicate the target object for a CallState XMI 1.3 UML 1.4.2 Resolved closed
UML14-105 parameters of object flow states XMI 1.3 UML 1.4.2 Resolved closed
UML14-98 Well-formedness rules for 2.12.3.8 XMI 1.3 UML 1.4.2 Resolved closed
UML14-108 Swap rule 2 and rule 3 of the Binding element XMI 1.3 UML 1.4.2 Resolved closed
UML14-45 UML 1.4 RTF Issue: Multiple languages for uninterpreted strings XMI 1.1 UML 1.4.2 Resolved closed
UML14-42 Efficient diagrammatic notation for Collaboration Specifications XMI 1.1 UML 1.4.2 Resolved closed
UML14-41 Statemachine/state as Namespace XMI 1.1 UML 1.4.2 Resolved closed
UML14-40 UML RTF 1.4 Issue: Missing notation mapping for association in composite XMI 1.1 UML 1.4.2 Resolved closed
UML14-43 ClassifierRoles should be independent of specific underlying base Classifi XMI 1.1 UML 1.4.2 Resolved closed
UML14-44 UML 1.4 issue: Top state in activity graphs XMI 1.1 UML 1.4.2 Resolved closed
MOF24-44 Rule 1 references 2:ContentElements which is undefined XMI 2.4 MOF 2.4 Resolved closed
MOF24-43 Rule 4i in 5.2 has the following with only 2 options XMI 2.4 MOF 2.4 Resolved closed
MOF24-46 Use of "xmi:" and //xmiPrefix// is inconsistent. XMI 2.4 MOF 2.4 Resolved closed
MOF24-45 1b has been deleted, but it is still referenced from 2g, 2l and 3 XMI 2.4 MOF 2.4 Resolved closed
MOF24-48 When 2n is used with 2j it is supposed to match the last part of schema production XMI 2.4 MOF 2.4 Resolved closed
MOF24-47 There is a missing colon in 2d. The last line should be (2h:FeatureAttrib)* XMI 2.4 MOF 2.4 Resolved closed
MOF24-50 The example in Issue 9645 doesn't seem like a particularly good one XMI 2.4 MOF 2.4 Resolved closed
MOF24-49 There was an error in the example in Issue 9626 XMI 2.4 MOF 2.4 Resolved closed
MOF24-53 MOF 2.4 references missing XMI 2.4 MOF 2.4 Resolved closed
MOF24-52 Issue 9673 contained "file:Co.xml" which is an invalid absolute URI XMI 2.4 MOF 2.4 Resolved closed
MOF24-51 Resolution text to issue 9650 not consistent XMI 2.4 MOF 2.4 Resolved closed
MOF24-54 The replacement text from Issue 15307 for "If true, serialize...is as follows:" doesn't makes sense XMI 2.4 MOF 2.4 Resolved closed

Issues Descriptions

Normative document references not found


Minor spelling mistakes

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

    Section B.2

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

The processContent attribute should be "lax" in the official XMI.xsd

  • Key: XMI26-5
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    As suggested by Pete while reviewing the XMI files generated for SysML 1.5, the official XMI.xsd should have the processContent attribute set to "lax" instead of "strict". It would allow using it for validating official XMI files for specification related to UML (e.g. SysML) since UML has no XSD.

  • Reported: XMI 2.5 — Wed, 14 Dec 2016 16:30 GMT
  • Updated: Thu, 22 Dec 2016 19:27 GMT

9.4.1 serialization of a composite property typed by a class

  • Key: XMI26-2
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Table 9.4.1 states:

    Choice of:
    1. XMIObjectElement
    2. Nested XMIReferenceElement
    3. Nested XMIReferenceAttribute

    Normally, serialized properties with isComposite = true are serialized as nested XMIObjectElements.
    In the case where the model is split across more than one file then a nested XMIReferenceElement would be used. Exceptionally, even within one file, it may be the case that a containing object has more than one serialized class-typed property with isComposite = true that, contain the same object or include it among their collection of objects. In such an exceptional case, because of MOF contstraints, only one of those properties can have an opposite with a non-empty slot. Objects of the property with the non-empty opposite slot are serialized as nested XMIObjectElements, and the other references to the same object are serialized either as XMIReferenceAttributes or nested XMIReferenceElements.

    This rule is very bad for several reasons:

    1) The criteria for determining which of the 3 possible options is very difficult to understand

    2) Words such as "Exceptionally" convey a sense that there is a distinction that should be seldom relevant in practice. This is definitely not the case. This rule affects all serializations of UML profiles and UML models that contain Structured Activities.

    3) Whether a model is serialized in one or multiple files has nothing to do with the intent of this rule. Mentioning this adds an unnecessary layer of complexity to the rule.

    4) The criteria for choosing between nested vs. reference/attribute serialization refers to unexplained considerations about MOF:

    • no explanation in the XMI spec
    • no cross-references to existing explanations in MOF specifications (it is even unclear which MOF specifications, if any, have such explanations)

    5) The combination of no illustrative example and of exceptional opacity has contributed to legitimate doubts as to whether there exists any truly conforming implementation of XMI 2.x (incl. 2.5.1) and whether claims of conformance to the XMI 2.x specification can be independently verified by non XMI experts.

    Suggest:

    a) Reword this rule to clearly explain all of what is necessary to unambiguously and deterministically determine whether a value of a composite property typed by a class must be serialized as a nested element, a nested reference or an attribute reference.

    b) Provide examples for all three options

  • Reported: XMI 2.5 — Wed, 22 Jun 2016 22:00 GMT
  • Updated: Thu, 23 Jun 2016 15:23 GMT

9.4.1 serialization of a null-valued property typed by an enumeration or primitive type

  • Key: XMI26-1
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Table 9.4.1 states:

    When the value of a Property is null, it is serialized as XMIValueElement with attribute nil=’true’.

    In UML, null means "lack of a value".
    MOF (which is based on a subset of UML) inherits this – that is, for MOF, null also means "lack of a value".

    Currently, many UML tools do not serialize null-valued properties according to the rule above, instead, the property is not serialized at all.

  • Reported: XMI 2.5 — Wed, 22 Jun 2016 21:45 GMT
  • Updated: Thu, 23 Jun 2016 04:59 GMT

XMI spec lacks support for profiles

  • Key: XMI26-4
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    In principle, any metamodel can have a profile extending it.
    The XMI spec only addresses producing an XMI schema for a metamodel. The XMI spec should also address the production of an XMI schema for a profile that extends one or model metamodels.

    In principle, any model that is an instance of a metamodel extended by one or more profile can be augmented with the application of such profiles. The XMI spec only addresses the production of an XMI document for the model itself. The XMI document production rules should also cover the augmentation of such a model corresponding to the profile-defined stereotypes applied and to the profile-defined datatypes & classes instantiated.

  • Reported: XMI 2.5 — Wed, 22 Jun 2016 22:14 GMT
  • Updated: Wed, 22 Jun 2016 22:14 GMT

9.4.1 serialization of a property typed by a structured datatype

  • Key: XMI26-3
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Table 9.4.1 states:

    Choice of:
    1. XMIObjectElement
    2. XMIValueAttribute
    3. Nested XMIValueElement
    By default instances of structured datatypes are serialized as if they were classes, as described in 7.8.7. This can be overridden by the tag org.omg.xmi.flattenStructuredDatatypes in which case the values of the Properties are serialized as a single string separated (by default) by commas. The default separator can be overridden by the XMI org.omg.xmi.valueSeparator tag.

    The flag org.omg.xmi.flattenStructuredDatatypes adds a layer of complexity for XMI interchange because tools need to handle effectively two different serialization strategies: flatten vs. structured.

    The benefit of flattened structured datatype value serialization is questionable because its relevance has not been established in current practice and current implementations.

    Suggest eliminating org.omg.xmi.flattenStructuredDatatypes.

  • Reported: XMI 2.5 — Wed, 22 Jun 2016 22:06 GMT
  • Updated: Wed, 22 Jun 2016 22:06 GMT

3.6.4 Inheritance Specification

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

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

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

XMI 1.2 Issue - Association elements with references

  • Key: XMI12-11
  • Legacy Issue Number: 5305
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

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

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

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

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

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

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

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

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

Invalid example model encoding XML

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

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

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

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

3.6.5 Attribute Specification

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

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

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

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

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

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

"3.6.1 Namespace Qualified XML Element Names"

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

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

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

General question to "3.6.4 Inheritance Specification"

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

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

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

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

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

    and for third subclass analogical:

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

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

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

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

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

    and than any n-subclass:

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

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

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

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

Empty Fragment Identifier in Link

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

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

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

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

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

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

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

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

    to

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

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

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

    to

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

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

Urgent XMI 2.0 issue: XML Schema Production

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

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

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

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

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

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

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

3.6.4 Inheritance Specification

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

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

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

XMI issue - referenceless composition does not export components

  • Key: XMI12-9
  • Legacy Issue Number: 5300
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

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

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

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

Production by Package Extent Example in 00-12-05

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

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

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

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

    Are these typos??? Sorry for nitpicking

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

EmbeddedObject is misused

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

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

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

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

Minor bug / typo in handling of References

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

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

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

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

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

EBNF incomplete for Attributes with complex types

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

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

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

Inconsistencies for classifier-level Attributes

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

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

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

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

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

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

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

    This does four things:

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

Specification addresses only generation not consumption (medium)

  • Key: XMI12-34
  • Legacy Issue Number: 4599
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

Anomalies with References and ordered Associations.

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

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

    Consider the following metamodel:

    package P {
    class C1

    { reference r1 to a1_e2 of A1; }

    ;

    class C2

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

    ;

    association A1

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

    association A2

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

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

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

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

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

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

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

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

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

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

UML: Using public identifiers to denote DTDs

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

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

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

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

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

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

Section 5.3 still uses old datatypes

  • Key: XMI12-40
  • Legacy Issue Number: 4580
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

Include Derived Attributes and References of Derived Associations

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

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

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

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

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

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

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

Garbled descriptions in ObjectAsElement (page 9-204)

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

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

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

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

    Or does it mean something else?

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

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

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

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

    According 9.5.4.2, the document should contain something like this:

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

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

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

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

Tool interchange recommendation insufficient (major)

  • Key: XMI12-30
  • Legacy Issue Number: 4605
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 3.10 has the following significant issues:

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

Problem with namespaces

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

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

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

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

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

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

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

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

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

    Basically, the new element would be defined just like

    {XMI.model}

    ,

    {XMI.metamodel}

    , and

    {XMI.metametamodel}

    .

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

MOF structured types missing from XMI 1.2

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

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

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

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

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

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

XMI issue - xmi.exporterId inconsistently used and undefined

  • Key: XMI12-20
  • Legacy Issue Number: 4790
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

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

Unclear URI format

  • Key: XMI12-26
  • Legacy Issue Number: 4702
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

bi-directional References and redundancy

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

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

    Discussion:

    For example, consider the following meta-model:

    package P {
    class C1

    { reference r1 to c2_end of A; }

    ;
    class C2

    { reference r2 to c1_end of A; }

    ;
    association A

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

    ;
    };

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

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

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

    So what?

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

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

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

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

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

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

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

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

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

Problems with section on Linking

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

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

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

Directory structure for OMG standard XMI documents and DTDs

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

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

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

Effect of xmi.import is unclear (medium)

  • Key: XMI12-33
  • Legacy Issue Number: 4601
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

Incomplete rules for non-Primitive Datatype values

  • Key: XMI12-39
  • Legacy Issue Number: 4581
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

DTD element content and multiplicities versus compliance.

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

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

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

    I argue that:

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

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

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

Association elements when no immediate references

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

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

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

org.omg.xmi.enumerationUnprefix

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

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

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

Nonexistent '' used (minor)

  • Key: XMI12-31
  • Legacy Issue Number: 4604
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

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

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

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

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

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

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

    <Acme:Wiz name="foo"/>

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

    // The Acme model:
    class Base

    { attribute String name: }

    class Derived: Base

    { attribute String name; }

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

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

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

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

    <Acme:Derived name="foo"/>

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

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

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

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

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

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

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

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

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

What IS this "General Datatype Mechanism" anyway?

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

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

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

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

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

Unclear software compliance - see also issues 3887 and 3889

  • Key: XMI12-21
  • Legacy Issue Number: 4705
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

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

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

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

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

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

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

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

Outmoded use of '|' as separator

  • Key: XMI12-23
  • Legacy Issue Number: 4704
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

[xmi] xmi.label / xmi:label

  • Key: XMI12-19
  • Legacy Issue Number: 4791
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

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

XMI does not document the tag used to determine XML Namespace

  • Key: XMI12-27
  • Legacy Issue Number: 4652
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

Reconsider XML attribute encoding of values in XMI 1.1

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

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

    Discussion:

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

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

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

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

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

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

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

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

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

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

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

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

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

Encoding of strings and characters in XMI documents

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

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

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

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

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

XML attribute encoding of values underspecified

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

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

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

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

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

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

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

    Which (if any) of the above is legal?

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

Composition Association problems

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

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

    Discussion:

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

    package P {
    class C1

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

    ;

    association A1

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

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

    ;
    };

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

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

    package P {
    class C1

    { // no reference to the_C2 of A1 }

    ;

    class C2

    { ... }

    ;

    association A1

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

    ;
    };

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

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

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

  • Key: XMI12-36
  • Legacy Issue Number: 4600
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

Example in A.5 is misleading

  • Key: XMI12-38
  • Legacy Issue Number: 4582
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

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

XMI document production rule 7c issue

  • Key: XMI12-41
  • Legacy Issue Number: 4505
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

DTD rules unclear for attributes of subclasses.

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

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

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

    This is ambiguous.

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

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

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

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

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

Document production rules for "un-Referenced" Associations.

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

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

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

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

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

Example 4 in A.5 is obscure (minor)

  • Key: XMI12-32
  • Legacy Issue Number: 4603
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

propose a new tag to be applied to metamodels

  • Key: XMI12-13
  • Legacy Issue Number: 4900
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

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

Adoption of XLink specification (minor)

  • Key: XMI12-29
  • Legacy Issue Number: 4606
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

What is the idea of encoding package contents?

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

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

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

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

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

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

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

OMG XML Metadata Interchange issue

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

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

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

UML conversion to MOF out of scope

  • Key: XMI12-24
  • Legacy Issue Number: 4703
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

Revise 7.13.2 XMI Document Exchange with Multiple Tools

  • Key: XMI21-4
  • Legacy Issue Number: 8669
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This applies to XMI 2.1 - ptc/04-06-11.

    The above section proposes a scheme that does not hold water. In particular it does not provide a means for the original tool to recognize its own objects. For this a simple extension is neded that assigns extenderIds at the same time as uuids. In addition it is also important that the exporterId is set.

    Proposed resolution: see ad/2005-03-06 for a change-barred proposed text.

  • Reported: XMI 2.0 — Thu, 31 Mar 2005 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

section 8.2.1 on page 46 (editorial)

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

    In section 8.2.1 on page 46, change the first three lines of rule
    4. ClassTypeDef from (Note mis-placed closing quote for "name"
    attribute)

    "<xsd:complexType name='" //Name of Class//
    ("mixed='true'")?
    "'>"

    to

    "<xsd:complexType name='" //Name of Class// "'"
    ("mixed='true'")?
    ">"

  • Reported: XMI 2.0 — Wed, 19 May 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

XMI 2.0 terminology

  • Key: XMI21-3
  • Legacy Issue Number: 7648
  • Status: open  
  • Source: Anonymous
  • Summary:

    I am reading through the XMI 2.0 "convenience document" ptc/04-06-11 and
    I am getting stuck trying to figure out the terminlogy. In particular,
    what precicely is a "reference," what is an "association end," and what
    is an "association role?" "Reference" and "association end" seem to be
    leftovers from MOF 1.4, while "association role" is maybe a leftover
    from UML 1.x. But, as far as I can tell these constructs do not exist
    any more in MOF 2, so some definitions for them are need. Are these
    suitable definitions?:

    Reference: A reference is a Property owned by a Class (ownedProperty)
    with isComposite=false and a type that is a subtype of Class.
    Association End: An association end is a Property owned by an
    Association (ownedEnd).
    Association Role: An association role is an association end.

    In section 7.8.4, there is a statement "For multi-valued Properties, no
    XML attributes are declared; each value is encoded as an XML element."
    However, the OMG-provided XMI 2.0 representations of the EMOF/CMOF
    models use attributes to represent multi-valued Properties that meet the
    definition of "Reference" above. This seems to be a contradiction. I
    assume that the XMI spec should say "For multi-valued Properties, no XML
    attributes are declared; each value is encoded as an XML element, unless
    the Property is a Reference."

  • Reported: XMI 2.0 — Fri, 13 Aug 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Mandatory Extensions when enforceMinimumMultiplicity is true

  • Key: XMI21-8
  • Legacy Issue Number: 7306
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    My base document is the MOF 2 XMI Final Adopted Specification,
    ptc/03-11-04.

    There is an issue with rule 4c, part of the XML Schema Production rules,
    on page 46.

    If either org.omg.xmi.enforceMinimumMultiplicity or org.omg.xmi.enforce-
    MaximumMultiplicity is true, then rule 4 places the 4b:ClassContents in
    an xsd:sequence element – and subelements are then decorated with
    minOccurs and maxOccurs attributes.

    However, rule 4c still emits the constant element,
    <xsd:element ref='xmi:extension'/>

    Therefore, in this case, the extension element becomes mandatory, with
    an implicit multiplicity of 1..1. This needs to be changed to
    <xsd:element ref='xmi:extension' minOccurs='0' maxOccurs='unbounded'/>

  • Reported: XMI 2.0 — Thu, 6 May 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

section 8.2.1 on page 44 (editorial)

  • Key: XMI21-5
  • Legacy Issue Number: 7383
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    In section 8.2.1 on page 44, change rule 1g. XMIFixedAttribs from
    (missing end of tags on line 2 and 4, missing namespace tag on line 3)

    ( "<xsd:attribute ref='xmi:id'"
    "use='optional'>" |
    "<attribute name='" //Id attrib name// "'"
    "type='xsd:ID' use='optional'" )
    "<xsd:attributeGroup ref='xmi:ObjectAttribs'/>"

    to

    ( "<xsd:attribute ref='xmi:id'"
    "use='optional'/>" |
    "<xsd:attribute name='" //Id attrib name// "'"
    "type='xsd:ID' use='optional'/>" )
    "<xsd:attributeGroup ref='xmi:ObjectAttribs'/>"

  • Reported: XMI 2.0 — Wed, 19 May 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

XMI for TypeLibrary::Objects::Object is Unspecified

  • Key: XMI21-7
  • Legacy Issue Number: 6345
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    Issue for XMI for MOF 2

    The specification of XMI for MOF 2 does not describe handling of MOF's
    object type, which is a supertype of ordinary class types as well as data
    types. Particularly, it does not describe what XML results from the
    following small example. The whole model is this:

    In a package M there is one class X having one owned attribute named Y of
    type TypeLibrary::Objects::Object with multiplicity 1..1.

    Consider the following 4 instances of X:

    1. An instance of X having Y set to the second instance of X.
    2. An instance of X having Y set to the integer 3.
    3. An instance of X having Y set to the string "this UNICODE string".
    4. An instance of X having Y set to that same fourth instance of X.

    What would an XMI-based serialization of these four instances of X look
    like?

    What would an XML schema for the package M look like?

  • Reported: XMI 1.3 — Thu, 4 Sep 2003 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

AssociationEnds without references

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

    Improvements to grammar for AssociationEnds that have no references.

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

"Inputs" that define an XMI metadata interchange format.

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

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

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

    1) The XML namespace used to abbreviate element names

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

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

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

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

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

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

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

Miss-stated XMI compliance points.

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

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

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

    2) XMI DTD compliance -

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

    3) XMI document compliance -

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

    4) Usage compliance -

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

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

    5) XMI MOF subset optional compliance -

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

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

    6) XMI DTD optional compliance -

    • The wording is horribly vague; for example

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

    A lawyer would have a field day with this!

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

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

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

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

    7) XMI Document optional compliance -

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

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

    8) Usage optional compliance -

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

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

Editorial: remove unnecessary hitorical references.

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

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

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

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

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

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

Bug in pseudo-code for PackageDTD

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

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

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

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

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

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

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

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

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

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

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

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

XMI Tags

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

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

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

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

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

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

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

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

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

XMI.reference suppression

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

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

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

Example C Multiplicity

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

    Clarify if example should show multiplicity as structure or object.

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

Usage of XMI for GIS ISO 19118/TC211

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

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

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

XMI cross-version compatibility

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

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

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

ISSUE: XMI for MOF 2 does not reflect MOF 2 model

  • Key: XMI21-11
  • Legacy Issue Number: 6636
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    The XMI for MOF 2 Specification seems to have been written as if referring to a MOF 1 Specification. For example, it defines mappings and mapping parameters for AssociationEnd, which is not in MOF 2.

    Recommended Resolution: Restate the XMI rules and mapping parameters in terms of MOF 2 and UML 2.

  • Reported: XMI 1.3 — Thu, 20 Nov 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

ISSUE: XMI for MOF 2 should address models, not just metamodels

  • Key: XMI21-9
  • Legacy Issue Number: 6635
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    The XMI for MOF 2 specification has not been updated to reflect one of the key goals in the alignment of MOF 2 with UML 2, which is that XMI becomes applicable to UML class models in general rather than to MOF-based metamodels only.

    Recommended Resolution: Replace "metamodel" with "model" in most places within the XMI for MOF 2 specification. Also, in describing the mapping from classes, properties, etc. to XML, do not use wording that implies a restriction to a MOF context except where MOF is , such as for elements of the MOF Type Library.

  • Reported: XMI 1.3 — Thu, 20 Nov 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

section 8.2.1 on page 46 (editorial)

  • Key: XMI21-6
  • Legacy Issue Number: 7384
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    In section 8.2.1 on page 46, change the fourth and fifth line of
    rule 4. ClassTypeDef from (missing eod of tag '>')

    ( "<xsd:complexContent>"
    "<xsd:extension base='" 4a:ClassTypeName "'")?

    to

    ( "<xsd:complexContent>"
    "<xsd:extension base='" 4a:ClassTypeName "'>")?

  • Reported: XMI 2.0 — Wed, 19 May 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

section 7.10.2.2(.2) on page 23 (editorial)

  • Key: XMI21-1
  • Legacy Issue Number: 7381
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    I've posted these to the XMI 2.1 RTF before. Since these typos still
    exist in the MOF2XMI Final Adopted Spec (ptc/03-11-04), I figured I
    should send them again. As editorial issues, they were not assigned
    an official issue number.

    In section 7.10.2.2(.2) on page 23, the URN for the XMI namespace
    needs to be in lowercase, according to W3C. Thus, change

    xmlns:xlink="http://www.w3.org/1999/XLink"

    to

    xmlns:xlink="http://www.w3.org/1999/xlink"

  • Reported: XMI 2.0 — Wed, 19 May 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Documentation of References in section 6.6

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

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

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

XMI MOF Subset" optional compliance point.

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

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

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

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

Section 6.12 needs rewriting.

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

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

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

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

Editorial: Fix up the cross-references.

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

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

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

    And so on.

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

DTD generation rules for composed Packages.

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

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

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

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

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

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

DTD production clarifications for nested Packages

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

    When a Package contains another Package:

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

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

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

Status of pseudo-code in Chapter 7

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

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

    Chapter 7.1 states in the second paragraph:

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

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

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

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

XMI.content declaration

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

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

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

Allow suppression of reference serialization

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

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

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

Containment as links

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

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

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

QName for XML attribute values

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

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

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

Appendix C example

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

    Portions of the example are inconsistent

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

XMI for MOF 2 defines tagged values

  • Key: XMI21-10
  • Legacy Issue Number: 6394
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    The XMI for MOF 2 specification defines several tagged values for adding
    data to a UML model that guide generation of an XML Schema and that guide
    document production. But these tags appear to be defined as if for MOF 1.
    To be appropriate for MOF 2 these must be defined using either an extension
    to the MOF or UML core models (as a package that adds to MOF and/or UML
    infrastructure) or they must be defined as a UML 2 profile. In either case,
    an official XML rendering of the model or profile is required. And given
    the big change from MOF 1, an example of such tags as they would appear in
    an XMI-based XML document of an example model would be very helpful.

  • Reported: XMI 1.3 — Thu, 30 Oct 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

Open DTD content for subclasses

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

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

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

Examples with references confusing.

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

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

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

Reference to deleted text on fully qualified names.

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


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

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

Element Identification Attributes

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

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

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

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

  • Reported: XMI 1.1 — Thu, 7 Oct 1999 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT

The UML and MOF DTD appendices are poor examples.

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

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

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

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

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

DTD generation for DataTypes with typecode.kind == tk_alias

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

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

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

Specifying Attributes vs Elements

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

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

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

Additional examples

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

    More examples would clarify the specification.

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

Typo in applicability scenarios

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

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

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

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

no documented standard serializiation of MOF 1.4 as an XMI 2.0 schema

  • Key: MOF24-59
  • Legacy Issue Number: 7605
  • Status: closed  
  • Source: ISIS ( Matt Emerson)
  • Summary:

    There is no documented standard serializiation of MOF 1.4 as an XMI 2.0 schema. OMG has published a document for MOF 1.3 as an XMI 2.0 document and MOF 1.4 and an XMI 1.2 DTD, but not MOF 1.4 as an XMI 2.0 schema. This is despite the fact that XMI 2.0 was designed around MOF 1.4. As far as I know, OMG has not released a single full XMI 2.0 schema example. Do any exist?

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

    This is requesting that an XMI-compliant XML Schema be provided for MOF itself, as an example of a metamodel. This is an issue for MOF not XMI.

    Revised Text:

    • none -

    Disposition: Transferred to MOF RTF

  • Updated: Sun, 8 Mar 2015 15:36 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

Examples are instances of non-MOF metamodels (medium)

  • Key: XMI11-101
  • Legacy Issue Number: 4602
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

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

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

MOF and UML tagged value alignment.

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

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

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

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

XMI Schema Issue - representation for Associations

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

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

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

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

Introduce extenderVersion

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

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

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

More use of schema structural constraints

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

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

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

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

Canonical XMI (ptc/2013-08-28): need rules for generating xmi:id and xmi:uuid for auxiliary XML elements

  • Key: XMI24-10
  • Legacy Issue Number: 19719
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Key: XMI24-8
  • Legacy Issue Number: 18838
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    MOF/XMI defines the schemaType tag as follows: "The name of a datatype defined in the XML Schema Datatype specification."

    First,the examples in the MOF/XMI specification and current use of this tag in OMG's XMI artifacts use datatype URIs, not datatype names.

    Second, the definition of this tag is vague about which datatypes are allowed.

    Consider for example "precision decimal", a datatype that is explicitly mentioned but not explicitly defined in the XML Schema Datatypes spec: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#primitive-vs-derived
    This datatype is explicitly defined in a different specification but in the "xs" namespace: http://www.w3.org/TR/xsd-precisionDecimal/#precisionDecimal

    This example illustrates the ambiguity of the scope as currently specified, that is, is "xs:precisionDecimal" allowed as a value for schemaType?

    Third, even if schemaType were to be clarified to be some subset of datatypes defined in the "xs" namespace, there are legitimate business reasons to expect greater flexibility.

    - Several OMG specifications define XSDs (e.g., BPMN, DTV, Â…) If these include XML Schema datatype definitions, why are we precluded from referring to them via a PrimitiveType that has a schemaType tag pointing to their URI?

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

Which type of name should be used

  • Key: XMI24-1
  • Legacy Issue Number: 7599
  • Status: open  
  • Source: ISIS ( Matt Emerson)
  • Summary:

    This problem is preventing me from implementing a XMI 2.0 Schema generator for a MOF 1.4 metamodeling environment. The specification is often unclear about which type of name (short name, fully-qualified name, or namespace-qualified name) should be used. >From section 1.8.1: “The XML element name for each metamodel class, package, and association in a document is its short name.” Then, in section 2.2.1, rule 4 we have “ClassTypeDef ::= "<xsd:complexType name=’" //Name of Class//Â…”. Now, the w3 xml schema specification (http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ states that “no complex type definition can have the same name as another simple or complex type definition.” If the spec means that we should use the short name of the Class in rule 4 above, then it isn’t in line with the xml schema specification, because it’s obvious that several classes in different namespaces of the same metamodel can have the same short name. Furthermore, the w3 schema specification defines the name attribute of a complexType declaration to be of type NCName, or ‘non-colonized name’. This means that we can’t use the namespace-qualified name for the Class either. The only solution is to use the fully-qualified name for metamodel elements** when defining their types. **The fully-qualified name of a metamodel element lists all of the encapsulating MOF Namespaces of the element. So, if you have Class A in nested Package B in outermost Package C, the qualified name of A would be ‘C.B.A’.

  • Reported: XMI 2.0 — Tue, 27 Jul 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

XMI issue - root elements for XMI Schemas

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

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

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

    Proposed resolution:

    Define two boolean XMI Tags:

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

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

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

metamodel for XML Schema

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

    Given that the XMI spec contains a metamodel for XML Schema it would be possible to express the Schema production rules using QVT as a transformation from the MOF metamodel to the XSD metamodel. This would create a more rigorous specification that could be automated

  • Reported: XMI 2.1 — Sat, 29 Apr 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Revise XMI examples in 9.4

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

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

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

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

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

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

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

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

    Metamodels do not necessarily use names compliant with XML syntax.

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

  • Reported: XMI 2.4 — Thu, 19 May 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

No XML-Schema for UML-XMI

  • Key: XMI24-7
  • Legacy Issue Number: 16582
  • Status: open  
  • Source: Software Systems Engineering ( Holger Eichelberger)
  • Summary:

    While for older versions of XML the concrete syntax for persisting UML models was given in DTD, for newer versions of XMI a related concrete syntax specification e.g. as XML Schema is missing (even if the syntax is described in ptc/2010-12-06). Pure syntax compliance tests for given XMI files cannot be performed.

  • Reported: XMI 2.4 — Wed, 5 Oct 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Name transformation

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

    MOF/UML does not require names of elements in a metamodel to be valid XML names.

    Therefore the XMI spec should document a transformation to be applied to cope with spaces, punctuation etc to be used for XML element and attribute names.

  • Reported: XMI 2.4 — Thu, 9 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

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

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

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

    (3:Extension)* should be added to 2a

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

Remarks to chapter "3.4.3 Derived Types and References" in XMI Spec. , v 2

  • Key: XMI21-20
  • Legacy Issue Number: 6065
  • Status: open  
  • Source: Anonymous
  • Summary:

    Remarks to chapter "3.4.3 Derived Types and References" in XMI Spec. , v 2.0, S. 3-15
    There it says:

    "... An instance of Company can use xsi:type to
    indicate that its HQAddress is actually of type USAddress and includes a zipcode:
    <Company xmi:id="Company_1" name="Acme">
    <HQAddress xmi:type="USAddress" xmi:id="Address_1"
    Street="Side Street" City="Hometown" zipcode="90210"
    ... "
    The 'HQAdress'-Element has a 'xmi:type'-Attribute. Parsing this with Xerces 2.4.0 gives problems, since a 'xsi:type' Attribute is required. Derived types must be specified with the 'xsi:type'-Attibute. Maybe the line
    "... An instance of Company CAN use xsi:type ..."
    should be changed in
    " ... An instance of Company MUST use xsi:type ..."

  • Reported: XMI 1.3 — Wed, 13 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Are xlinks legal?

  • Key: XMI21-19
  • Legacy Issue Number: 6054
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    maybe this is just because of my ignorance, but I'm running into
    a problem trying to validate documents against an XMI based schema
    here, and it looks like the validator has a point.

    As usual, my base document is XMI 2.0, formal/03-05-02.

    Section 1.10.2 "Linking" describes the usage of XLink simple links
    and XPointers to link across documents.

    However, looking at the schema production rules (page 2-2 to 2-5,
    rules 4g:ClassAttListItems and 1g:XMIFixedAttribs, as well as the
    LinkAttribs attributeGroup in the Fixed Schema Declarations on
    page 2-10, the xlink:href is never declared as a legal attribute
    for complexTypes.

    Hence I see why the parser (Xerces-C, when requested to validate)
    complains about attempts to use XLinks in a document.

    I think it is paramount that documents validate against the schema.
    (Am I the first to attempt validation? Can't be.)

    I realize that there doesn't seem to be a schema for XLinks yet,
    so the short-term solution might be to allow the "normal" href
    attribute to contain an XPointer.

    As a minor nitpicking, page 1-23 gives the XLink namespace as
    "http://www.w3.org/1999/XLink", whereas the W3C recommendation
    for XLink uses "http://www.w3.org/1999/xlink" (note case).

  • Reported: XMI 1.3 — Wed, 13 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

XMI 2.0 issue: Proxies and Multiplicities

  • Key: XMI21-12
  • Legacy Issue Number: 5950
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    Doc references are based on formal/03-05-02.

    In a Schema that is produced by the XML Schema Production
    rules, enforcement of multiplicities is incompatible with
    the use of proxies.

    According to 1.10.1, page 1-21, "Elements act as a union,
    where they are either a definition or a proxy. Proxies use
    the LinkAttribs attribute group to define the link, and
    contain no nested elements."

    However, if the org.omg.xmi.enforceMinimumMultiplicity is
    true, then the generated schema does not allow the complex-
    Type's content to be empty, and so proxies cannot exist in
    an XML document.

    As a simple fix, the 4b:ClassContents could be wrapped into
    an additional choice element, as in

    <xsd:choice minOccurs="0">
    <xsd:sequence>
    4b:ClassContents
    </xsd:sequence>
    </xsd:choice>

    This would allow the element to be empty. However, in this
    form, an XML document that contained both link attributes
    and contents would still validate.

    A stronger solution would be to make a choice between a
    link element and contents, by removing the LinkAttribs from
    the ObjectAttribs attribute group and by, in rule set 4,
    defining something along the lines of

    <xsd:choice>
    <xsd:sequence>
    4b:ClassContents
    </xsd:sequence>
    <xsd:element name="href" type="xsd:string">
    <xsd:element name="idref" type="IDREF">
    </xsd:choice>

    This way, an element in a validating document could only be
    either a proxy or not.

    As a side note to this issue, there are obviously unpleasant
    side effects when org.omg.xmi.enforceMinimumMultiplicity is
    true and org.omg.xmi.element is false. org.omg.xmi.enforce-
    MinimumMultiplicity=true should have the same effect as
    if org.omg.xmi.element=true and org.omg.xmi.attribute=false.

  • Reported: XMI 1.3 — Thu, 12 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT


More type safety in generated schemas

  • Key: XMI21-14
  • Legacy Issue Number: 5981
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    Document refs are against formal/03-05-02.

    According to rule 4d of the Schema production rules on page 2-5,
    "The type is 'xsd:string' for simple attributes".

    I assume here that "simple attributes" refers to MOF primitive
    types (Boolean, Integer, Long, Float, Double, String).

    I wonder why xsd:string was used for all these primitive types,
    when perfectly suitable data types are predefined for XML Schemas:
    there's xsd:boolean, xsd:int, xsd:long, xsd:float and xsd:double
    that exactly match the data types used by MOF.

    I propose to make use of these existing types to strengthen the
    generated schema.

  • Reported: XMI 1.3 — Mon, 23 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Schema production rule 4d clarification request

  • Key: XMI21-13
  • Legacy Issue Number: 5975
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    Document refs are against formal/03-05-02.

    Maybe it's because I'm still struggling with the details
    of XML Schemas and MOF, but I'm confused with rule 4d of
    the XML Schema Production rules (EBNF on page 2-4, expla-
    nation on page 2-5).

    • According to the EBNF, a type='xmi:Any' is an output
      option, but according to the explanation, this option
      is never used.
    • The explanation goes, "The type is 'xsd:string' for simple
      attributes ..." It is not clear to me what constitutes a
      "simple" vs. "non-simple" attributes. I assume this refers
      to MOFs PrimitiveTypes, but in any case a clarification
      would be useful.
    • The explanation goes on, "The type is [...] part of the
      of the value of the org.omg.xmi.schemaType tag". Why does
      it say "part of"? What should be removed from the value?
    • There is also a question of precedence. I guess the
      intention is that the schemaType tag should take
      precedence over the "simple attribute" decision?
    • There is no "else:" What if the attribute is not simple,
      not an enumeration, and the schemaType tag is not set?
      (Or maybe that is not possible in MOF?)
  • Reported: XMI 1.3 — Mon, 23 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

tag value constraint in chapter 1.11.2

  • Key: XMI21-18
  • Legacy Issue Number: 6011
  • Status: open  
  • Source: TU Braunschweig ( Lorenz Däubler)
  • Summary:

    Schema Production Rule 4i says, if tag enforceMinimumMultiplicity is true, IDREF is required. But tag value constraint in chapter 1.11.2 says, that with the enforceMultiplicity tag, attributes must be serialized as elements.

  • Reported: XMI 2.0 — Tue, 22 Jul 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Schema production rule for 'ClassReferences' (4.e)

  • Key: XMI21-17
  • Legacy Issue Number: 6010
  • Status: open  
  • Source: TU Braunschweig ( Lorenz Däubler)
  • Summary:

    The Schema production rule for 'ClassReferences' (4.e) does not conform with the Document Production Rule 'Reference Element' (4). In the Class References the linking attribues are missing

  • Reported: XMI 1.3 — Mon, 21 Jul 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The ClassAttribRef Production Rule (4i) can be enhanced

  • Key: XMI21-16
  • Legacy Issue Number: 6009
  • Status: open  
  • Source: TU Braunschweig ( Lorenz Däubler)
  • Summary:

    The ClassAttribRef Production Rule (4i) can be enhanced by adding a minLength/maxLength facette to the reference attribute. With this facette the cardinality can be constrained.

  • Reported: XMI 2.0 — Mon, 21 Jul 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

How to serialize values of the PrimitiveType UnlimitedNatural

  • Key: XMI21-24
  • Legacy Issue Number: 12407
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The XMI is not explicit as to how to serialize values of the PrimitiveType UnlimitedNatural. In practice, and in the normative metamodels for UML as well as MOF, the value ‘’ has been used to represent ‘unlimited’ (as opposed to the value ‘-1’ which was used at UML/MOF 1.x). Rule 2i in section 6.3 states: Use this production rule to serialize an attribute whose type is not an object and whose value can be represented by a string. Multi-valued attributes cannot be serialized as XML attributes. If the attribute’s type is one of the types defined by the XML Schema Part 2: Datatypes specification, serialize the value as specified in that specification. PROPOSED RESOLUTION Add the following sentence to the end of the above paragraph: “Unless specified otherwise, values of other types may be serialized as strings using any permitted visual notation for that type. This applies to values for the Primitive Type UnlimitedNatural, where unlimited is serialized, as well as displayed, as ‘’.

  • Reported: XMI 2.1 — Wed, 23 Apr 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page: 60

  • Key: XMI21-23
  • Legacy Issue Number: 9359
  • Status: open  
  • Source: Klocwork ( Adam Neal)
  • Summary:

    There are two typo's for element 2h:FeatureAttrib. >From Document: ------------------- 2h:FeatureAttrib ::= X2i:MIValueAttribute | 2jXMIReferenceAttribute ------------------- - X is misplaced for 2i element - missing colon for 2j element Should be: ------------------- 2h:FeatureAttrib ::= 2i:XMIValueAttribute | 2j:XMIReferenceAttribute -------------------

  • Reported: XMI 2.1 — Wed, 8 Feb 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page: 58

  • Key: XMI21-22
  • Legacy Issue Number: 9358
  • Status: open  
  • Source: Klocwork ( Adam Neal)
  • Summary:

    There are two issues in this section of the document pertaining to referencing elements which only exist in the specification for the previous version, formal/05-05-01 (which is a changebar version of formal/03-05-02). First issue: 1:Document references 2:ContentElements. Here, 2:ContentElements does not exist in the formal/05-09-01 specification. Second issue: 1a:XMI references 5j:Extension. Here, 5j:Extension does not exist in the formal/05-09-01 specification.

  • Reported: XMI 2.1 — Wed, 8 Feb 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

How are attributes and compositions inherited?

  • Key: XMI21-21
  • Legacy Issue Number: 7334
  • Status: open  
  • Source: None ( Arno Leist)
  • Summary:

    In my understanding of the XMI 2.0 spec, it is not clear about how attributes and compositions are inherited. On page 34 point 1.8.7 is stated, that for attributes and compositions copy-down inheritance is required. Contrarily is rule 4c on page 57, which states that only local attributes, references, and compositions are included if the org.omg.xmi.useSchemaExtensions is set to true.

  • Reported: XMI 2.0 — Wed, 12 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

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

15.3.11 State (from BehaviorStateMachines, ProtocolStateMachines)

  • Key: UML25-629
  • Legacy Issue Number: 7862
  • Status: closed  
  • Source: Anonymous
  • Summary:

    1. Attributes:

    /isComposite

    /isSimple

    /isSubmachineState

    defined without a type ( it must be Boolean).

    2. Associations:

    redefinedState : State [0..1]

    Must be subsets RedefinableElement::redefinedElement.

    3.

    region : Region [*] – subsets ownedMember

    Must be “subsets Namespace::ownedMember”.

    4.

    /redefinitionContext : Classifier [1]

    This member must redefine RedefinableElement::redefinitionContext (they have different multiplicity).

    5.

    region : Region [0..1]

    Second member named ‘region’ with another multiplicity and different semantic.

    6. I think some associations must subset members from parents, but this is not present in spec. I think this chapter needs review.

  • Reported: XMI 1.0 — Tue, 31 Aug 1999 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

15.3.14 Transition (from BehaviorStateMachines)

  • Key: UML25-620
  • Legacy Issue Number: 7864
  • Status: closed  
  • Source: Anonymous
  • Summary:

    1. Association:

    /redefinitionContext : Classifier [1]

    Must redefine RedefinableElement::redefinitionContext (different multiplicity).

    2.

    container [1]

    Defined without type (but (wonder?) with multiplicity!). J

    3.

    Generalizations: from NamedElement (from Kernel, Dependencies) and from RedefinableElement (from Kernel).

    But RedefinableElement inherited from NamedElement. What deep sense of this double inheritance from NamedElement?

  • Reported: XMI 1.0 — Tue, 7 Sep 1999 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

In normative XMI file for the metamodel, no Associations have a name.

  • Key: UML22-534
  • Legacy Issue Number: 7105
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In the normative XMI file for the metamodel, no Associations have a
    name.
    The name is needed for generating APIs and (in some cases) XMI elements;
    and their absence actually makes UML2 an invalid MOF2 metamodel: MOF2
    Core has the following constraint for CMOF:
    [6] Names are required for all classifiers and features (though there is
    nothing to prevent these names being automatically generated by a tool).

    (Association is a classifier)

    We could get by with not having a name in the MDL and auto-generating a
    name into the XMI. This is in fact what the Unisys XMI plug-in did when
    no Association name was provided - and this was hence reflected in the
    normative XMI for UML 1.x (the names were of the form A_<end1>_<end2>).

  • Reported: XMI 2.0 — Mon, 8 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2 Super/Interactions/Constraints for create messages

  • Key: UML22-533
  • Legacy Issue Number: 6989
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    page 429 Constraints for message need to include "no EventOccurences before receiving the create message". In the graphic notation this is handled by defining the create graphic path as flowing into the Lifeline head symbol, but since we do not want to introduce the concept of a Lifeline head in the meta-model, we need an additional constraint.

    Constraints need to be updated as new sorts of messages are added.

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML2 Infra/11.5.1/Invalid reference to Attribute class

  • Key: UML22-536
  • Legacy Issue Number: 7274
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In section 11.5.1 (DataType) the first association is specified as:

    ownedAttribute: Attribute[*] The Attributes owned by the DataType.

    This is out of date: the class Attribute has been replaced by Property,
    though the association name is OK referring to 'Attribute'. This is
    reflected in the diagram above that text (Fig 86).

    Proposed resolution:
    Replace the above text with:
    ownedAttribute: Property[*] The Properties owned by the DataType.

  • Reported: XMI 2.0 — Wed, 28 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Sending a signal after a delay

  • Key: UML22-475
  • Legacy Issue Number: 4937
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    Sending a signal after a delay

  • Reported: XMI 1.3 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The feature requested is already supported in UML 2.1: Precede an action by an AcceptEventAction, where the latter references a trigger that refers to a TimeEvent. Thus, for example, if you have a sequence of an AcceptEventAction with a TimeEvent specifyinig the desired delay and a SendSignalAction, then the signal will not be sent until the delay has passed. Note that this feature is extremely generic, probably giving the user even too much support (you can define a statemachine purely with actions, if there are not proper constraint placed on the events allowed in the AcceptEventAction).

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

Does visibility apply to creating an destroying links?

  • Key: UML22-474
  • Legacy Issue Number: 4448
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    It isn't clear whether visibility of association ends applies to
    creating and destroying links. If it does, then what if one end is
    private and the other public, can the private end create or destroy
    a link?

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

UML 1.5 table of contents

  • Key: UML22-520
  • Legacy Issue Number: 6665
  • Status: closed  
  • Source: EWSolutions ( Patrick Cross)
  • Summary:

    The example text <Company xmi:id="Company_1" name="Acme"> <HQAddress xmi:id="Address_1" Street="Side Street" </Company>City="Hometown"/> should be <Company xmi:id="Company_1" name="Acme"> <HQAddress xmi:id="Address_1" Street="Side Street" City="Hometown"/> </Company>

  • Reported: XMI 2.0 — Wed, 3 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Components / provided and required interfaces -- derived or subsets

  • Key: UML14-558
  • Legacy Issue Number: 6875
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Should Component::provided and Component::required really be derived? It seems that these sets of interfaces should be subsets of the sets of interfaces implemented/used by the component and/or its realizing classifiers, not derived from them

  • Reported: XMI 2.0 — Fri, 2 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

"Physical" Metamodel Package Structure (uml-rtf)

  • Key: UML14-554
  • Legacy Issue Number: 3123
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The package structure of UML 1.3 makes it difficult to deploy small parts of
    the "physical" metamodel separately. For example, a MOF-based facility that
    supports classes from Behavioral_Elements.Common_Behavior must support all
    of Behavioral_Elements. A facility that supports Exceptions must also
    support Use Cases and State Machines. This has been a problem in the
    formation of the CWM metamodel which extends UML. Its interfaces and DTDs
    are made to be much too large.

    The result of UML currently having three metamodels (two of which are large)
    rather than many smaller metamodels is that the IDL modules are very large
    and so are the DTDs. Breaking the metamodels into several smaller ones will
    allow smaller interface sets and DTDs that can be mixed and matched to
    provide necessary functionality without a huge overhead.

  • Reported: XMI 1.1 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

TaggedValue in TaggedValue

  • Key: UML14-556
  • Legacy Issue Number: 4726
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 metamodel, a ModelElement can contain any number of
    taggedValues, of type TaggedValue [UML 1-4, pp. 2-76].

    However, because a TaggedValue itself is a ModelElement [UML 1-4, pp. 2-76],
    it can itself contain taggedValues.

    The question is: is this really intended? And if so: please explain the
    semantics of such a construction.

    If not, at simple well-formedness rule

    self.taggedValue = { }

    attached to TaggedValue would do the trick.

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

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

Ambiguous semantics of classifier ownerscope

  • Key: UML14-555
  • Legacy Issue Number: 4446
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of classifier ownerscope is ambiguous for structural
    features declared on classifiers that have children. It is not
    defined whether this gives value for the classifier and all its
    descendents, or values for the classifier and each descendant
    separately.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML2 super/notation/Keywords

  • Key: UML14-471
  • Legacy Issue Number: 6877
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This is a general issue that is quite pervasive. I think it is important
    enough to be considered by the FTF.

    The specification is littered with keywords which are used on diagrams
    to indicate various things.

    What the specification sorely needs is an Appendix that gathers them all
    together. And cross-references each with where it is defined and the
    compliance level it is associated with.
    Also what it needs is a general description of the semantics of
    keywords, how they differ from 'Standard Stereotypes' and associated
    constraints - e.g. it should not be allowed to declare a Stereotype with
    a name which, when decapitalized, is the same as a keyword (since they'd
    be indistinguishable).

    Arguably keywords would be depicted with a distinct notation from
    stereotypes (based on language design principles and to help users
    interpret diagrams where they see words in guillemets and don't know
    whether to look it up in the list of keywords or stereotypes) but that
    is probably too major a change to make at this stage. However the
    notation should be clarified to cover the following cases:
    A) if the same element requires a keyword and has a stereotype applied
    are they shown in 2 separate <<xxx>> expressions or in one, separated by
    a comma?
    B) if a stereotype is applied to a class normally indicated by a
    keyword, does that keyword still need to be provided?

  • Reported: XMI 2.0 — Thu, 8 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Appendix B/Standard Stereotypes too heavyweight and incompletely defined

  • Key: UML14-470
  • Legacy Issue Number: 6876
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This is in my opinion important enough to be considered by the FTF since
    it affects implementability.

    Appendix B contains a list of Standard Stereotypes.
    Ironically, due to the nature of the UML2 Profile mechanism this
    mechanism is more heavyweight than a subclass since it requires a
    separate instance - so for the <<call>> stereotype of Usage one ends up
    with not only a instance of Usage but an attached instance of Call -
    this is far more heavyweight than having a distinct subclass of Usage
    which would result in only one object. And it's also harder to process
    via XMI or APIs.

    The Appendix is not adequate as a definition and does not use the
    official Stereotype notation? In particular it does not make clear the
    name of the instance of Stereotype (which I can only guess would be the
    capitalized form of the stereotype keyword e.g. "Call"), nor does it
    specify the name of the association used to attach an instance of the
    stereotype with the instance of the metaclass. And, of course, is there
    actually a Profile object (or objects) that contains these stereotypes?
    Can users consider this Profile already applied to any UML model or does
    it have to be explicitly done or is this a variation point?

    Finally, Appendix B is not properly referenced: 7.14.1 refers to the
    "Standard Profiles chapter" and 8.3.3 and 10.3.1 refer to "The UML
    Standard Profile".

  • Reported: XMI 2.0 — Thu, 8 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Interactions / incorrect multiplicity for PartDecomposition

  • Key: UML14-480
  • Legacy Issue Number: 6925
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The description of Lifeline on p. 427 (and Figure 331 on p. 409) indicates that the Lifeline::decomposedAs property is mandatory. This property refers, indirectly through a PartDecomposition, to an interaction the describes the internal workings of the ConnectableElement that the Lifeline represents.

    Unfortunately, there are common situations in which the decomposedAs property cannot be specified because the ConnectableElement is not decomposable (i.e., is not structured). In fact, the first constraint on p. 431 in the description of the PartDecomposition metaclass makes this very clear: "PartDecompositions apply only to Parts that are Parts of Internal Structures not to Parts of Collaborations."

    Therefore, we would request that the specification be amended to make the Lifeline::decomposedAs property optional (multiplicity [0..1]). If you can amend the generated multiplicity in your API in advance of any changes to the spec, that would be greatly appreciated!

  • Reported: XMI 2.0 — Sun, 18 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

The contents of the Interfaces package is shown in Figure 51

  • Key: UML14-479
  • Legacy Issue Number: 6913
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    "The contents of the Interfaces package is shown in Figure 51. The Interfaces package is one of the packages of the Classes package. "

    Should be "Figure 58"

  • Reported: XMI 2.0 — Fri, 16 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Interactions / navigability of enclosingOperation

  • Key: UML14-482
  • Legacy Issue Number: 6928
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Should InteractionFragment::enclosingOperation be navigable? The association end is named and even has a subset constraint, but the association isn't navigable in that direction for some reason (see Figure 329).

  • Reported: XMI 2.0 — Sun, 25 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Dependencies / Abstraction should have an optional mapping

  • Key: UML14-481
  • Legacy Issue Number: 6926
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In section 7.14.1 (Abstraction) it is stated explicitly that the mapping associated with an abstraction is optional (as it should be, since we do not necessarily want to have a mapping attached to every kind of abstraction). However, the diagram in figure 51 has a multiplicty of 1 for the "mapping" role (at the Expression end). This should be changed to 0..1.

  • Reported: XMI 2.0 — Wed, 21 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Templates / subsetting templateParameter

  • Key: UML14-478
  • Legacy Issue Number: 6911
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    ParameterableElement::owningParameter should subset ParameterableElement::templateParameter

  • Reported: XMI 2.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / General / Idenitfy sections specifying run-time semantics

  • Key: UML14-477
  • Legacy Issue Number: 6902
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The sections of the spec that describe the run-time semantics of UML are scattered throughout the document and not clearly identified. There should be at least some convenient guide in the document that would help locate those sections.

  • Reported: XMI 2.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Classes /

  • Key: UML14-476
  • Legacy Issue Number: 6901
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    on page 115 (section 7.15.3) when talking about the Notation of an
    interface, the third paragraph (between figure 59 and 60) says:
    "
    The usage dependency from a classifer to an interface is shown by
    representing the interface by a half-circle or socket, labeled
    with the name of the interface, attached by a solid line to the
    classifier that *implements* this interface (see Figure 60).
    "

    And I think it should say:
    "
    The usage dependency from a classifer to an interface is shown by
    representing the interface by a half-circle or socket, labeled
    with the name of the interface, attached by a solid line to the
    classifier that *requires* this interface (see Figure 60).
    "

  • Reported: XMI 2.0 — Wed, 14 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

importedMember property

  • Key: UML14-473
  • Legacy Issue Number: 6897
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    The importedMember property is derived from the ElementImports and the PackageImports.

    self.importedMember->includesAll(self.importedMembers(self.elementImport.importedElement.asSet()>union(self.packageImport.importedPackage>collect(p | >p.visibleMembers()))))

    The query importedMembers(...) should be importMembers(...). A fixed version is:

    self.importedMember->includesAll(self.importMembers(self.elementImport.importedElement.asSet()>union(self.packageImport.importedPackage>collect(p | >p.visibleMembers()))))

  • Reported: XMI 2.0 — Sat, 10 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Interactions / Two typos

  • Key: UML14-475
  • Legacy Issue Number: 6900
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    On page 408 there is text that says:

    Gates are just points on the frame, the ends of the messages. They may have an explicit name. See Figure 335.

    I think it should say:

    Gates are just points on the frame, the ends of the messages. They may have an explicit name. See Figure 336.

    On page 414 there is text that says

    See example of the usage of collaboration occurrences in Figure 345.

    I think it should say:

    See example of the usage of collaboration occurrences in Figure 339.

  • Reported: XMI 2.0 — Wed, 14 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

missing closing bracket

  • Key: UML14-474
  • Legacy Issue Number: 6898
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    There is a missing closing bracket in slot->forAll(s | classifier->exists(c | c.allFeatures()->includes(s.definingFeature) )

    The correct version is: slot->forAll(s | classifier->exists(c | c.allFeatures()->includes(s.definingFeature)) )

  • Reported: XMI 2.0 — Sat, 10 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

"• value : InstanceSpecification

  • Key: UML14-472
  • Legacy Issue Number: 6896
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    "• value : InstanceSpecification [*] ~~~~~~~~~~~~~~~~~~~~~ <<<< should be ValueSpecification The value or values corresponding to the defining feature for the owning instance specification. This is an ordered association. Subsets Element::ownedElement

  • Reported: XMI 2.0 — Sat, 10 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML2 Super / Classes / Operation constraints

  • Key: UML14-543
  • Legacy Issue Number: 7366
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Currently, the UML 2 specification defines Operation properties precondition, postcondition, and bodyCondition that are owned constraints. However, these properties do not subset the Namespace::ownedRule property, but rather the Namespace::ownedMember property.

    The opposites of these properties are preConstraint, postConstraint, and bodyConstraint, all of which are non-navigable and subset Constraint::context and Constraint::namespace.

    Also, the Constraint::namespace property, which is non-navigable, subsets Constraint::context, which is navigable. This is inconsistent, and in fact violates the UML's own constraint on property subsetting which stipulates that a navigable property can only be subsetted by a navigable property (constraint [4] of metaclass Property).

    The consequence of all this is that a Constraint that is the precondition (for example) of an Operation does not have a context . This means that a constraint such as an OCL expressions in pre-conditions cannot be parsed against the context namespace.

    There are (at least) two ways to solve this problem:
    let Operation::precondition and its cohorts subset Namespace::ownedRule instead of Namespace::ownedMember (which would leverage the eContainer() "cheat" that EMF offers to get the owner of an element that doesn't have a navigable owner property)
    let Constraint::namespace redefine NamedElement::namespace and make it navigable, thus making the subset relationship with Constraint::context valid

    The first option seems preferred, for two reasons:
    It makes sense that all constraints that a namespace owns should be included in the ownedRule property
    This would be consistent with the Behavior metaclass, whose precondition and postcondition properties do subset ownedRule

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML2 Super / ordering of association ends

  • Key: UML14-542
  • Legacy Issue Number: 7365
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It seems to me the the following properties should perhaps be ordered (currently they are not):

    ApplyFunctionAction::argument
    Association::endType
    CombinedFragment::operand
    ConnectableElement::end
    InteractionOccurrence::argument
    Message::argument
    StringExpression::subExpression
    StructuredClassifier::ownedAttribute
    TemplateSignature::parameter

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Q re Parameter

  • Key: UML14-541
  • Legacy Issue Number: 7355
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    There appears to be an inconsistency in the specification as to what it
    means to be a formal parameter or a return result. Please choose between the
    following two interpretations:

    A. A return result is a parameter that is specially indicated to be the
    return result. All other parameters are formal parameters.

    B. A return result is any parameter with direction return, out, or inout. A
    formal parameter is any parameter with direction in or inout.

    You could view (A) as focusing on the syntactical role the parameters play,
    while (B) focuses on when they communicate data.

    The difficulty arises from that the infrastructure and the superstructure
    have differing machineries of dealing with parameters.

  • Reported: XMI 2.0 — Sun, 16 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a duplicate of issue 7344

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

UML2 super/interactions

  • Key: UML14-537
  • Legacy Issue Number: 7301
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    03-08-02.pdf: page 412: consider/ignore - I can find no explanation of how
    the message types to be considered/ignored are modeled. The spec should be
    clear on this issue, probably in the description of combined fragment.

  • Reported: XMI 2.0 — Wed, 5 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Templates / invalid multiplicity

  • Key: UML14-536
  • Legacy Issue Number: 7277
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Figure 428 says that TemplateParameterSubstitution::ownedActual has a multiplicity of (0..1). However, the association description on page 549 states that the multiplicity is (1..). However, it seems to me that the multiplicity was intended to be 0.. despite what the diagram (and Rose model) seem to suggest.
    This is because a template substitution may not necessarily own any of its actual parameter values.

  • Reported: XMI 2.0 — Thu, 29 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Profiles / problem with name collisions

  • Key: UML14-535
  • Legacy Issue Number: 7276
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The new rule for extension end role names as adopted in ballot 10 (specifically for metaclass extension role names) is likely to lead to name collisions. For example, a stereotype that extends the Package metaclass with a property named 'basePackage' would conflict with the recommended role name of the metaclass extension end ('basePackage'). The recommended role names should be less likely to collide with names that might be chosen for stereotype properties, for example, base$"ExtendedMetaClassName" (i.e. base$Package).

  • Reported: XMI 2.0 — Thu, 29 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Question about Enumeration and EnumerationLiteral

  • Key: UML14-547
  • Legacy Issue Number: 7379
  • Status: closed  
  • Source: Red Hat ( Randall Hauch)
  • Summary:

    Enumeration is a subtype of DataType, and DataType allows both Properties and Operations. And since Enumeration has no additional constraints, this means that Enumeration also allows owned Property and Operation instances. Is there a reason why this is so? I would have expected an OCL constraint that limited the owned members of Enumeration to be only EnumerationLiteral instances.

    EnumerationLiteral is a subtype of InstanceSpecification, which itself is a subtype of PackageableElement. Because Package and own any number of PackageableElements, Package can actually own EnumerationLiteral. Is there a reason why this is so? The sematics talk about EnumerationLiteral being in the scope of an Enumeration, but it is somewhat vague about whether that is a constraint (there are no additional constraints). I would have expected an OCL constraint stating that EnumerationLiteral is only valid in the context of an Enumeration.

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 2 Super / missing owners of concepts

  • Key: UML14-540
  • Legacy Issue Number: 7336
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The owners of the metaclasses InformationFlow, ParameterSet, and PrimitiveFunction are not defined

  • Reported: XMI 2.0 — Fri, 14 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / state machines / state should be a namespace

  • Key: UML14-539
  • Legacy Issue Number: 7323
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Currently, a State is not a namespace, even though it contians things such as entry and exit pseudostates, substates, etc. all of which are in the context of a State. Therefore, State should be made a kind of Namespace as well as being a kind of Vertex. (Note that Vertices in general do not need to be Namespaces.

  • Reported: XMI 2.0 — Sat, 8 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue is resolved by the resolution to issue 6207.

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

UML 2 Super/Connector

  • Key: UML14-538
  • Legacy Issue Number: 7321
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    03-08-02.pdf, page 163:
    Specifies a link that enables communication between two or more instances.
    This link may be an instance of an association, or it may represent the
    possibility of the instances being able to communicate because their
    identities are known by virtue of being passed in as parameters, held in
    variables, created during the execution of a behavior, or because the
    communicating instances are the same instance.

    Doesn't this imply a semantic variation point?

  • Reported: XMI 2.0 — Fri, 7 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML2 Super / Common Behavior / Trigger should be a named element

  • Key: UML14-546
  • Legacy Issue Number: 7369
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In figure 317, Trigger is defined as a specialization of Element. However, it seems reasonable for triggers to have names, so it really should be a subclass of NamedElement

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML2 Super / Use cases / navigation from subject to use case

  • Key: UML14-545
  • Legacy Issue Number: 7368
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The current model of use cases does not allow navigation from a subject classifier of a use case to its use case. It should be possible to do this, so that a classifier can easily identify which use cases apply to it. The proposed resolution is to make Classifier::useCase navigable.

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / General / superclass pointers

  • Key: UML14-544
  • Legacy Issue Number: 7367
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It would greatly improve readability if every metaclass had a section that listed all the immediate superclasses of that class. This would also make the document consistent with the resolution to issue 7156, which indicates that such a subsection should exist.

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

transition is simply never enabled

  • Key: UML14-534
  • Legacy Issue Number: 7256
  • Status: closed  
  • Source: ISTI-CNR ( Franco Mazzanti)
  • Summary:

    Maybe this is a stupid question. But I could not find an answer ... A transition is not required to have a trigger. If the source of the transition is a composite state, its triggering is described by the rules about "completion transitions". But what happens if the source is just a simple state: It would seem that the transition cannot be considered as a "completion transition", but at the same time, the transition never satisfies the rules about "enabled transitions". Hence it woulds seem that the transition is simply never enabled. Is this interpretation correct? If so, it this behaviour really intended?

  • Reported: XMI 2.0 — Wed, 21 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML Sequence diagram

  • Key: UML14-533
  • Legacy Issue Number: 7253
  • Status: closed  
  • Source: Independence Blue Cross ( Janardhanam Venkat)
  • Summary:

    In the UML Sequence diagram there are asynchronous message that is very useful in designing application. I am trying to create an activity diagram between 4 asynchronous system. Why cant we have asynchronous arrow in activity diagram between swim lanes? That is the true representation of a flow in a distributed system.

  • Reported: XMI 2.0 — Fri, 16 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UseCase - Constraint for non-circular include relation

  • Key: UML14-493
  • Legacy Issue Number: 6965
  • Status: closed  
  • Source: Anonymous
  • Summary:

    UseCase - Constraint for non-circular include relation

    I suggest to add the following fragments to the sections "Additional Operations" and "Constraints":

    Additional Operations [1] The query allIncludedCases() gives a set of all of the uses cases which are either included directly by this use case or indirectly by other included use cases.

    UseCase::allIncludedCases(): Set(UseCase); allIncludedCases = self.include->union( self.include->collect(uc | uc.allIncludedCases()) )

    Constraints [4] A Use Case may not directly or indirectly include itself not self.allIncludedCases()->includes(self)

  • Reported: XMI 2.0 — Sat, 31 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

What level of MOF 2.0 is the metamodel for UML 2.0?

  • Key: UML14-492
  • Legacy Issue Number: 6959
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    UML 2.0 does not state which level of MOF (EMOF, CMOF, or
    whatever else) provides its meta-meta-model. Therefore, there is
    no formal statement defining which Class definition (Basic or
    Constructs package level) and so forth is the basis for the
    definitions in the UML 2.0 specification. UML tools implement
    this class, so it's probably a good idea to know which one it's
    supposed to be. (Proof, in case you're wondering: The names
    EMOF and CMOF do not occur anywhere in the Superstructure
    final adopted specification 03-08-02. The name MOF does, but
    not in the context of which version of MOF defines the
    UML metametamodel.)

    If there is an ambiguity in which it is, the FTF needs to resolve
    it. Once it's resolved ("The metamodel for UML 2.0 is CMOF"), it
    should be stated clearly in the specification.

  • Reported: XMI 2.0 — Wed, 4 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Realize keyword-stereotype

  • Key: UML14-484
  • Legacy Issue Number: 6930
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Table 28 in the appendix identifying standard stereotypes identifies that the "realizes" stereotype of Abstraction has been retired. However, on page 110 it is stated that the notation for a Realization dependency is a dependency with the "realize" keyword attached to this. Although this could be explained by saying that the keyword has not been retired whereas the stereotype has, this is very confusing and appears contradictory. I suggest we eliminate the table entry in Table to 28 that specifies that the "realize" stereotype has been retired.

    The bigger problem, perhaps is that the difference between keywords and stereotypes is not properly explained anywhere (at least not where I could find it). Perhaps the Notation appendix should discuss this.

  • Reported: XMI 2.0 — Mon, 26 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 2 Super / Classes / Properties owned by properties

  • Key: UML14-483
  • Legacy Issue Number: 6929
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It seems that the lower bound of Feature::featuringClassifier should perhaps be 0 (not 1) to allow for the situation in which a Property is owned not by a class, association, or data type, but another property (as one of its qualifiers)

  • Reported: XMI 2.0 — Mon, 26 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 367

  • Key: UML14-489
  • Legacy Issue Number: 6949
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    Top of page 367, text says:
    Activity diagrams have graphical elements for containment. These
    are included in Table 13.

    In the next line, the table caption says:
    Table 13 - Graphic nodes included in activity diagrams

    Proposed resolution:
    These are inconsistent, although not necessarily wrong. They should be
    made consistent.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 366

  • Key: UML14-488
  • Legacy Issue Number: 6948
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    Middle of page 366, text says:
    The graphic paths that can be included in structural diagrams are
    shown in Table 12.

    In the next line, the table caption says:
    Table 12 - Graphic nodes included in activity diagrams

    Proposed resolution:
    The table caption is correct, and the text above it needs to be changed
    to conform.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Inconsistent labeling of tables in Section 12.4, Activities.Diagrams p365

  • Key: UML14-487
  • Legacy Issue Number: 6947
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    Inconsistent labeling of tables in Section 12.4, Activities.Diagrams:

    Issue 1:
    Top of page 365, text says:
    The graphic nodes that can be included in structural diagrams are
    shown in Table 11.

    In the next line, the table caption says:
    Table 11 - Graphic nodes included in activity diagrams

    Proposed resolution:
    The table caption is correct, and the text above it needs to be changed
    to conform.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Deployments / Invalid cross-references

  • Key: UML14-486
  • Legacy Issue Number: 6946
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Table 9 on page 199 references pages such as 10-50, 26-201. These are not valid page number in the spec.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / use cases / incorrect table title

  • Key: UML14-495
  • Legacy Issue Number: 6969
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Table 22 on pages 523-524 is titled "Graphic nodes used in sequence diagrams" but should be titled "Graphic nodes used in use case diagrams"

  • Reported: XMI 2.0 — Mon, 2 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UseCase - Include - Constraint for irreflexivity

  • Key: UML14-494
  • Legacy Issue Number: 6967
  • Status: closed  
  • Source: Anonymous
  • Summary:

    UseCase - Include - Constraint for irreflexivity

    I suggest to add the following constraint for Include:

    Constraints [1] An include relation is irreflexive, i.e. source and target are not equal. self.addition <> self.includingCase

  • Reported: XMI 2.0 — Sat, 31 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue is resolved by the resolution to issue 6965.

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

UML 2 Super / Classes / Dependency should not be abstract

  • Key: UML14-485
  • Legacy Issue Number: 6945
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    A quick survey of the superstructure spec reveals the following places where Dependency is defined (and I probably missed some):

    Fig 51, P.106, shown as NOT abstract - this is where the Dependency package is shown
    Table 4, P.130, defines a visual symbol for it
    Fig. 101, P.155, shown as abstract
    Fig. 126, P.183, shown as abstract
    Fig 130, P.188, shows a pure dependency in an example
    Table 9, P.199, defines a visual symbol for it

    Most of the text also refers to the section containing figure 51 for the definition of dependency. If I were reading the spec, I would tend to consider the section where it is defined as the authority and dismiss the others as errors made by those writing the other chapters.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML2 superstructur: actor

  • Key: UML14-496
  • Legacy Issue Number: 6970
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    UML2 superstructure 03-08-02
    p. 513
    "[1] An actor can only have associations to use cases, subsystems, components and classes, and these associations must be binary."

    A subsystem is a component stereotype, so it doesn't make sense to mention it here.

    I would propose the following constraint instead of the above one:
    "[1] An actor can only have associations to classifiers, and these associations must be binary."

    It makes sense that an actor can have binary associations to the subject they are interacting with.
    The subject of an use case is a classifier.

  • Reported: XMI 2.0 — Mon, 2 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / General / specialization labeling convention

  • Key: UML14-491
  • Legacy Issue Number: 6958
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In most cases, when a metaclass is refined in a package, the phrase used in the title of the class description is "as specialized". In a few places, however, it is flagged as just "specialized". This needs to be made consistent.

  • Reported: XMI 2.0 — Wed, 4 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Typo in Collaboration Diagram figure

  • Key: UML14-490
  • Legacy Issue Number: 6950
  • Status: closed  
  • Source: Object Management Group ( Nancy Siegel)
  • Summary:

    In UML Superstructure, ad/03-08-02, Section 14.4 "Diagrams", page 443,
    figure 346, bottom right box labeled "sd Q", the label "ysuperB" needs
    a colon, and should be "y:superB" (as it is in the top right box).

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

adopt a single notation to specify text strings used in the notation

  • Key: UML14-518
  • Legacy Issue Number: 7135
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    There are three different ways to specify text strings used in the notation and two variations.

    The three ways:

    1. a sort of Bakus-Naur form as in: multiplicity ::= <multiplicity_range> [ ‘

    {‘ <order_designator> ‘}

    ’ ] see Super 7.4.1

    2. a second way as in: [visibility] [/] name [: type] [multiplicity] [= default] [

    { property-string }] see Super 7.8.1 The characters that are a part of the notation (virgule, colon, equals and braces) are simply shown.

    3. a third way, combining features of both as in: visibility name ‘<‘ template-parameter-list ‘>’ ‘<<‘binding-expression-list ‘>>’‘( ‘ parameter-list ‘)’ ‘:’ property-string see Super 17.5.12 The characters that are a part of the notation (angle bracket, parens, colon) are enclosed in single quotes. (The inverted comma and apostrophe are not consistently used as opening and closing single quotes.)

    Both the second and the third ways are sometimes used at the same place as in: [visibility] [/] name [: type] [multiplicity] [= default] [{ property-string }

    ] {{ [ name ] ‘:’ classname } | name } [ ‘[‘ multiplicity ‘]’ ] see Super 17.5.7

    The two variations:

    a. Sometimes a single bracket does double duty as in: direction name : type-expression [multiplicity] = default-value [

    { property-string }

    ] see Super 7.10.1 Here, the brackets around multiplicity indicate both that multiplicity is optional, and that the multiplicity is to be shown inside brackets. see Super 7.10.1

    b. Sometimes the brackets are not used when an item is optional as in: visibility name ( parameter-list ) : property-string see Super 7.10.1

  • Reported: XMI 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Appendix A of the superstructure spec

  • Key: UML14-517
  • Legacy Issue Number: 7125
  • Status: closed  
  • Source: International Business Machines ( Eran Gery [X] (Inactive))
  • Summary:

    Appendix A of the superstructure spec specify the usage of frames
    in diagrams. The text says:
    "Each diagram has a frame, a contents area, and a heading, see Figure 460."

    This statement implies that frames are normative. The text later says
    that "In cases where not needed, the frame may be omitted and implied by the border of the diagram area provided by a tool."

    This entire explanation distorts the common intent and practice of UML
    diagramming. Text should present the frames as an optional presentation
    option in the first place. Also, in all cases mentioned (ports, entry points)
    it is possible to notate the context using class boxes or states, so in none of these cases frames are "needed". It is a mere presentation option that might be

    used as an alternative to using prime container symbols.

  • Reported: XMI 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Activities / Fig.192 constraint duplicated

  • Key: UML14-516
  • Legacy Issue Number: 7099
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In Fig. 192 on pg. 277, the association end StructuredActivityNode::activity, the constraint

    {redefines activity}

    is duplicated

  • Reported: XMI 2.0 — Fri, 5 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Ambiguous semantics of isStatic - resubmission of issue 4446

  • Key: UML14-515
  • Legacy Issue Number: 7098
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of isStatic = true is ambiguous for structural features
    declared on classifiers that have children. It is not defined whether
    this gives a single value for the classifier and all its descendents,
    or values for the classifier and each descendant separately.

  • Reported: XMI 2.0 — Mon, 9 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is the same issue as issue 6974

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

UML 2 Super / Interactions / Invalid subsetting for enclosingOperand

  • Key: UML14-514
  • Legacy Issue Number: 7069
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There is a serious model consistency issue with InteractionFragment::enclosingOperand because it is currently constrained to be a subset of NamedElement::namespace, but its type (InteractionOperand) is not a specialization of Namespace. Also, InteractionOperand::enclosingInteraction does not subset NamedElement::namespace (it probably should; Interaction is already an indirect specialization of Namespace).

    The simplest solution is to make InteractionOperand a specialization of Namespace

  • Reported: XMI 2.0 — Thu, 4 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Classes / makesVisible () operation incorrect

  • Key: UML14-513
  • Legacy Issue Number: 7068
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    there appears to be a bug in the specification with respect to the definition of the makesVisible() OCL query on packages. Here is the OCL expression from the specification (page 100):

    Package::makesVisible(el: Namespaces::NamedElement) : Boolean;
    pre: self.member->includes(el)
    makesVisible = el.visibility->isEmpty() or el.visibility = #public

    As you can see, this definition makes even imported elements visible based on their own visbility rather than the visibility of the import
    relationship. The same applies to elements made visible indirectly via a package import.

  • Reported: XMI 2.0 — Thu, 26 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Super and Infra / Kernel-Classifiers / incorrect hasVisibilityOf definition

  • Key: UML14-512
  • Legacy Issue Number: 7056
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It seems that there is an issue with the hasVisibilityOf(NamedElement) operation on Classifier. In particular, it doesn't consider visibilities when determining if a member is visible:

    Classifier::hasVisibilityOf(n: NamedElement) : Boolean;
    pre: self.allParents()>collect(c | c.member)>includes
    hasVisibilityOf =true

    One might logically expect the operation to exclude, for example, members with private visibility.

  • Reported: XMI 2.0 — Sun, 29 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Operations and derived attributes

  • Key: UML14-526
  • Legacy Issue Number: 7219
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    I am looking at ValueSpecification which introduces Additional Operations, such as integerValue(). My question is : What is the reasoning behind making these Operations vs. Derived attributes?

    In MultiplicityElement we have a derived attribute lower which is equal to lowerBound(). What logic is used to determine whether an Operation has a corresponding Attribute?

    Also the spec seems to indicate that all derived values will be implemented via some operation. Is this a requirement or an assumption of implementation?

    Why can’t lower in MultiplicityElement simple be defined as if lowerValue->notEmpty() then 1 else lowerValue.integerValue()Â… what makes the lowerBound() operation required?

  • Reported: XMI 2.0 — Mon, 12 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

use of stereotypes

  • Key: UML14-525
  • Legacy Issue Number: 7213
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Today, the reason for this mail is that in my UML certification I was asked a question regarding the include and extend relationship between use cases.
    I was (and am still a bit) confused, because one question was dealing with the extend and include notation between use cases. I think the 640 pages UML 2 documnet 03-08-02.pdf is inconsistent here. (I now ask because I think I lost two correct answers in my fundamental UML 2 certification caused by include/includes and extend/extends...): UML 1 used the stereotype notations "extends" and "includes". Im UML 2, the classifiers are now called "include" and "extend". But confusingly enough, some association arrows inside the OMG document 03-08-02.pdf
    "UML Superstructure 2.0 Draft Adopted Specification" use the stereotypes (see <<extends>> and <<includes>> in Fig 406 p. 521 and twice <<extends>> and one time <<includes>> in Table 22 on page 523/524.)

    Who to report these inconsistencies to? Or are the stererotypes still allowed to be labeled <<extends>> and one time <<includes>> ?

  • Reported: XMI 2.0 — Fri, 26 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of issue 6465.

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

UML 2 Super / Appendix A / Typos

  • Key: UML14-524
  • Legacy Issue Number: 7162
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    p587 para 2 line 2 "UML diagrams contains graphical elements" (should be "contain")
    p587 para 5 line 1 "symbols defines the type" (should be "define")
    p587 last para "C1 and C1" (should be "C1 and C2")
    p588 para 1 line 2 "a graphical symbols" (should remove "a")
    p588 para 1 line 4 "assocition"

  • Reported: XMI 2.0 — Tue, 16 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/Interactions/Alternative with all false guards

  • Key: UML14-523
  • Legacy Issue Number: 7160
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Semantics of the alternative CombinedFragment (page 410) does not describe what happens if all branches are guarded, and
    all guards are false.
    Does this means: a) empty trace, or b) (dynamically) invalid trace ?
    I suggest to add a sentence, defining such traces as dynamically invalid.
    This will be consistent with the behavior of a ConditionalNode in Activities (page 313): "if no test section yields a true value, then no body section is executed; this may be a semantic error if output values are expected from the conditional node".

  • Reported: XMI 2.0 — Mon, 15 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / General / Classes chapter organization

  • Key: UML14-522
  • Legacy Issue Number: 7159
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The Classes chapter is organized differently from all other chapters in the document – it should be made consistent with the organization of all the other chapters

  • Reported: XMI 2.0 — Tue, 16 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / State machines / incorrect navigation specifications

  • Key: UML14-521
  • Legacy Issue Number: 7158
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In figure 354 on page 457, it is shown that it is not possible to navigate back from Region towards either the state machine that owns it or the state that owns it. However, it is often necessary to know who the owner of a region is, therefore these associations need to be made navigable in both directions.

  • Reported: XMI 2.0 — Mon, 15 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / General / consistent formatting conventions

  • Key: UML14-520
  • Legacy Issue Number: 7157
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Different chapters in different parts of the spec use different conventions for naming, headings, layout etc. These should all be made consistent based on one shared convention.

  • Reported: XMI 2.0 — Sun, 14 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is resolved by the resolutions to issue 6958 and 7190.

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

UML 2 Super / General / Dcoument conventions

  • Key: UML14-519
  • Legacy Issue Number: 7156
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The document needs an explanation of how it is laid out and how the format and meaning of the various sections in the individual class descriptions

  • Reported: XMI 2.0 — Sun, 14 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Activity Diagrams: Relax Traverse-to-Completion semantics

  • Key: UML14-528
  • Legacy Issue Number: 7221
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In my interpretation of the current semantics description of UML
    activity diagrams (Superstructure, Final Adopted Spec, ptc/03-08-02) I
    have identified some rather unpleasant properties of the current
    traverse-to-completion semantics. The full discussion together with
    examples can be found in the attached .pdf, the short of it is:

    *) the current semantics does not prevent deadlocks (as it is
    supposed to do)

    *) it rather induces deadlocks even in simple examples (e.g. examples
    in the UML spec are wrong)

    *) it makes for a very complex evaluation and introduces unnecessary
    synchronization in the (basically asynchronous) notation of Activiy
    Diagrams.

    I therefore propose to relax the semantics of token flow by dropping
    the constraint that every Action has to accept all tokens for all its
    input pins at once. MergeNodes should als be able to buffer tokens
    until their conditions are satisfied. This is a more natural way of
    interpreting ADs.

  • Reported: XMI 2.0 — Mon, 5 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML2 super/Deployments/CommunicationPath

  • Key: UML14-530
  • Legacy Issue Number: 7228
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In section 10.3.2 and Figure 125 the constraint is given that a
    CommunicationPath can only associate Nodes.
    This seems too restrictive and does not, for example, allow
    CommunicationPaths between actual servers (Instance Specifications).

    Proposed resolution:
    Relax constraint such that a CommunicationPath can link
    DeploymentTargets.

  • Reported: XMI 2.0 — Sun, 11 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

State machines / name of transitions association end

  • Key: UML14-529
  • Legacy Issue Number: 7226
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UML::StateMachines::BehaviorStateMachines::Region::transitions should be renamed to transition (i.e. made singular) to be consistent with the naming convention for other association ends.

  • Reported: XMI 2.0 — Sun, 11 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML2 Super/Composite Structure

  • Key: UML14-532
  • Legacy Issue Number: 7231
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    page 178, table 6 - the entry for port shows the only option for a port as
    being on the boundary of an enclosing box whereas the notation section for
    ports (169) states that port boxes may be shown inside the boundary of the
    enclosing box. The port entry on table 6 should amended so that it includes
    all cases.

    page 179, the table is headed table 6 but should be table 7.

  • Reported: XMI 2.0 — Mon, 12 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 1 activities

  • Key: UML14-531
  • Legacy Issue Number: 7230
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    figure 274 - should the arrow between Award Quote and Quote Responses be the
    other way round

  • Reported: XMI 2.0 — Fri, 9 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Composite Structures, 03-08-02.pdf

  • Key: UML14-527
  • Legacy Issue Number: 7220
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Can a connector be typed by an association one of whose ends are composite
    or shared? I can't see anything in the spec that prohibits this but I'm not
    sure that it makes a lot of sense to do so.

  • Reported: XMI 2.0 — Mon, 22 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Ambiguous example of a local action on a Lifeline in Figures 334, 335

  • Key: UML14-511
  • Legacy Issue Number: 6988
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 415-6 Figures 334,335 use a rectangular box with the text "DoSth" in it. The meaning of this symbols is not explained in the corresponding section, nor in Table 14 graphical nodes in Sequence Diagrams.
    In ITU Message Sequence Charts this would mean an informal action, local to the Lifeline.

    The syntax and semantics of local actions is the key issue in "executable sequence diagrams", and in proper alignment of semantics between Interactions, Activities and State Machines (and Actions).

    As a minimum, Figures 334, 335 need to be explained, and table 14 updated.
    It would be better to illustrate formal use of Actions.
    Ideally, Interactions will benefit from a data sublanguage based on Actions, in order to have a capability to fully specify flows of data between Lifelines:

    • message parameters (including composite values)
    • local attributes (storing data in Lifeliens; in data structures like lists, sets, tables, etc.)
    • identities of objects (input and output pins for actions)
    • actions (manipulations on data, access to data structures and composite values)
    • proper usage of data in guards and state invariants
    • proper usage of data in loop expressions
  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

ambiguous definition of the scope of a break CombinedFragment

  • Key: UML14-510
  • Legacy Issue Number: 6987
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    page 410 mentions that "Break CombinedFragments must be global relative o the enclosing InteractionFragment".

    This is ambiguous and needs to be explained in more precise way, involving InteractionOccurences and Interaction Overview Diagrams. There were debates on the scope of a similar construct in the ITU language.

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/Interactions/inconsistent spelling for InteractionOperator

  • Key: UML14-509
  • Legacy Issue Number: 6986
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    The enum type name InteractionOperator is often misspelt (e.g. interactionOperator or interaction operator). It is also used inconsistently when referring to a particular operator, e.g. InteractionOperator alt.
    I suggest using a single typigraphic convention:
    InteractionOperator <italic> alt </italic>

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Ambiguous sentence and typo in description of EventOccurence

  • Key: UML14-502
  • Legacy Issue Number: 6979
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 416:

    The sequences of Eventoccurences are the meanings of Interactions. >>Messages are sent through either asynchronous signal sending or operation calls.<<
    Likewise they are >>>recieved<<< by >>Receptions or actions of consuption.<<

    typo needs to be corrected.
    highlighted parts need to be re-phrased and terminology aligned with the rest of the spec.

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

graphic nodes for state invariant and continuation are not always distingui

  • Key: UML14-501
  • Legacy Issue Number: 6978
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    It is not possible to visually distinguish between a continuation (oval with a name) and a simple state invariant (also oval with a state name). Compare Figure 345 and 334.

    One possibility is to use guard syntax for state invariants.
    Another possibility is to use a different graphic for continuations

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Ambiguous semantics of isStatic

  • Key: UML14-498
  • Legacy Issue Number: 6974
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of isStatic = true is ambiguous for structural features
    declared on classifiers that have children. It is not defined whether
    this gives a single value for the classifier and all its descendents,
    or values for the classifier and each descendant separately.

  • Reported: XMI 2.0 — Mon, 9 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

self-activation notation in Sequence diagrams missing

  • Key: UML14-497
  • Legacy Issue Number: 6972
  • Status: closed  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    UMl 1.x sequence diagrams had a notation for self-activation, where the activation boxes (now called "execution occurrences" in UML 2) can be nested.

    E.g. UML 1.4, Notation, Sequence Diagrams, section 3.60.4, figure 3-56

    This notation is missing from UMl 2.0 Interactions chapter. No alternative notation is provided.

  • Reported: XMI 2.0 — Fri, 6 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    duplicate

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

UML 2 Super/Interactions/rationale subsections not informative

  • Key: UML14-505
  • Legacy Issue Number: 6982
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Most sections in chapter 14 on Interactions do not have a Rationale subsection, while the remaining few only contain the text "not applicable". This is not informative.
    I suggest to remove the Rationale subsections altogether.

    Pages 414 421 423 425 428 430 433

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Remove the empty “Rationale” sub-sections on pages 414, 421, 423, 425, 428, 430, 433.

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

UML 2 Super/Interactions/incorrect grammar for

  • Key: UML14-504
  • Legacy Issue Number: 6981
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Grammar for <state-info> at page 434 has a typo:
    <state-info>::=<region}

    {, <region> }*


    must be:
    <state-info>::=<region> {, <region> }

    *

    It is not clear, how to define <region-name> in Sequence Diagrams.

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

word "execute" in definition of alternative CombinedFragment is ambiguous

  • Key: UML14-507
  • Legacy Issue Number: 6984
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 410 The word "execute" is used to describe the Alternative CombinedFragment i nthe context "operand will execute", etc. This word is ambiguous. I suggest changing it to "operand is chosen", etc.
    Or even the full description, like "the meaning of the InteractionOperator alt is a trace corresponding to only one of its operands".

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/Interactions/Ambiguous description of state invariants

  • Key: UML14-506
  • Legacy Issue Number: 6983
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    page 433 has the following text: "A StateInvariant is a constraint on the state of a Lifeline. In this case we mean by "state" also the values of >>eventual attributes<< of the Lifeline".

    The term >>eventual attribute<< may be ambiguous.

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/Interactions/incorrect text and table title for Table 19

  • Key: UML14-500
  • Legacy Issue Number: 6977
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 450 has the following text:
    "The graphic nodes that can be included into >>structural diagrams<< are shown in Table 19". Table 19 has the following title "Graphic nodes and paths included in >>sequence diagrams<<"

    The text needs to be changed into "The graphic nodes >>and paths<< that can be included into >>timing diagrams<< are shown in Table 19"

    Title of Table 19 should read "timing diagrams" instead of "sequence diagrams".

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/Interactions/incorrect text before Table 14

  • Key: UML14-499
  • Legacy Issue Number: 6976
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 436 has the following text:
    "The graphic nodel that can be included in >>structural diagrams<< are shown in Table 14."

    Table 14 is called "Graphic nodes included in sequence diagrams".

    Text needs to be changed into "sequence diagrams"

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a duplicate of 6934, already resolved

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

UML 2 Super/Interactions/incorrect spelling of EventOccurence

  • Key: UML14-503
  • Legacy Issue Number: 6980
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    There are multiple places in the Interaction section, where class name EventOccurence is spelt incorrectly (usually as Eventoccurence).

    pages 403 410 411 416 417 419 420 422 427 429 431

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

text differs from metamodel for critical region InteractionOperator

  • Key: UML14-508
  • Legacy Issue Number: 6985
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    On page 411 subsection for Critical Region mentions the InteractionOperator "critical", while the metamodel uses the enum "region".

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Predefined datatypes

  • Key: UML14-61
  • Legacy Issue Number: 4452
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The various datatypes that are the result of expressions are not
    defined in UML. For example, there is no subtype of Datatype
    called Boolean. This means users will all define their own Boolean,
    Integer, etc., breaking interchangeability.

    The datatypes defined in the Datatypes packages are not model
    elements, so theoretically cannot be used in M1 models. However,
    the interchange model for UML includes these types, making them
    available for user models. If this is the case, it should be made
    clear in the UML spec. The overview of the Datatypes package
    (section 2.7.1) says it contains types used in defining UML, so
    they formally belong to the MOF.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

The definition of Multiplicity in Datatypes does not list the range associa

  • Key: UML14-60
  • Legacy Issue Number: 4449
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The definition of Multiplicity in Datatypes does not list the range association

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Component notation: logical compartments

  • Key: UML14-65
  • Legacy Issue Number: 4464
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    The current component notation does not provide for separate
    logical compartments when nesting implementation classes and artifacts in a
    component, as shown in Notation, Figure 3-95. It would be useful to provide
    separate logical compartments for this, as we do for subsystems and classes.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Exceptions do not correspond to common usage

  • Key: UML14-64
  • Legacy Issue Number: 4457
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Exceptions in UML are signals, but the normal usage of the term is
    for non-local flow of control that is trapped in procdural code.
    No signal is normally sent with exceptions.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Ambiguous semantics of classifier targetscope

  • Key: UML14-59
  • Legacy Issue Number: 4447
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of classifier targetscope is ambiguous for
    associations with participating classifiers that have children. It
    is not defined whether this specifies links for the classifier and
    all its descendants, or links for the classifier and each
    descendant separately.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Event => Event Specification

  • Key: UML14-63
  • Legacy Issue Number: 4456
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The event metaclass would better called "event specification". Or
    at least the runtime event should be called "occurences" rather
    than instances.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue is resolved by the resolution to issue 6682.

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

The text and OCL of rule #5 for Method do not say the same thing.

  • Key: UML14-62
  • Legacy Issue Number: 4455
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The text and OCL of rule #5 for Method do not say the same thing.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Another State machine issue

  • Key: UML14-37
  • Legacy Issue Number: 3202
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    State Machines

    The metaclass StateVertext, including its subclasses PseudoState,
    StubState and SyncState is not owned by a StateMachine.

    The associations from StateVertext to

    • container : CompositeState
    • outgoing : Transition
    • incoming : Tranision
      can all be empty.
      If they are all empty in a model, we do not know to which statemachine
      this StateVertex belongs. IS this the intention ?
  • Reported: XMI 1.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Data Types Misplaced in the "Physical" Metamodel (uml-rtf)

  • Key: UML14-36
  • Legacy Issue Number: 3127
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    All data types used in the UML metamodels are clumped together in a
    Data_Types package in the Foundation metamodel. When a new type is needed
    by some other metamodel, such as for Activity Graphs, the type is added into
    Foundation. This breaks the whole concept of extensibility. Data types,
    like other model elements, should be defined in the specific packages where
    they are needed. A new package that requires new types should include those
    types itself and not impose a change on UML Foundation.

    Recommendation: In the "physical" metamodel, put data types into the
    packages where they are first used. For example, PseudostateKind should be
    defined in Behavioral_Elements.State_Machines, not in Foundation.Data_Types.

  • Reported: XMI 1.1 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Inheritance violation in "Auxiliary Elements"

  • Key: UML14-30
  • Legacy Issue Number: 2361
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Source: HO Wai-Ming, PhD research Student, IRISA, France

    Reference: UML Semantics 1.1, Sep. 1997 and UML Semantics 1.3 Beta, Jan
    1999 and the associated Rational Rose model files

    Specification section reference: UML Semantics 1.1 Part 2, Section 4.3
    Well-formedness rules, pp.32 and UML Semantics 1.3, Part 2, Section
    2.5.3, pp.2-49

    Nature: Clarification

    Severity: Medium
    Summary: In the 1.1 model file, there is an inheritance relationship
    between
    "Presentation" (in "Auxiliary Element") and "Element" (in "Core").
    "Presentation" is an association class and "Element" is a normal class.
    The two types are not the same, this this brings up the following
    constraint in the semantic document:

    self.subtype.oclType = self.supertype.oclType

    Question:
    1) Is "Presentation" suppose to inherit from "Element"? The other
    association classes "ElementOwnership" and "ElementReference" do no
    appear to do so.

    2) If the answer to (1) is yes, then isn"t it a violation of the UML
    semantics" well-formedness rule.

  • Reported: XMI 1.0 — Mon, 1 Feb 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

class EnumerationLiteral issue

  • Key: UML14-33
  • Legacy Issue Number: 2582
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I think that the class EnumerationLiteral should be an heir of DataValue
    (this inheritance relationship is currently missing).

    Once this is fixed, the association between EnumerationLiteral and Enumeration
    should be seen as a refinement of the association between DataValue and DataType
    (itself implicitly inherited from the association between Instance and classifier),
    with a supplementary OCL constraint in the case of EnumerationLiteral,
    namely that self.classifier.oclIsKindOf(Enumeration)
    (to ensure covariance, as is done for DataValue wrt DataType).

    BTW, shouldn"t there be a symetric OCL constraint in DataType
    specifying that its Instances are all DataValues,
    and similarly in Enumeration specifying that its instances are all EnumerationLiterals ?

  • Reported: XMI 1.0 — Mon, 12 Apr 1999 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Operations and Constraints Missing from "Physical" Metamodels

  • Key: UML14-35
  • Legacy Issue Number: 3126
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The "physical" metamodel should include the OCL constraints and operations
    defined in the UML Specification. This has been done in the MOF 1.3
    specification. The operations provide valuable capabilities and should be
    part of the standard UML facility interfaces. Making the operations part of
    the "physical" metamodel allows them to be used when defining new
    constraints in extension metamodels, such as in CWM.

    Recommendation: Add the specification's constraints and operations to the
    "physical" metamodel.

    Note that adding constraints and operations will affect IDL, but it will not
    affect XMI DTDs.

  • Reported: XMI 1.1 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Incomplete Inheritance Specification

  • Key: UML14-31
  • Legacy Issue Number: 2362
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Source: HO Wai-Ming, PhD research Student, IRISA, France

    Reference: Rational Rose model files for UML 1.1 and UML 1.3 beta

    Specification section reference: None

    Nature: Clarification

    Severity: Minor

    Summary: There is an oddity in the inheritance relationship of
    "Classifier" in "Core". Is "Classifier" suppose to inherit from
    "Taxon-Datatype", but the specification is incomplete. Rational Rose
    and Rose98 raises an error for this association during a "Check Model".

  • Reported: XMI 1.0 — Mon, 1 Feb 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Datatypes: Expression

  • Key: UML14-32
  • Legacy Issue Number: 2541
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the metaclass Expression includes an attribute called "language" of type
    Name. To enable tools to check OCL expressions, it is neccesary to
    define a standard value for this attribute, which denotes the fact that the
    expressions is an OCL expression.
    Without such a standard defined value tools cannot distinguish OCL
    expresions and cannot interpret them (for purposes of typechecking,
    code generation, etc....)

    I propose to add the value "OCL" as a standard value for the attribute
    "language" of metaclass "Expression" to the chapter on datatypes.

  • Reported: XMI 1.0 — Mon, 15 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Interfaces on Nodes

  • Key: UML14-34
  • Legacy Issue Number: 2613
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In looking through the UML 1.3 alpha R2 documentation set, I cannot
    determine if interfaces are allowed on Nodes. Since a Node is a kind
    of classifier, it seems possible that a Node can realize an interface.
    However, since this relationship is not explicitly mentioned as allowed
    or not, I am unclear as to the intention.

  • Reported: XMI 1.0 — Mon, 19 Apr 1999 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: Dynamic concurrency arguments

  • Key: UML14-38
  • Legacy Issue Number: 3276
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Actions in dynamically concurreny states in activity graphs need
    some way to access the arguments provided by the concurrency
    expression. The Reference manual suggests the "implicit" event,
    but does not define what that is (p 437). Perhaps it is an the
    action language issue.

  • Reported: XMI 1.1 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: Parallel action iteration

  • Key: UML14-39
  • Legacy Issue Number: 3285
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Actions should have a isParallel attribute to specify if the iteration
    is sequential or parallel.

  • Reported: XMI 1.1 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: ClassifierRole contents problem

  • Key: UML14-82
  • Legacy Issue Number: 4736
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The UML 1.4 standard states [UML 1.4, pp. 2-121] that a ClassifierRole
    "...specifies a restricted view of a [base] classifier.." and defines "...a
    set of Features, which is a subset of those available in the base
    classifier, as well as a subset of ModelElements contained in the base
    classifier...".

    The ClassifierRole wellformedness rules [UML 1.4, pp. 2-125] states that the
    "feature" association inherited from Classifier must be empty - instead the
    ClassifierRole must select features from the base classifier using the
    "availableFeature" association [UML 1.4, pp. 2-121].

    The ClassifierRole also has an "availableContents" association [UML 1.4, pp.
    2-121] indicating "the subset of ModelElements contained in the base
    Classifier, which is used in the Collaboration". There is however no
    restriction in the wellformedness rules restricting the ownedElements
    contents of the ClassifierRole itself, meaning that a ClassifierRole can
    contain the following meta-elements:

    Method
    Attribute
    Operation
    Reception
    State
    ActionState
    ObjectFlowState
    Transition
    CallState
    Pseudostate
    SimpleState
    SubactivityState
    SynchState
    CompositeState
    SubmachineState
    SubState
    FinalState
    CallAction
    TerminateAction
    CreateAction
    DestroyAction
    SendAction
    ActionSequence
    UninterpretedAction
    ReturnAction
    ExtensionPoint
    Stimulus
    Parameter
    Permission
    UseCase
    ProgrammingLanguageDataType
    StateMachine
    Comment
    LinkObject
    Enumeration
    Association
    Dependency
    ClassifierInState
    SignalEvent
    Constraint
    NodeInstance
    Usage
    Signal
    Actor
    Interface
    Component
    Link
    Primitive
    Collaboration
    SubsystemInstance
    ChangeEvent
    Generalization
    Stereotype
    Subsystem
    TagDefinition
    Abstraction
    Extend
    ActivityGraph
    Flow
    UseCaseInstance
    DataType
    Object
    Class
    TimeEvent
    ComponentInstance
    Exception
    Include
    CollaborationInstanceSet
    AssociationClass
    CallEvent
    Binding
    Package
    Node
    Artifact
    Model
    DataValue
    TaggedValue

    So the question is: is this lack of restriction intentional? And if so, why
    are ownedElements handled differently from features? And what is the
    semantic difference between entities selected using the "availableContents"
    association and those contained directly?

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: Node, Artifact, Package and Model contents problem

  • Key: UML14-81
  • Legacy Issue Number: 4735
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, the abstract metaclass Namespace
    compositely contains any type of ModelElement, but does however state that
    subclasses may restrict this containment [UML 1.4, pp. 2-45].

    The metaclasses Node, Artifact [UML 1.4, pp.1-16], Package and Model [UML
    1.4, pp.1-188] - all deriving from Namespace - make no such restrictions
    however.

    This means that Node, Artifact, Package and Model can compositely contain
    the following concrete metaclasses as ownedElements:

    Method
    Attribute
    Operation
    Reception

    State
    ActionState
    ObjectFlowState
    Transition
    CallState
    Pseudostate
    SimpleState
    SubactivityState
    SynchState
    CompositeState
    SubmachineState
    SubState
    FinalState

    CallAction
    TerminateAction
    CreateAction
    DestroyAction
    SendAction
    ActionSequence
    UninterpretedAction
    ReturnAction

    ExtensionPoint
    Stimulus
    Parameter

    Permission
    UseCase
    ProgrammingLanguageDataType
    StateMachine
    Comment
    LinkObject
    Enumeration
    Association
    Dependency
    ClassifierInState
    SignalEvent
    Constraint
    NodeInstance
    Usage
    Signal
    Actor
    Interface
    Component
    Link
    Primitive
    Collaboration
    SubsystemInstance
    ChangeEvent
    Generalization
    Stereotype
    Subsystem
    TagDefinition
    Abstraction
    Extend
    ActivityGraph
    Flow
    UseCaseInstance
    DataType
    Object
    Class
    TimeEvent
    ComponentInstance
    Exception
    Include
    CollaborationInstanceSet
    AssociationClass
    CallEvent
    Binding
    Package
    Node
    Artifact
    Model
    DataValue
    TaggedValue

    The question is: are all these ownedElement types intended for all the
    mentioned containers? Especially the first 28 in the list appear out of
    place.

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Suggest that alternate syntax used in section 6.5.5 be adopted thoughout

  • Key: UML14-89
  • Legacy Issue Number: 4816
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Subclassing of associations for various reasons leads to having duplicate opposite association ends with in the same class hierarchy unless the association ends are renamed for each subclass. A specific example where this has been miss-used is throughout the DMTF CIM specification.

    This rule is derived from section 6.5.4 and is expressed in the well-formedness rules in 2.5.3.8 for Classifiers. However, if opposite association end name(rolename) was qualified by association name, then the navigational reason to not allow duplicates goes away.

    Suggest that the alternate syntax used in section 6.5.5 be adopted thoughout. Specifically, define "rolename = associationName[oppositeassociationend]" Then specify "classifier.rolename" instead of "classifier.oppositeassociationend." Can then optionally allow use of "classifier.oppositeassociationend" when usage would not be ambiquous.

  • Reported: XMI 1.3 — Tue, 29 Jan 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Invalid XMI.link.atts in UML 1.4 DTD

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

    The DTD for UML 1.4 (ad/01-02-16)(which claims to be XMI 1.1) has a
    XMI.link.att declaration as follows:

    <!-- _______________________________________________________________ -->
    <!-- -->
    <!-- XMI.link.att defines the attributes that each XML element that -->
    <!-- corresponds to a metamodel class must have to enable it to -->
    <!-- function as a simple XLink as well as refer to model -->
    <!-- constructs within the same XMI file. -->
    <!-- _______________________________________________________________ -->

    <!ENTITY % XMI.link.att
    'href CDATA #IMPLIED xmi.idref IDREF #IMPLIED xml:link
    CDATA #IMPLIED xlink:inline (true|false) #IMPLIED
    xlink:actuate (show|user) #IMPLIED xlink:content-role
    CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:show
    (embed|replace|new) #IMPLIED xlink:behavior CDATA
    #IMPLIED'>

    The XMI 1.1 (and XMI 1.2) standard specifies only href and xmi.idref out of
    these (p4-81 of formal/00-11-02).

    The others seem to be copied from the "UML 1.1" DTD in the XMI 1.1 appendix
    (this appendix was removed at XMI 1.2 since it was wrong and misleading).

    Many of the above link attributes seem actually to be invalid:

    • xml:link is invalid since this is not part of the xml namespace
    • xlink:inline, xlink:behavior and xlink:content-role are not part of xlink
      namespace
    • xlink:actuate has invalid values - the standard values are
      (onLoad|onRequest|other|none)
    • xlink:show is missing values - the full set is
      (new|replace|embed|other|none) [I guess it is not so much of a problem to
      exclude certain values]
  • Reported: XMI 1.3 — Mon, 21 Jan 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4.1 should use MOF 1.4

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

    In the case of MOF 1.4 there are far more important reasons for moving to
    it. The main change in MOF 1.4 is a 'proper' modeled datatype system as
    opposed to CORBA datatypes hidden away in typeCodes. Because of this:
    a) MOF 1.4 is the basis of the Java Metadata Interface (JMI) which provides
    Java APIs to metamodels and is being adopted by a number of repository and
    UML tool vendors. Without an official version of UML expressed in MOF 1.4
    people will have to do their own conversion with subsequent interoperability
    problems

    b) MOF 1.4 is also the basis of XMI 1.2 and XMI 2.0 (XMI for XML Schemas).
    Without being expressed in MOF 1.4, the UML interchange definition cannot be
    expressed as an XML Schema.

    c) the proper datatype model provides the opportunity to 'clean up' a
    number of datatype-related issues in UML (e.g. issue 4452). And represent
    UML's datatypes such as Multiplicity and MultiplicityRange as MOF
    (structure) datatypes rather than MOF classes.

    I would expect this to only affect the UML 1.4.1 Concrete metamodel. I would
    be willing to draft a proposal for this. Is there a version of this with
    already-agreed 1.4.1 changes incorporated?

  • Reported: XMI 1.3 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Add action for invoking an activity

  • Key: UML14-94
  • Legacy Issue Number: 4940
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add action for invoking an activity

  • Reported: XMI 1.3 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: Wrong target for StateMachine.top association

  • Key: UML14-84
  • Legacy Issue Number: 4739
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A StateMachine compositely contains a State through the "top" association
    [UML 1.4, pp. 2-147, fig. 2-24].

    However, the wellformedness rules for StateMachine state that "A top state
    is always a composite: self.top.oclIsTypeOf(CompositeState)" [UML 1.4, pp.
    2-158].

    If that is the case, the top association should target a CompositeState, not
    the more general State.

    Note: of course this is not an error as such, but if a wellformedness rule
    can be expressed just as easily in UML, there is no reason to complicate
    matters

  • Reported: XMI 1.3 — Thu, 6 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: AttributeLink containment error

  • Key: UML14-83
  • Legacy Issue Number: 4738
  • Status: closed  
  • Source: Anonymous
  • Summary:

    AttributeLink is unconditionally contained in an Instance [UML 1.4, pp.
    2-97, fig.2-16], as well as being contained in a LinkEnd [UML 1.4, pp. 2-98,
    fig.2-17].

    The former containment obviously prevents the latter from ever being
    realized.

    Note: If changing the former containment from mandatory to optional, please
    remember to exclude AttributeLink from other composite containments
    implicitly enabled by such a change - such as being an ownedElement of a
    Namespace, or a parameter of a template.

  • Reported: XMI 1.3 — Thu, 6 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Definitions in glossary don't conform to any standard for definitions

  • Key: UML14-87
  • Legacy Issue Number: 4800
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The definitions in the glossary are often incomplete, vague, and, most importantly, DO NOT CONFORM TO ANY STANDARD FOR DEFINITIONS.

    For those of us in IT who have studied concepts such as "language" and "word" and "definition" it is very disturbing to find people purporting to develop a new "language" who do know how to define words.

    Please get QUALIFIED help immediately. The work you are doing is too important to too many people. If you want OMG and UML to be taken seriously, do it right.

    People in the information business should understand that wrong information is much worse than no information. Do it right or just don't do it.

  • Reported: XMI 1.3 — Wed, 2 Jan 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Composite relationship between Event and StateMachine

  • Key: UML14-86
  • Legacy Issue Number: 4746
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    As previously mentioned in issues 3558 (Who owns an Event?) and
    4734 (Event containment problem).
    Based upon issue 3558 response I believe that an Event should be owned by a
    StateMachine.
    A composite relationship should be added between Event and StateMachine in
    the UML Meta-Model.

  • Reported: XMI 1.3 — Wed, 12 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Simplify inputs/outputs of procedures

  • Key: UML14-92
  • Legacy Issue Number: 4927
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [Conrad Bock, Jim Rumbaugh] Simplify inputs/outputs of procedures so
    they point at inputs/outputs of contained actions. Groups referred
    input pins together that receive the value from the same parameter.

  • Reported: XMI 1.3 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

match/correspond clarfication

  • Key: UML14-91
  • Legacy Issue Number: 4917
  • Status: closed  
  • Source: International Business Machines ( Mr. Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 33. Chapter 7 : Collection Action Classes. The
    specification text does not clearly explain how 'match' and 'correspond'

    • dependencies are to be used. See figure 2-57, page 2-307 are used in
      the spec. Are these intended to be illustrative? Are they constraints
      on the values passing thru input and output pins. What is the
      difference between 'match' and 'correspond'?
  • Reported: XMI 1.3 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

StartStateMachine clarification

  • Key: UML14-93
  • Legacy Issue Number: 4936
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [Conrad Bock] Does StartStateMachine cause the intial state to be
    entered and its outgoing transition taken? Ie, what is the semantics in
    relation to the RTC step.

  • Reported: XMI 1.3 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Namespace.contents

  • Key: UML14-90
  • Legacy Issue Number: 4848
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The current definition of the operation Namespace.contents is:

    The operation "contents" results in a Set containing all ModelElements
    contained by the Namespace.
    contents : Set(ModelElement)
    contents = self.ownedElement -> union(self.namespace, contents)

    (UML Specification, version 1.4 page 2-64, version 1.3 page 2-55)

    The last line of this definition seems wrong, since the "union" operation
    must have a single parameter.

    The former definition of this operation did not present any contradiction
    between text and OCL expression:

    The operation "contents" results in a Set containing all ModelElements
    contained by the Namespace.
    contents : Set(ModelElement)
    contents = self.ownedElement

    (UML Semantics, version 1.1 page 32)

  • Reported: XMI 1.3 — Tue, 26 Feb 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Adding events to the class definition

  • Key: UML14-85
  • Legacy Issue Number: 4740
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The proposal is to add an optional fourth compartment to the
    class artifact that lists events that are accepted by that
    class.

    If a class is 'Active', it will have an associated
    state/activity model. This state/activity model will respond to
    events sent to that class. At the moment the only way to
    determine what events can be accepted by a class is to observe
    its state/activity model. Very clumsy!

    A workaround is to list events in the operations compartment
    and label them with an appropriate stereotype <<event>> for
    example. This should only be a temporary solution, since events
    are no more operations than they are attributes.

    Events need to be part of the class definition.

  • Reported: XMI 1.3 — Fri, 7 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Parametrizable model elements not shown

  • Key: UML14-17
  • Legacy Issue Number: 1209
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 5.11.1 pg. 39 says "Parametrisation can be applied to other
    ModelElements". Implicitly not to all ModelElements. Which ModelElements
    can
    and which cannot be templates?
    Some clarifications would be welcome, in what concerns the
    parametrisation of other kind of model elements, such as packages,
    operations and methods.

  • Reported: XMI 1.0 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Inconsistency regarding guards on forks

  • Key: UML14-119
  • Legacy Issue Number: 5745
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This applies to UML 1.4.1. ad/02-06-05. There seems inconsistency as to whether forks can have guards.
    The notation, section 3.9.4, states: "In Activity Diagrams, transitions outgoing from forks may have guards. This means the region initiated by a fork transition might not start, and therefore is not required to complete at the corresponding join. The usual notation and mapping for guards may be used on the transition outgoing from a fork."

    However this seems contradicted by Section 2.12.2.7, PseudoState, which states: "fork vertices serve to split an incoming transition into two or more transitions terminating on orthogonal target vertices. The segments outgoing from a fork vertex must not have guards."

    Is this a real inconsistency or do activity diagrams really override the constraint on Pseudostates in State Machines?

  • Reported: XMI 1.3 — Fri, 1 Nov 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

spelling of the word Use Case

  • Key: UML14-118
  • Legacy Issue Number: 5744
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    I have a question about the spelling of the word Use Case. The different
    >spellings used everywhere are a little bit irritating to me (but this may
    >not be the case for other people). I think that it should be one fixed
    >spelling of the word defined i UML. But even in the UML specification I
    >found three different spellings on the same side: Use Case, use case and
    >UseCase. In a book I'm reading they use the following spelling: Use Case
    >and, when used with other words, Use-Case (Realization for example).

  • Reported: XMI 1.3 — Fri, 25 Oct 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

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

There is an unnecessary condition in rule 1 of the Namespace element

  • Key: UML14-110
  • Legacy Issue Number: 5732
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    There is an unnecessary condition in rule 1 of the Namespace element – “me2.name<>’’”. Also we should add the following condition to the OCL expression: “not me1.oclIsKindOf (Generalization) and not me2.oclIsKindOf(Generalization)”.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Rule 6 of the Method element isn't formulated well

  • Key: UML14-109
  • Legacy Issue Number: 5731
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    Rule 6 of the Method element isn't formulated well. It’s better to write so: “self.owner.allMethods->select( me | me.operation = self.operation).size = 1”.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

There is a misprint in rule 2 of the Object element: “Stimuli” instead of “

  • Key: UML14-115
  • Legacy Issue Number: 5738
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    There is a misprint in rule 2 of the Object element: “Stimuli” instead of “Stimulus”.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

There are misprints with numeration of rules of the Instance element

  • Key: UML14-114
  • Legacy Issue Number: 5737
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    There are misprints with numeration of rules of the Instance element

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

there is something wrong with rule 3 of the Trace element

  • Key: UML14-112
  • Legacy Issue Number: 5735
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    think there is something wrong with rule 3 of the Trace element. The “model” additional operation of the ModelElement element yields the set of Models to which it belongs. Maybe we should add “allModels” operation and use it in rule 4 of the Trace element.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

The first sentence is not consistent with figure 2-9 on page 2-17

  • Key: UML14-120
  • Legacy Issue Number: 5763
  • Status: closed  
  • Source: Combitech Systems ( Per Tengdahl)
  • Summary:

    The first sentence is not consistent with figure 2-9 on page 2-17! It seems reasonable to accept the sentence and to clarify in figure 2-9 that the 'subject' end of the association has multiplicity "1.." and not "".

  • Reported: XMI 1.3 — Tue, 19 Nov 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Wrong alphabetical order: DataValue section should be before DestroyAction

  • Key: UML14-113
  • Legacy Issue Number: 5736
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    Wrong alphabetical order: DataValue section should be before DestroyAction section.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Add rule to Namespace element

  • Key: UML14-111
  • Legacy Issue Number: 5734
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    I think we should add the following rule to the Namespace element: “not self.allContents->includes(self)”.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

There is a misprint in rule 1 of the SubsystemInstance element

  • Key: UML14-116
  • Legacy Issue Number: 5739
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    There is a misprint in rule 1 of the SubsystemInstance element: “Stimuli” instead of “Stimulus

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

font sizes

  • Key: UML14-117
  • Legacy Issue Number: 5740
  • Status: closed  
  • Source: Anonymous
  • Summary:

    “self.stateMachine->notEmpty” and “and not oclIsKindOf(self.stateMachine, ActivityGraph))” are in different font size.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Optimize Instance data values

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

    Although the DataValue class claims to 'have no identity' it nonetheless inherits from ModelElement and is represented as a 'normal' object in the interchange as well as the logical metamodel (so will also inherit annotation and name - though presumably it's 'name' that is used to hold the actual value of the DataValue since no attribute seems to be actually defined for that purpose). And will it end up becming a first class object by default in most automatically-generated repositories or tool implementations.

    There are applictions of UML, and CWM which reuses it, which require a large number (several thousand) of data instances to be modeled - for which requiring a separate physical/interchange object for each data value is extremely inefficient. Not only does it double the number of objects, the DataValues have to be contained somewhere - which results in a parent package not only owning the Instance objects but a large number of DataValues also which must be filtered out if wanting to navigate from an Instance Model (for example) to its instances.

    Since a DataValue in practice has a 1-1 relationship with an AttributeLink, it is proposed that in the Interchange Model at least that DataValues be represented as a String attribute on AttributeLink. For forward compatibility it might be necessary to introduce a subclass of AttributeLink for this - which could even be called 'DataSlot' for compatibility with CWM (an equivalent proposal has been made to CWM RTF which uses 'Slot' instead of 'AttributeLink') And one could retain DataValue in deprecated mode.

    NB There is no practical benefit in having the current Link from dataValue to Classifier (DataType), since this is already linked from the Attribute (and the ability to record that a DataValue has a subtype of its Attribute's type seems too obscure in comparison to the cost).

  • Reported: XMI 1.2 — Thu, 16 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Component notation: showing delegation of messages

  • Key: UML14-66
  • Legacy Issue Number: 4465
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    The current notation does not provide for showing how method calls
    or messages to a component interface are delegated (or propagated) to the
    interfaces in components or implementation classes that reside in the
    component. This is sometimes referred to as the "wiring problem."

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: State containment problem

  • Key: UML14-75
  • Legacy Issue Number: 4729
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 metamodel, a State can either be contained as a
    "subvertex" in a CompositeState [UML 1.4, pp. 2-147], as the "top" state in
    a StateMachine [UML 1.4, pp. 2-147], or as an "ownedElement" [UML 1.4, pp.
    2-13] in a Model, Package, Artifact, Node or ClassifierRole (all other
    concrete subclasses of Namespace restrict their owned elements to exclude
    State). The latter containment does not seem to make a lot of sense.

    Fortunately, the description of a StateMachine states that "This means that
    a state machine owns its transitions and its top state. All remaining states
    are transitively owned through the state containment hierarchy rooted in the
    top state." [UML 1.4, pp. 2-153].

    The question is: does this mean that a State is restricted to being
    contained in a CompositeState or a StateMachine? If not, please explain the
    meaning of e.g. a State contained directly in an otherwise empty Package?

    If the mentioned restriction is intended, it should be stated
    unambiguously so in the wellformedness rules for State:

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: Action problem in Collaborations

  • Key: UML14-74
  • Legacy Issue Number: 4728
  • Status: closed  
  • Source: Anonymous
  • Summary:

    n UML 1.4, an Action is only used in the context of a StateMachine or a
    CollaborationInstanceSet.

    In a CollaborationInstanceSet, an Action is required as the cause of a
    Stimulus [UML 1.4, pp. 2-97], but since the Action can only be contained in
    a Namespace (or in the context of a StateMachine, which is irrelevant here),
    it cannot be contained in the Stimulus, nor in the Instances the Stimulus
    connect, nor in the InteractionInstanceSet or CollaborationInstanceSet they
    are part of. The "nearest" possible container is the Package that happens to
    contain the CollaborationInstanceSet.

    Intuitively, this makes no sense - used in this context, the Action is
    clearly part of the InteractionInstanceSet, or the participating Instances
    or Stimuli.

    If this error report is rejected, please elaborate on the intended
    containment structures for Collaboration instances.

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: Event containment problem

  • Key: UML14-80
  • Legacy Issue Number: 4734
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, an Event is defined as "...a
    specification of a type of observable occurrence" [UML 1.4, pp. 2-150]. It
    is used exclusively in the context of state machines, as triggers of state
    transitions [UML 1.4, pp. 2-147, fig. 2-24].

    Because Event is a direct subclass of ModelElement - and because no other
    composite containments are specified for Event or any of its subclasses - it
    must be compositely contained as an ownedElement in a ClassifierRole, Model.
    Package, Artifact or Node (all other concrete subclasses of Namespace have
    restricted their owned elements to exclude Event).

    The question is: is this containment intended, or should an Event be
    contained in e.g. the StateMachine in which it is used? If the currently
    allowed containment IS intended, please explain the semantics of e.g. an
    Event contained in an otherwise empty Package (or even Model).

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: Stimulus containment

  • Key: UML14-79
  • Legacy Issue Number: 4733
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, a Stimulus is a ModelElement representing
    a communication between two instances [UML 1.4, pp. 2-106]. It is used
    exclusively in the context of collaborations, as part of an
    InteractionInstanceSet [UML 1.4, pp. 2-120].

    Because Stimulus is a direct subclass of ModelElement - and because no other
    composite containments are specified for Stimulus - it must be compositely
    contained as an ownedElement in a ClassifierRole, Model. Package, Artifact
    or Node (all other concrete subclasses of Namespace have restricted their
    owned elements to exclude Stimulus).

    Having the Stimulus be part of any of these classes makes no sense, as it is
    intuitively part of the InteractionInstanceSet.

    Proposed remedy: change the association between InteractionInstanceSet and
    Stimulus [UML 1.4, pp. 2-120, diagram 2-20] to a mandatory composite
    containment (with Stimulus as the part).

    Alternatively, please clarify the intended semantics of each of the
    currently allowed containments listed above

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: Transition containment problem

  • Key: UML14-77
  • Legacy Issue Number: 4731
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, a Transition [UML 1.4, pp. 2-147] is
    contained either as an "internalTransition" in a State, as a "transition" in
    a StateMachine, or as an "ownedElement" [UML 1.4, pp. 2-13] in a Model,
    Package, Artifact, Node or ClassifierRole (other containers excluded because
    of restrictions they make on the "ownedElement" containment in their
    wellformedness rules). The latter containment does not seem to make a lot of
    sense.

    The question is: is the containment of a Transition as an "ownedElement"
    intended? If so, please explain the meaning of e.g. a Transition contained
    directly in an otherwise empty Package.

    If not, it should be stated unambiguously so in the wellformedness rules for
    Transition, e.g.:

    self.namespace = null

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: ExtensionPoint containment problem

  • Key: UML14-76
  • Legacy Issue Number: 4730
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 metamodel, an ExtensionPoint [UML 1.4, pp. 2-135]
    can be contained as an ownedElement [UML 1.4, pp. 2-13] in a Model, Package,
    Artifact, Node or ClassifierRole (other containers excluded because of
    restrictions they make on the "ownedElement" containment in their
    wellformedness rules).

    The questions are: what is the intended meaning of an ExtensionPoint in eg.
    an otherwise empty Package? Why isn't the ExtensionPoint contained in the
    UseCase it extends, as would appear more logical to the uninitiated?

    Suggestion: change the association between ExtensionPoint and UseCase [UML
    1.4, pp. 2-135] to an unconditional composite containment (with
    ExtensionPoint as the part).

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: Feature containment problem

  • Key: UML14-78
  • Legacy Issue Number: 4732
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, a Feature [UML 1.4, pp. 2-13] is
    contained either as an "feature" in a Classifier, or as an "ownedElement"
    [UML 1.4, pp. 2-13] in a Model, Package, Artifact, Node or ClassifierRole
    (other containers excluded because of restrictions they make on the
    "ownedElement" containment in their wellformedness rules). In addition an
    Attribute (subclass of Feature) may be contained as a "qualifier" in an
    AssociationEnd [UML 1.4, pp. 2-14].

    The question is: is the containment as an "ownedElement" intended? If so,
    please explain the meaning of e.g. an Operation contained directly in an
    otherwise empty Package.

    If not, it should be stated unambiguously so in the wellformedness rules for
    Feature:

    self.namespace = null

    Remarks:
    ========
    It should be noted that the standard does make a number of partly
    contradictory statements which seem to indicate that Features can not be
    used as ownedElements:

    Page 2-25: "BehavioralFeature specifies a behavioral aspect of a
    Classifier."
    Page 2-36: "A feature [...] is encapsulated within a Classifier."
    [contradicts with the statement below].
    Page 2-37: "Note that an Attribute may be owned by a Classifier (in which
    case it is a feature) or an AssociationEnd (in which case it is a qualifier)
    but not both."
    Page 2-42: "Method is a declaration of a named piece of behavior in a
    Classifier"
    Page 2-45: "Operation is a BehavioralFeature that can be applied to the
    Instances of the Classifier that contains the Operation.".

    These statements could however be made unambiguous by adding the mentioned
    wellformedness rule.

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: Action containment error

  • Key: UML14-73
  • Legacy Issue Number: 4727
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Because Action is a ModelElement, it may be contained as an ownedElement
    [UML 1.4, pp. 2-13, fig. 2-5] in a ClassifierRole, Model, Package, Artifact,
    Node or Collaboration (all other concrete subclasses of Namespace restrict
    their owned elements to exclude Action).

    Because Actions are only used in the context of either a StateMachine or a
    CollaborationInstanceSet, this containment does not seem to make sense.

    In order to exclude these containments, the wellformedness rules for Action
    could include the following statement:

    self.namespace = null

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Guard in current metamodel can be replaced by Constraint with stereotype

  • Key: UML14-19
  • Legacy Issue Number: 2020
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Guard metatype in the current metamodel contains only one attribute
    of type BooleanExpression. Since a guard is semantically equivalent to
    a Constraint on the transition, we can remove the Guard metaclass and
    add e standard stereotype <<guard>> for Constraints, with the same
    semantics.

    It simplifies the metamodel by unifying the Guard and Constraint concepts.
    It also allows OCL as the optional language to write the guard expression.

    Within the OCL specification, it should be checked if there are any
    additions that need to be made to support everything neded to express
    udseful guards.

  • Reported: XMI 1.0 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Need for notation for dealing with evolution of UML models

  • Key: UML14-18
  • Legacy Issue Number: 1512
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is a need for a notation for dealing with evolution of UML models. Currently, UML does not provide adequate support for dealing with evolution of software components in a disciplined way. With disciplined evolution we mean that there should be a general mechanism to express how a modelling element evolves over time by adding, removing or changing parts of it. In the current version of UML, 2 mechanisms could be used to describe the evolution process, but they both have their shortcomings:

  • Reported: XMI 1.0 — Mon, 8 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Missing OCL

  • Key: UML14-25
  • Legacy Issue Number: 2289
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I would like to note that in the UML Semantics specification (versions 1.1
    and 1.2) the third well-formedness rule for Association does not have an
    OCL expression. It has only the natural language expression.

  • Reported: XMI 1.0 — Tue, 5 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

OCL needs to be added

  • Key: UML14-24
  • Legacy Issue Number: 2278
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Only binary associations may be aggregates. There needs to
    be OCL added to do this.

  • Reported: XMI 1.0 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Add the missing OCL

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

ElementOwnership

  • Key: UML14-26
  • Legacy Issue Number: 2290
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In UML versions 1.1, 1.2, and 1.3 the class diagram for the Core Backbone
    declares ElementOwnership as an AssociationClass. This appears to be a
    violation of MOF compliance, since the MOF meta-meta-model does not support
    the notion of an AssociationClass.

    Of course one could extrapolate AssociationClass from the MOF
    meta-meta-model since it does support both Association and Class, and one
    could also logically extrapolate a MOF-IDL and MOF-XML mapping for an
    extrapolated MOF AssociationClass. However, two architects might
    extrapolate these mappings in perfectly valid but different manners, since
    there is no standard mapping for a MOF AssociationClass. Apparently such
    an extrapolation has been performed in order to derive the IDL for the UML
    meta-model that concerns ElementOwnership, but doing this without a
    standard mapping seems dangerous.

  • Reported: XMI 1.0 — Tue, 5 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

extension to the notation for a transition

  • Key: UML14-28
  • Legacy Issue Number: 2336
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I would like to make an appeal for an extension to the notation for a transition
    to allow its effect to be specified declaratively rather than only imperatively by
    means of an action sequence, e.g.

    e() / [p]

    While I realize there are ways to work around this (e.g. by writing "e() / pTrue()"
    where the query pTrue() has the postcondition "result = p and in targetState"), I
    think the issues are readability and ease of use.

  • Reported: XMI 1.0 — Fri, 22 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Page 19 semantic doc. name

  • Key: UML14-23
  • Legacy Issue Number: 2277
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 19 semantic doc. name is described here but is not shown as
    a metalevel attribute on Figure 6. It should be.

  • Reported: XMI 1.0 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 1.1.section 4.2:editorial

  • Key: UML14-22
  • Legacy Issue Number: 2276
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Aggregation: "when on target end, specifies whether target end
    with respect to source end". I think target and source are the wrong
    way round here.

  • Reported: XMI 1.0 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

User-defined symbols for tagged values and properties

  • Key: UML14-27
  • Legacy Issue Number: 2291
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML allows users to define specific symbols and icons for stereotypes. It should also be allowed to define specific symbols and icons for tagged values and properties. For example, users that often use the properties

    {ordered}

    ,

    {frozen}

    and

    {add only}

    may define they own user-defined icons for those properties, because UML does not define them.

    Suggested Solution:
    UML users should be allowed to define specific symbols and icons for tagged values and properties.

  • Reported: XMI 1.0 — Wed, 6 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Associate a predicate with a state

  • Key: UML14-29
  • Legacy Issue Number: 2337
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Related to the previously submitted issue regarding the declarative specification of
    the effects of transitions, I would like to suggest that it be possible to associate
    a predicate with a state.

    Such a predicate (e.g. written in OCL) would appear within the state box in the
    notation, just below the name of the state.

    Rather than extend the notation directly, I suggest this be a predefined property,
    e.g.

    {predicate = boolean-expression}

    .

  • Reported: XMI 1.0 — Fri, 22 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Figure 7 p. 43 of the UML semantics guide

  • Key: UML14-21
  • Legacy Issue Number: 2208
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On Figure 7 p. 43 of the UML semantics guide,
    Template is described as a shared aggregate of its templateParameters,
    while Binding (representing an instantiation of a Template) is described
    as a composite aggregate of the actual arguments.

  • Reported: XMI 1.0 — Fri, 13 Nov 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

AssociationEnd needs ownerScope

  • Key: UML14-20
  • Legacy Issue Number: 2083
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I believe AssociationEnd needs an ownerScope attribute. How else could one
    model a static (as in Java) relationship? Currently, it appears to only be
    possible using an Attribute of Classifier.

  • Reported: XMI 1.0 — Thu, 15 Oct 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Initial state for composite states - OCL example and missing constraint

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

    This issue was triggered by what seemed to be an ill-formed state machine
    example which revealed a deeper lack of rigor in the spec.

    The example state machine in section 6.5.10 (illustrating oclInState) does
    not have an initial pseudostate within the 'Off' state. Section 3.80.2
    indicates that this is mandatory:
    "A transition drawn to a composite state boundary indicates a transition to
    the
    composite state. This is equivalent to a transition to the initial
    pseudostate within the
    composite state region. The initial pseudostate must be present."

    [Aside: There's also typo in the list of valid OCL expressions in 6.5.10:
    object.oclInState(Off:NoPower) should have a double colon:
    object.oclInState(Off::NoPower)].

    If indeed it is mandatory to have an initial state where there is a
    transition to a composite state (this does seem sensible for
    predictability), this should be reflected in a constraint within the
    abstract Syntax (section 2.12) to the effect that a CompositeState with
    'incoming' Transitions must contain an initial PseudoState.

    For example 2.12.4.3 contains the following which implies an initial
    pseudostate, though uses the ill-defined 'default transition' as well as
    'initial transition':
    "Entering a non-concurrent composite state
    Upon entering a composite state, the following cases are differentiated:
    • Default entry: Graphically, this is indicated by an incoming transition
    that
    terminates on the outside edge of the composite state. In this case, the
    default
    transition is taken. If there is a guard on the transition it must be
    enabled (true). (A
    disabled initial transition is an ill-defined execution state and its
    handling is not
    defined.) The entry action of the state is executed before the action
    associated with
    the initial transition."

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

    1. Change example in 6.5.10 to add an initial pseudostate within the 'Off'
    composite with a transition to 'Standby'.

    2. Correct typo in 6.5.10 valid expressions: object.oclInState(Off:NoPower)
    should have a double colon: object.oclInState(Off::NoPower)

    3. Add the following constraint to section 2.12.3.1
    [7] A composite state with an incoming transition must have an initial
    state.
    self.incoming->notEmpty() implies
    self.subvertex->select (v | v.oclIsKindOf(Pseudostate))->select(p :
    Pseudostate | p.kind = #initial)->size = 1

    4. Alter the section in 2.12.4.3 to read as follows:
    "Entering a non-concurrent composite state
    Upon entering a composite state, the following cases are differentiated:
    • Default entry: Graphically, this is indicated by an incoming transition
    that
    terminates on the outside edge of the composite state. In this case, there
    must be an initial state and the initial
    transition is taken. If there is a guard on the transition it must be
    enabled (true). (A
    disabled initial transition is an ill-defined execution state and its
    handling is not
    defined.) The entry action of the state is executed before the action
    associated with
    the initial transition."

  • Reported: XMI 1.3 — Thu, 9 May 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

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

UML 1.4 - Partition relates to nothing

  • Key: UML14-99
  • Legacy Issue Number: 5269
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    UML 1.4 has no association for showing what a Partition relates to.
    Typically this would be something representing a role in a process.

  • Reported: XMI 1.3 — Tue, 7 May 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

In v1.4, section 3.84.1 the paragraph on semantics

  • Key: UML14-104
  • Legacy Issue Number: 5657
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    "An Activity Diagram is a special case of a state machine in which the
    states represent performance of actions or subactivitities and the
    transitions are triggered by the completion of actions or subactivities. It
    represents the state machine of a procedure itself."

    But in Section 2.13.1 it says:

    "An activity graph is a special case of a state machine that is used to
    model processes involving one or more classifiers. Its primary focus is on
    the sequence and conditions for the actions that are taken, rather than on
    which classifiers perform those actions. Most of the states in such a graph
    are action states that represent atomic actions; that is, states that invoke
    actions and then wait for their completion. Transitions into action states
    are triggered by events, which can be

    • the completion of a previous action state (completion events),
    • the availability of an object in a certain state,
    • the occurrence of a signal, or
    • the satisfaction of some condition.
      "

    The latter statement implies that (a) events other than completion of prev
    activity can be triggers and (b) entire processes, not just procedures can
    be modeled in ADs.

    Which one is it?

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Section 2.13.4.3

  • Key: UML14-103
  • Legacy Issue Number: 5656
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    2) Section 2.13.4.3 says

    "Unless there is an explicit "fork" that creates orthogonal obect
    states only one of an object flow state's outgoing transitions will fire as
    determined by the guards of the transitions",

    which seems to require that if you want to "feed" the object to multiple
    actions, you will need a "fork" bar. But then 3.90.2.2 says:

    "The same object may be (and usually is) the output of one action
    and the input of one or more subsequent actions".

    This would seem to suggest that a "fork" bar is not required. Please
    clarify.

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML Issue - Inconsistency between UML 1.3 XMI and DTD

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

    The UML 1.3 DTD implies a reference ModelElement.taggedValue which does not
    exist in the UML metamodel XMI file. This causes problems for my product
    which is metamodel-driven so reports an error when an import attempts to
    supply a value for the non-existent reference. This is strictly speaking a
    bug in the DTD (since it's not generated according to the XMI rules):
    however changing the DTD might cause inconvenience for vendors who are
    making use of it, and because not having the reference would make processing
    the tags much harder.

    At UML 1.4 the reference has been added to the metamodel, which suggests
    that the metamodel rather than the DTD be fixed. However this could require
    a restructuring to avoid circular package dependencies [see UML issue 3735].

    The same issue applies to the 'stereotype' reference on ModelElement - again
    it should ideally be added to the metamodel.

    The reason I'm raising the issue on UML 1.3 is that this is the chosen
    version for interoperability work. A decision is needed as to which way to
    resolve the inconsistency within UML 1.3 without forcing an upgrade to UML
    1.4.

  • Reported: XMI 1.3 — Fri, 19 Jul 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Section number duplicated

  • Key: UML14-107
  • Legacy Issue Number: 5685
  • Status: closed  
  • Source: Alcatel-Lucent ( Julien Maisonneuve)
  • Summary:

    Probably an Action Semantics RTF Issue, but one that may be addressed
    in an UML RTF.

    In the UML 1.5 spec in the action semantics chapter, sections numbers
    2.16 and 2.17 are duplicated. The section content appears all right
    but the succession of titles is : 2.15, 2.16, 2.17, 2.16, 2.17, 2.18.

    The document simply needs consistent renumbering of that chapter.

  • Reported: XMI 1.3 — Mon, 14 Oct 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Section 3.90.2.2

  • Key: UML14-106
  • Legacy Issue Number: 5659
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    Section 3.90.2.2 says

    "In other words when a state prodices an outpout that is input to the
    subsequent state, that object flow relationship implies a control
    constraint."

    I take it that this is not the same as isSynch being true? That is isSynch
    means that an object in an object flow is rather like a token in a Petri
    net. ie once it flows out to the consuming state, its gone from its place.
    Is that correct?

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Well-formedness rules 4 and 6 on 2.12.3.4 PseudoState

  • Key: UML14-97
  • Legacy Issue Number: 5267
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Well-formedness rules 4 and 6 on 2.12.3.4 PseudoState make incorrect use of
    oclIsKindOf, which should only take a single argument.

  • Reported: XMI 1.3 — Tue, 7 May 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

A_context_raisedSignal

  • Key: UML14-96
  • Legacy Issue Number: 5005
  • Status: closed  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    The
    association in question is not named in the UML 1.4 interchange model. The
    name "A_context_raisedSignal", is an artificial one that was created by the
    program that created the DTD. It was using an algorithm recommended by the
    MOF RTF for naming unnamed associations. However, it would seem to be wise
    policy for this association to have a name. This would remove any
    dependency on the vagaries of various MOF tools.

  • Reported: XMI 1.3 — Tue, 19 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

How does one indicate the target object for a CallState

  • Key: UML14-102
  • Legacy Issue Number: 5655
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    How does one indicate the target object for a CallState (i.e. the actual
    object that executes the stated action/method)? If the target action takes
    no parameters then it may be possible to say that the target object is just
    the object flowing into the CallState. But what if it does take parameters?
    (e.g. the Person.Drive(to: Place) example in Fig. 3-88). That would require
    more than one object to be flowing into the CallState and leads to an
    ambiguity about which constitutes the target and which the parameter.

    P.S. The actual object may be passed around by the activity diagram, so it
    is not possible to show it statically on a swimlane (even if that is the
    recommended way)

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

parameters of object flow states

  • Key: UML14-105
  • Legacy Issue Number: 5658
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    parameters of object flow states – The Notation section of the UML 1.4
    Spec does not discuss it, nor is an example provided. I am still in the dark
    about how parameters are supposed to be used in the context of object flow
    states. Are output parameters supposed to be like reference parameters in
    the Algol style languages?

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Well-formedness rules for 2.12.3.8

  • Key: UML14-98
  • Legacy Issue Number: 5268
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Well-formedness rules for 2.12.3.8 Transition numbered 1, 3 and 4 make
    incorrect use of oclIsKindOf, which only takes one argument.

  • Reported: XMI 1.3 — Tue, 7 May 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Swap rule 2 and rule 3 of the Binding element

  • Key: UML14-108
  • Legacy Issue Number: 5730
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    Swap rule 2 and rule 3 of the Binding element. It improves readability

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4 RTF Issue: Multiple languages for uninterpreted strings

  • Key: UML14-45
  • Legacy Issue Number: 3391
  • Status: closed  
  • Source: ObjectSwitch ( Conrad Bock)
  • Summary:

    Multiple languages for uninterpreted strings

    The various places that uninterpreted strings are used in UML should
    support multiple languages. For example, the Expression metaclass has
    an metaattribute for language and another for the uninterpreted string.
    This should be a set of such pairs. Then code generators can target
    multiple languages from the same model.

  • Reported: XMI 1.1 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    resolved, see above

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

Efficient diagrammatic notation for Collaboration Specifications

  • Key: UML14-42
  • Legacy Issue Number: 3368
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I have played a lot with different ways of showing how several collaboration specifications may appear in one class diagram.

    Right now, there are collaboration specification diagrams, and there are class diagrams that feature template instantiations, but no class diagrams that feature collaboration specifications. If you use a round ellipse for hooking up a collaboration specification into a class diagram, you will see ellipses all over the place, but will not see how the collaboration specifications relate to the associations between the classes.

    I can show you the variations of how to draw collaboration specifications in class diagrams. In case you wonder whether you really need this, I can offer you my whole Ph.D. thesis, which is on framework design using role modeling ) There is plenty of other work going into this direction, for example Erich Gamma’s pattern annotations in class diagrams.

  • Reported: XMI 1.1 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Statemachine/state as Namespace

  • Key: UML14-41
  • Legacy Issue Number: 3341
  • Status: closed  
  • Source: University of Oslo ( Birger Møller-Pedersen)
  • Summary:

    I am not sure if this qualify as an Issue, but I what just wondering
    why Statemachine and State are not Namespaces. Is it so that names are not supposed to be defined within these, or do names end up in the Namespace of the context model element?

  • Reported: XMI 1.1 — Mon, 28 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: Missing notation mapping for association in composite

  • Key: UML14-40
  • Legacy Issue Number: 3291
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    No mapping for this in mapping section, p 3-77:

    [p 3-75, Notation section for Composition] An association drawn
    entirely within a border of the composite is considered to be
    part of the composition.

  • Reported: XMI 1.1 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

ClassifierRoles should be independent of specific underlying base Classifi

  • Key: UML14-43
  • Legacy Issue Number: 3376
  • Status: closed  
  • Source: Anonymous
  • Summary:

    ClassifierRoles should be independent of specific underlying base Classifiers. Otherwise, you can not specify OOram role models properly. You need "free" ClassifierRoles (=without base) if you want to span layers, for example.

    Collaboration Templates don't do the trick; templates serve a different purpose.

    Please contact me at riehle@acm.org if you want to know more. I have long worked on this topic.

  • Reported: XMI 1.1 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4 issue: Top state in activity graphs

  • Key: UML14-44
  • Legacy Issue Number: 3382
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Top state in activity graphs

    The state machine meta-model currently requires a top state, whereas
    activity graphs should not. Composite states are not required for
    activity graphs (wf [2] for PseudoState, p 2-166).

  • Reported: XMI 1.1 — Tue, 29 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Rule 1 references 2:ContentElements which is undefined

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

    This is intended to represent arbitrary XML elements which might be unrelated to XMI.

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

    Use a comment rather than a numbered clause

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

Rule 4i in 5.2 has the following with only 2 options

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

    2. Rule 4i in 5.2 has the following with only 2 options:

    ("type=’xsd:IDREFS’ use=’optional’/>"

    "type=’xsd:IDREF’ use=’required’/>"

    Why not separate the use from the type and allow all 4 combinations e.g. for an optional single-valued attribute? Or a required multivalued one?

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

    Allow all 4 options

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

Use of "xmi:" and //xmiPrefix// is inconsistent.

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

    Use of "xmi:" and //xmiPrefix// is inconsistent. 2e and 2f use the latter

    even though 1f clearly specifies that xmi is the prefix. "xmi:" should

    be used directly in 2e and 2f.

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

    resolved

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

1b has been deleted, but it is still referenced from 2g, 2l and 3

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

    1b has been deleted, but it is still referenced from 2g, 2l and 3. I think

    those should actually be:

    2g:TypeAttribute ::= "xmi:type='" 2k:QName "'"

    2l:LinkAttribute ::= "xmi:idref='" //refId// "'" | 2m:Link

    3:Extension ::= "<xmi:extension xmi:type='xmi:Extension'"

    (" extension='" // extender // "'")?

    (" extenderID='" // extenderID // "'")?

    ">"

    // Extension elements //

    "</xmi:extension>"

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

    Take the recommendation from the issue which corrects the resolution of issue 8438.

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

When 2n is used with 2j it is supposed to match the last part of schema production

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

    When 2n is used with 2j it is supposed to match the last part of schema production

    rule 4i:

    (Qname ? "type='xsd:anyURI' use='optional'/>"))

    Is that even valid XML schema? It only allows a single anyURI so 2j

    doesn't comply with it. However the description of 4i doesn't mention

    it, nor does section 4.8.5 - Reference representation.

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

    Issue 15453 identifies the same problem and removes the option to use a URI in 2j.

    Revised Text:
    Actions taken:
    September 21, 2010: received issue
    Proposed Disposition: Duplicate of 15453

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

There is a missing colon in 2d. The last line should be (2h:FeatureAttrib)*

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

    There is a missing colon in 2d. The last line should be (2h:FeatureAttrib)*

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

    As per the issue

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

The example in Issue 9645 doesn't seem like a particularly good one

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

    The example in Issue 9645 doesn't seem like a particularly good one. I would expect the URI for UseCase to be something like:

    http://www.omg.org/spec/UML/20100901/uml.xml#UseCase

  • Reported: XMI 2.4 — Wed, 6 Oct 2010 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    Make the fix suggested in the issue

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

There was an error in the example in Issue 9626

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

    There was an error in the example in Issue 9626:

    Operation is a subclass of Element, not ModelElement. ModelElements no longer exist.

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

    Make the fix suggested in the issue

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

MOF 2.4 references missing

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

    The version of MOF serialized is referenced in the Scope, Section1 - but should also be in Normative References. Both need updating to reference MOF 2.4.

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

    Add the reference in Normative References, but avoid duplicating it in Scope. Also re-introduce useful text for the Scope, based on wording from the XMI 1.3 formal document

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

Issue 9673 contained "file:Co.xml" which is an invalid absolute URI

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

    Issue 9673 contained "file:Co.xml" which is an invalid absolute URI as it doesn't contain the appropriate initial slashes.

    (See section 5.2 of http://www.ietf.org/rfc/rfc2396.txt part (3) for a comment on why relative URIs with a scheme aren't correct.) [PJR] OK

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

    Remove the file: from the example.

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

Resolution text to issue 9650 not consistent

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

    The resolution to Issue 9650 is supposed to be removing all traces of xmi:version. However, the final replacement paragraph contains the text "The xmi:version attribute is used to denote the start of XMI information"

    which clearly is not consistent with that aim.

    The resolution should also mention updates to the XMI document production rules 1c and 1d.

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

    Correct the inadvertent retention of the original text mentioning xmi:versio and remove production rules 1c and 1d completely

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

The replacement text from Issue 15307 for "If true, serialize...is as follows:" doesn't makes sense

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

    The replacement text from Issue 15307 for "If true, serialize...is as follows:" doesn't makes sense within the context of table 4.1 as it doesn't proceed to give an ordering. It only makes sense within the revised text section of the resolution itself.

    The text from the following addition to 5.2.1 needs to be included or reference made to it

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

    Make the fix

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