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.

4) "3.6.4 Inheritance Specification" should go after "3.6.5 Attribute
Specification" because uses attribute concepts explained in 3.6.5.

There are several problems related to the specification of Association
elements (representing Links).

1) At the moment Association elements are only generated in DTDs/Schemas for
referenceless associations.
This precludes the use of Association instances in XMI files to link
existing/external objects: a technique I have certainly found useful even
when those objects do have references. There seems to be little reason for
not generating the Association elements.

2) The description of DTD design principles in 3.6.6 refers to association
roles. Presuming this is intended to mean association ends, the text is not
accurate since the element name generated is based on the reference name for
the class which may differ from the association end name.

3) Section 3.6 does not mention the creation of Association elements even
for the existing referenceless Association case.

4) The DTD and document generation rules for Association elements are
unnecessarily heavyweight and inconsistent with the treatment of references
on classes. For example it does not make sense for an AssociationEnd element
to have the fixed xmi attributes; and it should be possible to dispense with
them completely: letting an Association element refer to the linked elements
using XML attributes. e.g. for association A with ends b and c, a link could
be represented as follows (b1 and c1 are xmi.id's): <A b=b1 c=c1 />).

The DTD's (01-04-03) for XMI 1.2 does not correspond to the specification of the xmi.version attribute (section 3.5.3). This makes it difficult to detect whether XMI 1.1 or 1.2 was used to export a UML model.

The example model encoding XML is invalid, according to the DTD that appears above it. It shows <Envelope.toAddress> and <Envelope.fromAddress> tags which are not as described in the DTD, instead of containing nested <Address> tags, as it should.

I found this confusing and in fact implemented code that handled parsing of erroneous constructs such as these because I thought I had misread the specification portions of the document. The error has been present since early versions of the XMI 1.1 specification.

3) In "3.6.5 Attribute Specification" on site 3.17.
There is:
<!ELEMENT a EMPTY >
<!ATTLIST c.a xmi.value (enum1 | enum2 | .) #REQUIRED >

Should be:
<!ELEMENT c.a EMPTY >
<!ATTLIST c.a xmi.value (enum1 | enum2 | .) #REQUIRED >

The same error repeated on next site, where should be:
<!ELEMENT c.a1 (#PCDATA | XMI.reference) *>
<!ELEMENT c.a2 EMPTY >
<!ATTLIST c.a2 xmi.value (true | false) #REQUIRED >

The same error repeated on bottom direct before note, where should be:
<!ELEMENT c.a EMPTY >
<!ATTLIST c.a xmi.value (enum1 | enum2 | .) #REQUIRED d >

1) In "3.6.1 Namespace Qualified XML Element Names" on site 3.15. An example
uses inheritance, what is explained later, we should find another example.

General question to "3.6.4 Inheritance Specification": Why we declare all
XML elements and XML attributes direct under class C0 declaration and not as
parameter entity named like:

<!ENTITY % C0.elem "C0.a0">
<!ENTITY % C0.ref "C0.r0">
<!ENTITY % C0.comp "C0.comp0">

<!ENTITY % "C0.attr
a0 CDATA #IMPLIED
a1 CDATA #IMPLIED
r0 CDATA #IMPLIED
r1 CDATA #IMPLIED
>

