Section B.2
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.
The constraint should be made specific to where the composite property is itself the
one used for nesting
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.
This is taken care of in the resolution to issue 15610 which rewrites the new rule 3..
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
Make the change as suggested.
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>
/>" )*
Agreed. Accept in principle
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.
Make the change as suggested
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.
This needs to be addressed.
Annex B is only described as an agreement for OMG. Delete Annex B.
No Data Available
These references are informative. Put “(informative)” under the title.
Replace the title of Annex A, which current reads:
Annex A - References
with:
Annex A - Bibliography
Replace the contents of Annex A, which current reads:
[XML] XML, a technical recommendation standard of the W3C.
http://www.w3.org/TR/REC-xm.
[XML Schema] XML Schemas, a proposed recommendation of the W3C.
Primer: http://www.w3.org/TR/xmlschema-0/,
Structured types: http://www.w3.org/TR/xmlschema-1/
Data types: http://www.w3.org/TR/xmlschema-2/.
[NAMESP] Namespaces, a technical recommendation of the W3C.
http://www.w3.org/TR/REC-xml-names
[XLINK] XLinks, a working draft of the W3C.
http://www.w3.org/TR/WD-xlink and
http://www.w3.org/TR/NOTE-xlink-principles
[XPath] XPointer, technical recommendation of the W3C.
http://www.w3.org/TR/xpath
[UML] UML 2.0, an in progress standard of the OMG. More
specifically, this refers to the UML 2.0 Infrastructure
submission. See
http://www.omg.org/techprocess/meetings/schedule/UML_2.0_I
nfrastructure_RFP.html .
[MOF] MOF 2.0, an in progress standard of the OMG. More
specifically, thisrefers to the MOF 2.0 Core submission. See
http://www.omg.org/techprocess/meetings/schedule/MOF_2.0_
Core_RFP.html.
[XMI] XMI 2.0, an adopted standard of the OMG. http://www.omg.org
with:
[XLINK] "XML Linking Language (XLink) Version 1.0"
W3C Recommendation 27 June 2001
http://www.w3.org/TR/2001/REC-xlink-20010627/
[XPath] "XML Path Language (XPath)
Version 1.0" W3C Recommendation 16 November 1999
http://www.w3.org/TR/1999/REC-xpath-19991116
[UML1] "ISO/IEC 19501:2005 , Information Technology - Open Distributed
Processing - Unified Modeling Language (UML) Version 1.4.2"
[MOF1] "ISO/IEC 19502:2005 , Information technology - Meta Object Facility
(MOF)"
[XMI1] "ISO/IEC 19503:2005 , Information technology XML Metadate
Interchange (XMI)"
Clause “introduction” explains informative sentences usually. However, this clause explains an overview of XML Document Production. Change “introduction” to “general.”
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
Issue as XML Schema Inforset Model is informative. Delete it or move to an annex.
Replace the title of clause 9.2, which current reads:
9.2 Introduction
with:
9.2 Overview
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.
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">
This sub sub clause describes informative example only. Move to an annex.
Insert the following as a 1 sentence paragraph before the first paragraph of clause
7.10.3:
This sub clause is informative.
This sub sub clause describes informative example only. Move to an annex.
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.
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” .
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"/>
Other documents should be specified. Titles should be specified as referencing definitions.
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.
That definition is presented in Clause 8 rather than 7. Change Clause 7 to Clause 8.
No Data Available
Clause “Additional Information” is not needed. Delete this clause or move to an informative annex except as copyright.
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.
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 ...”
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.
"
ISO/IEC standards were not specified. MOF(ISO/IEC19502) and XMI(ISO/IEC19502)
MOF4.2 (ISO/IEC29505) should be considered
No Data Available
The statements are not for the Scope. The area or range of this standard should be stated clearly.
No Data Available
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”.
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
"
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”.
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
"
If “MOF 2 XMI” in a title means “MOF to XMI”, it is not adequate. Change the title if it means “to”.
Change the title, which current reads:
OMG MOF 2 XMI Mapping Specification
with:
Object Management Group - XML Metadata Interchange (XMI)
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.
No Data Available
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.
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
Category “Object Management Group” is not adequate for standards. Change to “Information technology – Object Management Group MOF 2 XMI Version 2.4.1”.
No Data Available
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.
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.
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.
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
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.
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
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”.
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.
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.
No Data Available
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.
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.
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.
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.
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 proposed change is not sufficiently detailed to be actionable..
Disposition: Close No Change
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.
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
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
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”).
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
No Data Available
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
No Data Available
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?
No Data Available
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.
agreed
( 6b: DataTypeContents |
"<xsd:any minOccurs=’0’ maxOccurs=’u
processContents=’" // ProcessCont
"’/>")?
Should be:
( 6b: DataTypeContents |
"<xsd:any minOccurs=’0’ maxOccurs=’unbounded’
processContents=’" // ProcessContents Value //
"’/>")?
agreed, accept proposal
"></xsd:choice></xsd:complexType></xsd:element>" ) )*
Should be:
"</xsd:choice></xsd:complexType></xsd:element>" ) )*
agreed
4f. ClassCompositions ::= ( "<xsd:element name=’" //Name of Reference// "’"
Should be:
4f. ClassCompositions ::= ( "<xsd:element name=’" //Name of Class-typed Property// "’"
agreed
( "<xsd:complexContent>"
"<xsd:extension base=’" 4a:ClassTypeName "’")?
( "</xsd:extension>"
"</xsd:complexContent>" )?
Should be:
( "<xsd:complexContent>" |
"<xsd:extension base=’" 4a:ClassTypeName "’")?
( "</xsd:extension>" |
"</xsd:complexContent>" )?
agreed
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:
Delete these attributes from the document and the XMI.xsd file.
Section 6, rule 2n: should remove the type/Qname preceding the URI this is never used for hrefs.
As proposed.
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
Explain that the XMIObjectElement syntax can be used, and refer to the earlier description from 8884
Section 6.5.2 nil=’true’ is only used if org.omg.xmi.includeNils = ‘true’
Clarify as proposed
Section 6.5.2 should state that “The value of an EnumerationLiteral is its name” (as opposed to an Enumeration ).
Replace as proposed.
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
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.
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.
Adapt the wording.
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
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.
Section 5.2.1, rule 5: Class Elements should only be included if the metaclass is non-abstract
Change as recommended
Section 4.11.3 needs to better clarify what happens if both element and attribute are both true as per 9675
As per suggestion. Also qualify the tag names.
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
These need to be reconciled with the serialize tag
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.
Remove the option as per the issue
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."
Add text as described below
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
Replace text as described below
4.11, table 4.1: 'complex' is repeated in the list of values for contentType
Delete text as described below.
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.
Replace text as described below.
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.
As proposed, extend the href attribute description and add the constraint
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"
Replace text as described below
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
Correct URI syntax in examples
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.
Agreed
4.10.2.1 should also mention the use of XML attributes representign class-typed properties in the metamodel
Rephrase section 4.10.2.1 to cover also class-typed properties
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."
Change as suggested
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.
Improve the text
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
Use long tag names, except in tables 4.1 and 4.2.
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.
Delete last bullet of section 4.10.1.
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.
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).
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.
The example in 4.12.4 has been updated in the resolution to 9632. The other 2 examples listed need updating.
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.
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
6.5.3 2nd row of table starts "As Association": this should be "An Association",
Replace text as described below
In Figure 4.2 the XMI model references Object (from MOF) which should be MOF::Element
Update Figure 4.2
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).
Modify text as described below.
The differencs section 4.5 should refer to 4.12 for how the differences are to be processed
Add text as described below
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).
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:
Disposition: Closed No Change
4.3.3: in the following sentence the word 'lax' should be bold. "The processContents attribute is lax,"
Bold the word lax in the text as described below.
3.1 refers to 'XML Production of XML Schema' which was the name of an RFP/submission but not a formal specification
Delete text as described below
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".
This compliance clause refers to things outside the scope of the MOF XMI Mapping.
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.
This is a duplicate of issue number 9293. Resolve with no change.
Disposition: Merged / Duplicate
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.
The issue is wrong: xmi:type was never required for link elements, and from XMI 2.4 it is not even allowed.
Revised Text:
Disposition: Closed No Change
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>
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).
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."
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.
5.2 rule 7: define 'Unreferenced Association' in MOF2 terms
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.
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.
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.
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?
Correct section 4.13.3
The tagged values "ordered", "processContents" and "valueSeperator" are missing in table 4.2
Insert the missing tags in table 4.2
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.
Replace text as described below
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
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:
Disposition: Closed No Change
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?
See resolution for Issue 9296.
Revised Text:
(See resolution for Issue 9296.)
Disposition: Closed Duplicate to 9296
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.
The XML Schema metamodel will be moved into the IMM specification when it is adopted.
Revised Text:
Disposition: Deferred
Section 7: the examples and rules use Attributes extensively not Properties
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
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.
Replace text as described below.
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
Handled by resolution to issue 9650 (deleting the version attribute)
Revised Text:
(See resolution to 9650)
Disposition: Closed Duplicate to 9650
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.
Superseded by the resolution for issue 9649
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.
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’
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>
The example is completely replaced by resolution of 9632.
Revised Text:
Disposition: Closed Duplicate, Resolved by 9632
4.11.7: the sentence "the validator would not recognized the additional attributes in Road and River" should use "recognize".
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.
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>>.
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
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.
Replace text as described below
4.11.7 contains several xsd:annotation elements which are neither required nor described as an option by the spec. They should be removed
Delete text as described below.
4.11.6, 4.11.7 has: schemaLocation="xmi20.xsd"
which is wrong for XMI 2.1.
Replace text as described below
4.11.3 is largely redundant with, and should be merged with, 4.11.5
Merge 4.11.3 (partially) into 4.11.5; correct table 4.2 in 4.11.5.
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
Namespace prefix is much better. All of the sections mentioned should be changed. Replace text as described below
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
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
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>
This is covered by the resolution for issue 9632.
Revised Text:
(see resolution for issue 9632)
Disposition: Closed Duplicate of 9632
4.11.7: the example should make clear whether this is a CMOF or EMOF metamodel
Add clarification this is EMOF
4.11.7 has: xmlns:xmi="http://www.omg.org/XMI" which is wrong
This has been fixed in the current version of the specification. Resolve with no change.
Disposition: Closed No Change
4.8.1 states "each tag in XML has its own namespace." which is not technically correct - 'naming context' would be btter than 'namespace'
Change as proposed
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
Clarify as proposed
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.
There is no “choice” the schema generator is obligated to use the URI specified by the mandatory org.omg.xmi.nsURI tag.
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"/>
This is a duplicate of issue 12859. Close no change.
Disposition: Merged / Duplicate
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.
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.
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.
The refID() function is from MOF 1.x and does no .longer exist in MOF 2.
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.
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
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.
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.
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.
The MOF Facility and Object Lifecycle specification provides detailed instructions how to generate URIs to be used as uuids.
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."
Add text as described below
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.
Delete text as described below
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
Add text as described below
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."
Delete the 7th paragraph in section 4.5.3, which currently begins with the words “The serialization of the XMI element ”.
.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.
Ignore the label.
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."
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."
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.
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.
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.
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
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."
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.
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>
Replace text as described below
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.
Duplicate issue.
Revised Text:
None
Disposition: Duplicate of 9653
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
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.”
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).
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
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.
The precise order is important for cases such as the textual comparison of model files
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.
This will break too many existing implementations. Close no change.
Disposition: Closed No Change
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
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:
Disposition: Closed No Change
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.
agreed
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"
Change as suggested
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.
XML does not support multiple inheritance and there is nothing we can do about it. Close no change.
Disposition: Closed No Change
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.
Remove Chapter 7.
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>
Resolved by the resolution to issue 8884.
Revised Text:
(see resolution to issue 8884)
Disposition: Closed Duplicate to issue 8884
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.
Resolution included in resolution to 8884. In addition, change the one sentence mentioned in the issue.
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).
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.
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?
Delete text as described below
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
Replace text as described below
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...".
Replace text as described below
4.8.2 states "By default, XMI produces schemas that ignore multiplicities also." This should refer to "XMI 2".
Change as proposed
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.
Since the top-level element is not necessarily the XMI element, replace “XMI” with “top level”.
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."
Replace text as described below
4.8.4 has "For properties whose types are primitive types (for example, string)". The last word should be String (capital S).
Replace text as described below
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)
Correct the example.
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
Extend the last sentence of the first paragraph in the spirit proposed
4.8.8 Should say "more control to the metamodeler" rather than "to the end user"
Section 4.8.9, not 4.8.8. Change as proposed.
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.
Add text as described below
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
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.
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
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:
Disposition: Closed No Change
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"."
This has already been resolved and completed in a previous RTF. Close no change.
Disposition: Closed No Change
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.
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.
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:
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.
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.
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.
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
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.
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:
Disposition: Closed No Change
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.
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
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?
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.
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 ?
Replace text as described below
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.
The RTF consider this as a valuable argument
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.
Delete text as described below
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.
This is a duplicate of issue number 10112. Resolve with no change.
Disposition: Merged / Duplicate
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.
Replace text as described below
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.
This proposed enhancement would break backward compatibility. Close no change.
Disposition: Closed No Change
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.
This issue was resolved in version 2.1.1. Close no change.
Disposition: Closed No Change
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.
(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:
Proposed Disposition: Closed No Change
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.
The subsection refers to documents [MOF2] and [UML2] which are not further specified in the document.
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?
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’.
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)
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
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
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 ‘_’
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.
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.
3:Extension is only referenced from 1a. However it certainly should be valid within an XMIObjectElement.
(3:Extension)* should be added to 2a