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

Canonical XMI, ptc/2013-08-28, states that xmi:uuid must be always present (B2, #5) except for values that are datatypes (B2, #7).
What does "values that are datatypes" in B2 #7 mean?

Are auxiliary XML elements like mofext:Tag and stereotype instances considered "values that are datatypes" ?

If not, then according to B2 #5, these auxiliary XML elements must have identification attributes (xmi:id and xmi:uuid).

Historically, the OMG used rather arbitrary conventions for producing the xmi:id of mofext:Tag — not a big deal because nobody really refers to them. However, these arbitrary conventions break the repeatability and reproducibility of Canonical XMI!

The Canonical XMI document production rules in B4 are incomplete: they should be augmented to specify the serialization, identification and ordering of auxiliary XML elements.

Consider augmenting the Canonical XMI specification B6 with the following rules:

Generate the xmi:id and xmi:uuid for mofext:Tag by appending "_mofext.Tag" to the xmi:id and xmi:uuid respectively of the referenced element.

Generate the xmi:id and xmi:uuid for stereotype instances by concatenating the xmi:id and xmi:uuid respectively of the stereotype with that of the element on which the stereotype is applied.

The subsection refers to documents [MOF2] and [UML2] which are not further specified in the document.

MOF/XMI defines the schemaType tag as follows: "The name of a datatype defined in the XML Schema Datatype specification."

First,the examples in the MOF/XMI specification and current use of this tag in OMG's XMI artifacts use datatype URIs, not datatype names.

Second, the definition of this tag is vague about which datatypes are allowed.

• The builtin datatypes explicitly defined in the XML Schema Datatype spec? http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#built-in-datatypes
• Any datatype defined in the "xs" namespace?

Consider for example "precision decimal", a datatype that is explicitly mentioned but not explicitly defined in the XML Schema Datatypes spec: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#primitive-vs-derived
This datatype is explicitly defined in a different specification but in the "xs" namespace: http://www.w3.org/TR/xsd-precisionDecimal/#precisionDecimal

This example illustrates the ambiguity of the scope as currently specified, that is, is "xs:precisionDecimal" allowed as a value for schemaType?

Third, even if schemaType were to be clarified to be some subset of datatypes defined in the "xs" namespace, there are legitimate business reasons to expect greater flexibility.

- Several OMG specifications define XSDs (e.g., BPMN, DTV, …) If these include XML Schema datatype definitions, why are we precluded from referring to them via a PrimitiveType that has a schemaType tag pointing to their URI?

• For working with RDF, it would make sense to define a PrimitiveType whose schemaType tag maps it to rdf:PlainLiteral — I.e., http://www.w3.org/TR/rdf-plain-literal/#Definition_of_the_rdf:PlainLiteral_Datatype
• Similarly, for OWL, it would make sense to define PrimitiveType that would be mapped to owl:Rational and owl:Real: http://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#Datatype_Maps

At the moment every metaclass has a XML element generated, allowing it to be the root of any interchange.

While this flexibility might be useful in some cases, it clogs up the XSD with elements that will never get used in practice.

Proposed resolution:

Define two boolean XMI Tags:

1. To define whether root elements should be restricted: org.omg.xmi.restrictRoots (defaults to true)

2. To mark classifiers (classes or associations) as being potential roots: org.omg.xmi.rootElement (defaults to false)

These examples in the XMI spec s have nothing to do with modeling but are related to Departments and stoplights.

Furthermore they do not show xmi:ids and xmi:types.

They should also illustrate some of the more sophisticated cases such as that introduced by Issue 16330.

Finally, the Figures in Section 9.4 are all labeled Figure 1

Metamodels do not necessarily use names compliant with XML syntax.

XMI should include a name transformation algorithm to convert names e.g. replace spaces by ‘_’

While for older versions of XML the concrete syntax for persisting UML models was given in DTD, for newer versions of XMI a related concrete syntax specification e.g. as XML Schema is missing (even if the syntax is described in ptc/2010-12-06). Pure syntax compliance tests for given XMI files cannot be performed.

MOF/UML does not require names of elements in a metamodel to be valid XML names.

Therefore the XMI spec should document a transformation to be applied to cope with spaces, punctuation etc to be used for XML element and attribute names.

3:Extension is only referenced from 1a. However it certainly should be valid within an XMIObjectElement.

(3:Extension)* should be added to 2a

This is intended to represent arbitrary XML elements which might be unrelated to XMI.

Use a comment rather than a numbered clause

2. Rule 4i in 5.2 has the following with only 2 options:

("type=’xsd:IDREFS’ use=’optional’/>"

Why not separate the use from the type and allow all 4 combinations e.g. for an optional single-valued attribute? Or a required multivalued one?

Allow all 4 options

Use of "xmi:" and //xmiPrefix// is inconsistent. 2e and 2f use the latter

even though 1f clearly specifies that xmi is the prefix. "xmi:" should

be used directly in 2e and 2f.

resolved

1b has been deleted, but it is still referenced from 2g, 2l and 3. I think

those should actually be:

2g:TypeAttribute ::= "xmi:type='" 2k:QName "'"

2l:LinkAttribute ::= "xmi:idref='" //refId// "'" | 2m:Link

3:Extension ::= "<xmi:extension xmi:type='xmi:Extension'"

(" extension='" // extender // "'")?

(" extenderID='" // extenderID // "'")?

">"

"</xmi:extension>"

Take the recommendation from the issue which corrects the resolution of issue 8438.

When 2n is used with 2j it is supposed to match the last part of schema production

rule 4i:

Is that even valid XML schema? It only allows a single anyURI so 2j

doesn't comply with it. However the description of 4i doesn't mention

it, nor does section 4.8.5 - Reference representation.

Issue 15453 identifies the same problem and removes the option to use a URI in 2j.

Revised Text:
Actions taken:
September 21, 2010: received issue
Proposed Disposition: Duplicate of 15453

There is a missing colon in 2d. The last line should be (2h:FeatureAttrib)*

As per the issue

The example in Issue 9645 doesn't seem like a particularly good one. I would expect the URI for UseCase to be something like:

http://www.omg.org/spec/UML/20100901/uml.xml#UseCase

Make the fix suggested in the issue

There was an error in the example in Issue 9626:

Operation is a subclass of Element, not ModelElement. ModelElements no longer exist.

Make the fix suggested in the issue

The version of MOF serialized is referenced in the Scope, Section1 - but should also be in Normative References. Both need updating to reference MOF 2.4.

Add the reference in Normative References, but avoid duplicating it in Scope. Also re-introduce useful text for the Scope, based on wording from the XMI 1.3 formal document

Issue 9673 contained "file:Co.xml" which is an invalid absolute URI as it doesn't contain the appropriate initial slashes.

(See section 5.2 of http://www.ietf.org/rfc/rfc2396.txt part (3) for a comment on why relative URIs with a scheme aren't correct.) [PJR] OK

Remove the file: from the example.

The resolution to Issue 9650 is supposed to be removing all traces of xmi:version. However, the final replacement paragraph contains the text "The xmi:version attribute is used to denote the start of XMI information"

which clearly is not consistent with that aim.

The resolution should also mention updates to the XMI document production rules 1c and 1d.

Correct the inadvertent retention of the original text mentioning xmi:versio and remove production rules 1c and 1d completely

The replacement text from Issue 15307 for "If true, serialize...is as follows:" doesn't makes sense within the context of table 4.1 as it doesn't proceed to give an ordering. It only makes sense within the revised text section of the resolution itself.

The text from the following addition to 5.2.1 needs to be included or reference made to it

Make the fix