The title page of the document lists the following normative documents:

Normative Machine Consumable Files:
http://www.omg.org/spec/XMI/20131001/XMI.xsd
http://www.omg.org/spec/XMI/20131001/XMI-model.xmi

However, attempting to retrieve (for example) http://www.omg.org/spec/XMI/20131001/XMI.xsd returns HTTP redirect to https://www.omg.org/spec/XMI/20131001/XMI.xsd.
Attempt to retrieve https://www.omg.org/spec/XMI/20131001/XMI.xsd returns a 404.

Section B.2

• bullet 2 - smi:XMI should be xmi:XMI
• bullet 6 - smi:type should be xmi:type and smi:idref should be xmi:idref
  Section B.5.3
• second bullet - xmi:idreg should be xmi:idref

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

Table 9.4.1 states:

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

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

This rule is very bad for several reasons:

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

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

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

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

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

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

Suggest:

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

b) Provide examples for all three options

Table 9.4.1 states:

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

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

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

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

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

Table 9.4.1 states:

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

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

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

Suggest eliminating org.omg.xmi.flattenStructuredDatatypes.

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

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

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

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

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

The suspected bug is registered with MagicDraw

No Data Available

There is another bug in the XMI:

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

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

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

This bug seems prevalent throughout the MagicDraw XMI.

No Data Available

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

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

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

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

No Data Available

The document, which is about a mapping of MOF to XMI, does not define the initialisms MOF or XMI anywhere in the documents, either in Chapter 1 (Scope) or in a glossary, which does not exist in this document.

Chapter 1 starts with "XMI is a widely used interchange format..." and ends with "MOF is the foundation technology for describing metamodels..." but there is no mention of what the terms actually stand for, a significant omission in a formal document.

One may also question the use of "MOF 2 XMI" in the title. While "MOF2XMI" may be a common way to create a meta-abbreviation for a relationship between two concepts denoted by abbreviations, there is little justification to eschew the grammatically correct "MOF-to-XMI Mapping" (with hyphens or spaces) in the document title. Using the numeral "2" is actually ambiguous – does it mean "to" or does it refer to a version 2 of MOF?

Overall, this issue is more about casual editing than about correctness, but I believe it makes the specification weaker, editorially, than the usual OMG standard of documentation.

Make the change as suggested

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:

• <xsd:attribute ref="id"/>

• <xsd:attributeGroup ref="IdentityAttribs"/>
  <xsd:attributeGroup ref="LinkAttribs"/>
  <xsd:attribute name="type" type="xsd:QName" use="optional" form="qualified"/>

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:

• none-

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:

• none -

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:

• none -

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?