UMLR — Are two identical bound templates the same?

Consider: my general purpose library provides:

mylib::Aggregate<T>

My subsystems exploit this by drawing:

mysub1::Aggregate<T -> String>
mysub2::Aggregate<T -> String>

and my application integrates the subsystems by drawing

myapp::Aggregate<T -> String>

Since each of the three Aggregates of String have different packages, oops, it would seem that they are different types and so cannot be passed interchangeably between subsystems.

The above arises from the natural encoding of a graphical representation in which Aggregate<String> is drawn once per diagram/package and referenced many times. The package owns and so appropriates the shared type.

In contrast, textual representations, in the absence of a typedef, elaborate Aggregate<String> for each reference. Each reference 'owns' the shared type, which is not appropriated by a prevailing package.

(This has been a major problem for attempts to provide UML-aligned XMI serialization for OCL since e.g. there is obviously only one Set(String) but who owns it, who persists it, and how is it referenced? Eclipse OCL has prototyped a solution whereby a shared orphanage package is responsible for owning the singletons, but everyone persists their singletons. This incurs unpleasant costs in creating local orphanages during a serialization and destroying them again during loading. Struggling with this finally made me see that there is a fundamental UML limitation.)

In similar scenarios where there is an ownership/reference dilemma, UML provides e.g. TemplateParameter::parameteredElement/ownedParameteredElement. Surely there should be a TypedElement::type/ownedType so that a TypedElement::ownedType can introduce a package-less type that is consequently shared by all similar introductions? Bloat could be avoided by one TypedElement::type referencing another TypedElement::ownedType. Alternatively a Package::sharedElements could contain local copies that are logically shared globally. (This could also solve the problem of everyone wanting their own Boolean PrimitiveType.)