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.