UMLR — Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model

SysML 1.3 – http://www.omg.org/cgi-bin/doc?ptc/2011-08-10 – is defined as an extension of UML 2.4.1
What is the XMI serialization of applying the profile to a UML 2.4.1 Package?

The XMI serialization of the application of a profile in UML 2.4.1, section 18.3.7, was written at a time when UML2.0 required Stereotypes to be directly contained in a Profile. UML 2.3 relaxed this. According to the Stereotype semantics defined in UML 2.4.1 (18.3.9), a Stereotype may be contained in a Profile or a Package which defines the namespace for the Stereotype.

The XMI serialization in 18.3.7 is defined by a contrived example where a Stereotype is directly contained in its Profile (see Figs. 18.8, 18.9). SysML 1.3 has several nested packages (see Fig 4.3 in SysML 1.3) Neither UML 2.4.1 nor XMI 2.4.1 clearly address how the serialization of the application of Package-nested Stereotypes works.

For SysML 1.3, the XMI published for the SysML profile itself looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI xmlns:xmi="http://www.omg.org/spec/XMI/20110701"
xmlns:mofext="http://www.omg.org/spec/MOF/20110701"
xmlns:uml="http://www.omg.org/spec/UML/20110701">
<uml:Profile URI="http://www.omg.org/spec/SysML/20110919/SysML" xmi:type="uml:Profile"
xmi:id="OMG_SysML_20110919_SysML_0"
name="SysML"
visibility="public">
...
<packagedElement xmi:type="uml:Package" xmi:id="_OMG_SysML_20110919_SysML_Blocks" name="Blocks">
...
<packagedElement xmi:type="uml:Stereotype" xmi:id="_OMG_SysML_20110919_SysML_Blocks-Block"
name="Block">
...
</packagedElement>
...
</packagedElement>
</uml:Profile>
<mofext:Tag xmi:type="mofext:Tag" xmi:id="OMG_SysML_20110919_SysML_2"
name="org.omg.xmi.nsPrefix"
value="SysML"
element="OMG_SysML_20110919_SysML_0"/>
</xmi:XMI>

Given the fact that, per the MOF/XMI 2.4.1 specification, only the toplevel UML Package Namespace maps to an XMI Document Namespace,
it follows that nested UML Package Namespaces have no corresponding XML Namespace declaration.

This means that SysML's Blocks Package cannot have any XML Namespace declaration per current MOF/XMI 2.4.1 rules.
Therefore, the only possible serialization for this example is the following:

<xmi:XMI
....
xmlns:SysML="http://www.omg.org/spec/SysML/20110919/SysML"
....
>
<uml:Package name="A" ........>
....
<packagedElement xmi:type="uml:Class" xmi:id="123" name="B"
....
</uml:Package>
....
<SysML:_OMG_SysML_20110919_SysML_Blocks-Block base_Class="123" xmi:id="456" ... />
....
</xmi:XMI>

This particular serialization may be surprising to some who might have expected:

<xmi:XMI
....
xmlns:SysML="http://www.omg.org/spec/SysML/20110919/SysML"
....
>
<uml:Package name="A" ........>
....
<packagedElement xmi:type="uml:Class" xmi:id="123" name="B"
....
</uml:Package>
....
<SysML:Block base_Class="123" xmi:id="456" ... />
....
</xmi:XMI>

The familiar-looking XMI serialization assumes that all UML CLassifiers in scope of a Profile have unique XMI:id values. The reason is very subtle but it is a consequence of the fact that the MOF/XMI specification maps only the toplevel UML Namespace into a corresponding XML Namespace declaration – i.e., a toplevel UML::Model/Package/Profile has a corresponding XML Namespace declaration & prefix; nested UML Namespaces do not!

This means that the UML Namespace distinguishability criteria that suffices for ensuring UML NamedElements are distinguishable within the same UML Namespace
is insufficient to guarantee that the XMI encoding of such UML NamedElements will be also distinguishable in the scope of their containing XML Namespace!

For SysML 1.3, I specifically used an unconventional XMI:id generation algorithm that encodes the fully qualified path (name/metatype/linearized collection order) of each UML Element so as to ensure that each XMI:id Element in the scope of an XMI document is distinguishable within that document.