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

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

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

see above

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

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

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

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

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

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

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

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

see below

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

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

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

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

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

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

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

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

see above

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

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

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

Add a type called Any to the XMI namespace

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

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

see above

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

see above

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

see above

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

Clarify.

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

See revised text

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

see above

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

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

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

see above

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

Clarify by adding text

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

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

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

see above

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

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

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

see above

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

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

see above

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

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

see above

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

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

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