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

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