-
Key: UMLR-233
-
Legacy Issue Number: 15400
-
Status: open
-
Source: Adaptive ( Mr. Pete Rivett)
-
Summary:
qualifiedName is not unambiguous
Section 7.3.33 states:
“A named element also has a qualified name that allows it to be unambiguously identified within a hierarchy of nested namespaces.” And the description of the property has: “A name that allows the NamedElement to be identified within a hierarchy of nested Namespaces.”
Constraint [2] describes the derivation of /qualifiedName which makes use of the names of the containing namespaces.
However the use of isDistinguishableFrom in the constraint for Namespace, which allows the names to be the same but the types different, means that the name alone may not unambiguously identify either the element or its namespaces.
It seems that we have the following options:
- Remove the notion of type from isDistinguishableFrom and insist on the names being different
- Somehow include the type/metaclass in the qualified name (which I think we can do without needing a qualified name for the type itself since UML has a flat namespace but it could cause problems for profiles or other metamodels)
- Drop the idea that the qualified name allows unambiguous identification. Which would be a shame. And might affect it being marked as
{id}
as per the recent issue resolution
BTW the OCL for the derivation of /qualifiedName uses union() to construct it: however AFAIK this will not result in a String.
-
Reported: UML 2.5 — Fri, 27 Jun 2014 11:17 GMT
-
Updated: Fri, 6 Mar 2015 20:57 GMT
UMLR — Nasty UML 2.x Issue - /qualifiedName is not unambiguous
- Key: UMLR-233
- OMG Task Force: UML 2.6 RTF