and then:
<!ELEMENT C0 (%C0.elem; | XMI.extension | %C0.ref; | %C0.comp*>
<!ATTLIST C0
%C0.attr;
%XMI.element.att;
%XMI.link.att;"
>

and for third subclass analogical:

<!ELEMENT C3
(%C0.elem; | %C1.elem; | %C2.elem | %C3.elem | XMI.extension |
%C0.ref; | %C1.ref; | %C2.ref; | %C3.ref |
%C0.comp | %C1.comp | %C2.comp | %C3.comp )*>

• >
  <!ATTLIST C3
  %C0.attr;
  %C1.attr;
  %C2.attr;
  %C3.attr;
  %XMI.element.att;
  %XMI.link.att;"
  >

Imagine how short would be the DTD of UML in such an format.

It can be even shorter if we declare only one entity for all subelements
like:

<!ENTITY % C0.elem "C0.a0 | C0.r0 | C0.comp0 | XMI.extension">
<!ENTITY % C1.elem "%C0.elem | ... my own elements without XMI.extension ...
">

and than any n-subclass:

<!ENTITY Cn "%C'n-1'.elem | ... my own elements without XMI.extension ...">
<!ELEMENT Cn (%Cn.elem*>

analogical implified form for ATTLIST is applicable, the last example could
be:

<!ENTITY Cn.attr "
%C'n-1'.attr
... my own elements without %XMI.element.att; and %XMI.link.att; ... ">
<!ATTLIST Cn
%Cn.attr;
>

This is a feature request for the XMI 2.1 RTF. (Does
it have a mailing list? I'm crossposting to the XML
Schema FTF in case that list is still alive.)

My base document is the proposed available specification
(ptc/02-06-03). (I did not find a later version.)

Section 2.10.2, "Linking" specifies that "the URI
reference must be of the form URI#id_value, where URI
locates the XML file containing the XML element to link
to, and id_value is the value of the XML element's XMI
id attribute."

I propose to add the feature that if the URI does not
contain a fragment, then the link is to the outermost
document element of the referenced file.

This is a common use case, and allows linking to a
document that was provided by someone else and not
annotated with values for the optional xmi:id attribute.

Therefore I propose to change the text in 2.10.2.1 (the
"Using the XMI href attribute to locate an XMI id" sub-
section):

The URI reference must be of the form URI#id_value,
where URI locates the XML file containing the XML
element to link to, and id_value is the value of
the XML element's XMI id attribute.

to

If the URI reference contains a fragment identifier
(as in URI#id_value), then the URI locates an XML
file, and the fragment identifier is used to locate
an XML element with the fragment identifier as its
XMI id attribute. If the URI reference does not
contain a fragment identifier, then the outermost
document element of the XML file is referenced.

And to change, in 2.10.2.2 (the "Using an XLink simple
link and XPointer bare name to locate an XMI id" sub-
section) likewise:

The value of xlink:href must again be a URI reference
of the form URI#id_value. In this case, id_value is
technically an XPointer bare name, but it looks just
like the id_value for the XMI href attribute.

to

The value of xlink:href must again be a URI reference,
which is evaluated as above. If the URI reference
contains a fragment identifier, which is then
technically an XPointer bare name, then the fragment
identifier is used to locate an XML element with the
fragment identifier as its XMI id attribute in the
referenced XML file. If the URI reference does not
contain a fragment identifier, then the outermost
document element of the XML file is referenced.

This is an urgent XMI 2.0 issue. All section and page numbers are against XMI 2.0 (formal/03-05-02).

Section 1.11 (page 1-26) introduces the org.omg.xmi.attribute and org.omg.xmi.element tags to drive schema and document production so that a MOF attribute becomes either an XML attribute or subelement (or both, if both tags are false).

Chapter 3 (XML Document Production) explicitly evaluates these tags, in rule 3g (page 3-6) or rule 5 (page 3-9).

However, chapter 2 (XML Schema Production) does not mention these tags at all, so they are ignored by the schema production rules. Therefore, an XML Schema that is produced using these rules always contains attribute and element definitions for each MOF attribute.

To avoid this ambiguity, rules 4i and 4j should only be executed if org.omg.xmi.element is false. Rules 4d and 4e should only be executed if org.omg.xmi.attribute is false.

2) In "3.6.4 Inheritance Specification" on site 3.17. What makes '%' in
first line of element declaration?:
<!ELEMENT % C1 (C0.a0 | C1.a1 | XMI.extension | C0.r0 | C1.r1 | C0.comp0 |
C1.comp1)* >