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.