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

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

Revised Text:

• none -

Disposition: Transferred to MOF RTF

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.