nestingPackage getting overwritten

[scinnamond]

A UML Package can have only 1 value for 'nestingPackage' (singular attribute) yet when we use MagicDraw to make a common package sharable, then use it in another package so we can easily reference its contents, e.g. classifiers, we get the below XMI example.
For the second artifact graph to be correct, the package href (href='common.mdxml#_16_0_1_1707042b_1306852862751_314490_803'), needs to be DE-referenced just like any other href, and the result linked into the element graph. But again
Package can have only 1 value for 'nestingPackage'.

One possible 'fix' might be to change fUML.Syntax.Classes.Kernel.Package implementation as below.
...
public class fUML.Syntax.Classes.Kernel.Package ...
...
if (packagedElement instanceof Package) {
this.nestedPackage.addValue((Package) packagedElement);
// prevents overwrite in the case where package is linked into
// another package hierarchy by means of href
if (((Package) packagedElement).nestingPackage == null)
((Package) packagedElement).nestingPackage = this;
}
...
}
//artifact 1
<packagedElement xmi:type='uml:Package' xmi:id='_16_0_1_1707042b_1306852051135_154213_364' name='org' visibility='public'>
<packagedElement xmi:type='uml:Package' xmi:id='_16_0_1_1707042b_1306852058245_627192_365' name='foo' visibility='public'>
<packagedElement xmi:type='uml:Package' xmi:id='_16_0_1_1707042b_1307362731083_734976_1893' name='test' visibility='public'>
<packagedElement xmi:type='uml:Package' xmi:id='_16_0_1_1707042b_1306852862751_314490_803' name='common' visibility='public'>
<packagedElement xmi:type='uml:Class' xmi:id='_16_0_1_1707042b_1306853514519_194257_909' name='PessimisticConcurrent' visibility='public' isAbstract='true'>
</packagedElement>
</packagedElement>
</packagedElement>
</packagedElement>
</packagedElement>

//artifact 2
<packagedElement xmi:type='uml:Package' xmi:id='_16_0_1_1707042b_1319633687467_756099_368' name='org1' visibility='public'>
<packagedElement xmi:type='uml:Package' xmi:id='_16_0_1_1707042b_1319633687482_30259_369' name='foo1' visibility='public'>
<packagedElement xmi:type='uml:Package' xmi:id='_16_0_1_1707042b_1319633687482_444742_370' name='test1' visibility='public'>
// this package can't have 2 parents
<packagedElement xmi:type='uml:Package' href='common.mdxml#_16_0_1_1707042b_1306852862751_314490_803'>
</packagedElement>
</packagedElement>
</packagedElement>
</packagedElement>

[scinnamond]

Ed just assigning you to get any feedback.

[seidewitz]

The MagicDraw module/shared package capability is non-standard. There is a definite need for a capability like this, and a number of tools provide something like it, but how it is done differs from tool to tool. The UML community at OMG realizes the need to address this in a standard way, but it remains largely an open issue right now.

However, every modeling element having at most one owning is fundamental to the structuring of metamodels in MOF, so I doubt that any standardized resolution to this issue will violate the ownership principle. Note also that even handling this as a special case for packages requires more than just dealing with nestingPackage, but also all the subsequently derived ownership attributes, including at least namespace and owner. And the semantic effect of this is not clear (it is probably not too bad for fUML, since packages don't really have execution semantics, but it would effect Alf semantics, since name resolution in Alf relies on the namespace structure).

So , all in all, I don't see that this non-standard feature can be readily accomodated in the reference implementation.

[scinnamond]

Was not at all suggesting that, e.g. a Package should have multiple owners. But that the Package href above is legal XMI and not seemingly tools specific, and since all hrefs are de-referenced during loading, the package owner (nestingPackage) gets overwritten. So it could be that 1.) Package hrefs or maybe all hrefs should be de-referenced only at run time and never actually linked into the element graph (?). I think we'd find many instances where this would not be practical at least for the RI. Consider Property Type hrefs for instance. Or 2.) just leave Package hrefs unresolved or 3.) just don't support Package hrefs in the RI at all.
Option 3.) would seem to imply that documents can't easily be re-used. But I need to research this more with tools other than MD, e.g. papyrus.

[seidewitz]

The package href in your example is legal XML, but it is NOT legal XMI, at least as of XMI 2.4.2 (the current formal standard). The Package::packagedElement property is composite, and the XMI spec requires that a composite property be serialized as a nested XML element, not as an href (see XMI spec subclause 9.4.1).

There will be a change to this in XMI 2.5 (whenever that finally comes out), to specifically allow serialization of composite properties as hrefs. But, even then, MOF (and UML) rules on composition will still require that a packaged element (package or otherwise) only be composed into one package. Thus, even in XMI 2.5, it would not be legal to have one XMI file that has the packaged element serialized as a nested XML element, with another XMI having a packagedElement href to the same element (as is the case in your example).

Further, note that the code for Package::addPackagedElement also sets the namespace and the owner of the packaged element, whether it is a package or not (this happens through the super.addOwnedMember call). So not also setting nestingPackage would be inconsistent, and would not prevent the ownership of the nested package from being changed anyway. And if the code was further changed to not do the call to addOwnedMember for a reference package, this would be very bad, because the semantic code assumes that all packaged elements are owned members (as required by the UML spec).

The bottom line is that what MagicDraw does to support its module mechanism is non-standard and can't be supported by a standard-compliant implementation of the UML abstract syntax metamodel. It is not the intent of fUML RI to be able to read all non-conformant, tool-specific variants of XMI. In some cases it is easy to work around tool quirks, but when the tool provides a significant capability that is known to be non-conformant (as in the MagicDraw module implementation), then it is up to the modeler to export a model to compliant XMI before using it in the RI (this can be done with MagicDraw).

Finally, the issue is not package hrefs as such. It is the use of hrefs for serializing composite properties. An href to a package for, say, a package import is completely OK, since this is not a composition relationship. On the other hand, using an href for the packagedElement property is generally not OK, whether the element being referenced is a package or something else.

So, I only see two possibilities for handling hrefs like the one in your example:

1. Detect that the property being serialized is a composite property (as defined in the UML abstract syntax metamodel), and reject the XMI as illegal.
2. De-reference the href as usual and establish a normal composite relationship, which means setting the ownership of the element (and all properties derived from this, like nestingPackage) in the same way as if the element had been serialized as nested XML rather than an href.

I prefer option 2, which I believe is what currently happens anyway, and which will be compliant with XMI 2.5. In the case of a MagicDraw module, it means that the ownership of the referenced package will effectively be changed to the package from which it is referenced. This is clearly not the intent from the point of view of MagicDraw, but that is a issue with the way that MagicDraw serializes such models to XMI, not with the RI.