Issue 9637: metamodel for XML Schema
Issue 9698: Section 8
Issue 15452: XMI issue - root elements for XMI Schemas
Issue 15887: Name transformation
Issue 16257: XMI should include a name transformation algorithm to convert names e.g. replace spaces by ‘_’
Issue 16272: attributes which apply to model elements and do not make sense at the XMI element level:
Issue 16273: In the XML Schema production rules the following in rule 4 is missing the option separator |:
Issue 16274: Rule 4f still uses the word “Reference” instead of Class-typed Property
Issue 16275: Rule 4f has an extraneous “>”
Issue 16276: The rule for 6f has become corrupted
Issue 16277: The production rule for Associations should use sequence if the tag order is set to true
Issue 16331: XMI composite opposite constraint overly restrictive
Issue 16341: Revise XMI examples in 9.4
Issue 16889: Grammar for XML Schema - XMI 2.4 Beta
Issue 16890: Grammar for XML Schema - XMI XMI 2.1.1
Issue 17389: An XMIReferenceElement cannot be used for serializing a composite property
Issue 17718: The text should be reviewed for clarity and objectivity and then amended
Issue 17719: Section1: The intended scope of the standard is unclear
Issue 17720: Section 2.1 - delete
Issue 17721: Section 2.2.2
Issue 17722: Section 2.3.1
Issue 17723: Section 3 references
Issue 17724: Section 4
Issue 17725: Section 6 - delete clause
Issue 17726: Section 7.11.6: Move the example to an informative annex and delete the clause from its present position.
Issue 17727: Section 7.12
Issue 17728: Title page i
Issue 17729: Title page i: f “MOF 2 XMI” in a title means “MOF to XMI”, it is not adequate
Issue 17730: Foreword Page vii
Issue 17731: Foreword Page vii: Title of ISO/IEC DIS 195058 is different.
Issue 17732: Section 1 Scope: The statements are not for the Scope
Issue 17733: Section 2 Normative Reference: ISO/IEC standards were not specified
Issue 17734: Clause “Additional Information” is not needed.
Issue 17735: Section 7.1, 2nd Paragraph
Issue 17736: Section 3 Terms and Definitions
Issue 17737: Section 7.1, 3rd Paragraph
Issue 17738: Section 7.10.3
Issue 17739: Section 7.11.6
Issue 17740: Section 7.11.6: change type=”CitiMember” to type=”CitiFeature”
Issue 17741: Section 7.12.4
Issue 17742: Section 10
Issue 17743: Section 9.2: Change “introduction” to “general.”
Issue 17744: Annex A Page 73
Issue 17745: Annex B
Issue 9637: metamodel for XML Schema (mof2xmi-rtf)
Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
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
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.
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)
Proposed Disposition: Deferred
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.
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 ‘_’
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"/>
( "<xsd:complexContent>"
"<xsd:extension base=’" 4a:ClassTypeName "’")?
…
( "</xsd:extension>"
"</xsd:complexContent>" )?
Should be:
( "<xsd:complexContent>" |
"<xsd:extension base=’" 4a:ClassTypeName "’")?
…
( "</xsd:extension>" |
"</xsd:complexContent>" )?
4f. ClassCompositions ::= ( "<xsd:element name=’" //Name of Reference// "’" Should be: 4f. ClassCompositions ::= ( "<xsd:element name=’" //Name of Class-typed Property// "’"
"></xsd:choice></xsd:complexType></xsd:element>" ) )*
Should be:
"</xsd:choice></xsd:complexType></xsd:element>" ) )*
( 6b: DataTypeContents |
"<xsd:any minOccurs=’0’ maxOccurs=’u
processContents=’" // ProcessCont
"’/>")?
Should be:
( 6b: DataTypeContents |
"<xsd:any minOccurs=’0’ maxOccurs=’unbounded’
processContents=’" // ProcessContents Value //
"’/>")?
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.
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.
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
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
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
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
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.
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.
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.
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.
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”.
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.
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.
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.
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.
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.
Category “Object Management Group” is not adequate for standards. Change to “Information technology -- Object Management Group MOF 2 XMI Version 2.4.1”.
If “MOF 2 XMI” in a title means “MOF to XMI”, it is not adequate. Change the title if it means “to”.
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”.
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”.
The statements are not for the Scope. The area or range of this standard should be stated clearly.
ISO/IEC standards were not specified. MOF(ISO/IEC19502) and XMI(ISO/IEC19502) MOF4.2 (ISO/IEC29505) should be considered
Clause “Additional Information” is not needed. Delete this clause or move to an informative annex except as copyright.
That definition is presented in Clause 8 rather than 7. Change Clause 7 to Clause 8.
Other documents should be specified. Titles should be specified as referencing definitions.
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 ...”
This sub sub clause describes informative example only. Move to an annex.
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.
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” .
This sub sub clause describes informative example only. Move to an annex.
Issue as XML Schema Inforset Model is informative. Delete it or move to an annex.
Clause “introduction” explains informative sentences usually. However, this clause explains an overview of XML Document Production. Change “introduction” to “general.”
These references are informative. Put “(informative)” under the title.
Annex B is only described as an agreement for OMG. Delete Annex B.