Issue 15400: Nasty UML 2.x Issue - /qualifiedName is not unambiguous (uml2-rtf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Uncategorized Issue Severity: 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. Resolution: Revised Text: Actions taken: August 5, 2010: received issue Discussion: End of Annotations:===== ubject: Nasty UML 2.x Issue - /qualifiedName is not unambiguous Date: Thu, 5 Aug 2010 10:54:56 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nasty UML 2.x Issue - /qualifiedName is not unambiguous Thread-Index: Acs0x1Ce47yIAGSkQa6zEp2S3oWL5g== From: "Pete Rivett" To: , "Steve Cook" , "Maged Elaasar" , "Nicolas Rouquette" /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. Pete -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp From: "Rouquette, Nicolas F (316A)" To: Pete Rivett CC: "issues@omg.org" , Steve Cook , Maged Elaasar Date: Thu, 5 Aug 2010 20:24:56 -0700 Subject: Re: Nasty UML 2.x Issue - /qualifiedName is not unambiguous Thread-Topic: Nasty UML 2.x Issue - /qualifiedName is not unambiguous Thread-Index: Acs1FvG1PDqY30mnSCKscZyFxnu5lQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Pete, On Aug 5, 2010, at 10:54 AM, Pete Rivett wrote: /qualifiedName is not unambiguous Indeed, we should have caught this in the ballot 10 review for UML 2.4. 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. As the description of this query says, this is logical distinguishability of named elements within a namespace. It seems that we have the following options: - Remove the notion of type from isDistinguishableFrom and insist on the names being different This would break many things including most versions of UML 2.x because of the tacit convention we've been depending on for specifying the calculation of certain derived properties: C::/x : T -- a derived property typed by T. C::x() : T -- an operation of the same name that calculates the derived values of /x. I say tacit convention because this modeling idiom should have been documented in clause 6.4.1. FYI: the UML 2.4 infrastructure uses this idiom 18 times and the UML 2.4 superstructure 27 times. - 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) This would make UML behave quite differently than what many people are used to; ultimately, it doesn't solve the underlying issue. - 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 That's our only option at this point. Unambiguous identification of model elements is an important capability we need but it's a strategic issue. The issue pertains in particular to all unordered properties whose element types don't have a name or may not be named. For example: Namespace::ownedRule : Constraint[*] This one is particularly nasty because our specification document process assigns a number to these constraints, e.g., in 7.3.33: [1] If there is no name, or one of the containing namespaces has no name, there is no qualified name. [2] ... [3] ... How do we tell which constraint defined in UML::Namespace is really [1], [2], [3]? The only way we have to do this is to specifically point to it via, e.g., a stereotype application or a relationship with a particular constraint as the target. That is, the architecture of the UML makes a tacit assumption that "identifying" an element involves another element that explicit references the "identified" element. This is different than languages like OWL2 that provide each entity its own identifier value -- i.e., an IRI in OWL2 case. Note that in OWL2, the type system was carefully designed to allow the possibility that a given IRI may refer to different entities as long as they have distinct types, e.g., the OWL2 equivalent of C::/x and C::x() above would have the same IRI. Coincidentally, OWL2 calls this feature "metamodeling". - Nicolas. BTW the OCL for the derivation of /qualifiedName uses union() to construct it: however AFAIK this will not result in a String. Pete -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=yemz+Wy5sfR5+3rerfinESKNQGCv3d29BgT37lGd47c=; b=pn9ci/Ou8T3WydyDjfm9WAZC2gyVh0/lFf4/DRQOIcXAYjEcTapYyYSABiKvXD0IIa gnoa1mnFwHDxf3yVj0jGXmnr/6MF9Rhe6sa2eOPvNs3gTnRTo02zbkbHZP+jSr0H/Xpt LwHQ/Ygd/iDcW7njgJCBvfaE3v3CxQS2w06GU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=Y2APKgkbLTMgE3PcjeE4deywIeIqLlo9OzCEXPbdm/6njUjIOsin7CsA9ng7ZDH1AG G14fG9UIpmF1QDNw0NSE5rikDEcwOs1rXsTDvlANzFiY1UZbgPs6TGLWvGr4clzLJcAO Ui1Uv2YKZIOys/vSEFN5VQdUj6QJNz525McmE= Sender: bran.selic@gmail.com From: Bran Selic Date: Tue, 17 Aug 2010 22:16:07 -0400 X-Google-Sender-Auth: 2TZnziHHBO8ub-qp1ryjD-IH4ok Subject: Re: issue 15400 -- UML 2 RTF issue To: Pete Rivett Cc: uml2-rtf@omg.org Pete, On Tue, Aug 17, 2010 at 4:52 PM, Juergen Boldt wrote: It seems that we have the following options: - Remove the notion of type from isDistinguishableFrom and insist on the names being different [bvs] This is not an option, since many OO languages allow the same name to be shared among different model elements of the same type. For example, in C++ you can have a number of operations called "print" belonging to the same class (i.e., the same namespace), but with different parameter sets. - 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) [bvs] As the example aboveindicates, even the type/name combination may not be sufficient to distinguish two elements. So, this is not an option either. - 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 [bvs] Based on the above, this looks like the only practical solution. In fact, given the fact reality empty names are commonly used in modeling practice (it is highly useful not being forced to name every named element in a model while avoiding fake computer-generated names), I am surprised that the idea of qualified names being unambiguous was ever suggested. Cheers...Bran Date: Wed, 18 Aug 2010 09:46:52 +0100 From: Dave Hawkins User-Agent: Thunderbird 2.0.0.21 (X11/20090302) To: Bran Selic CC: Pete Rivett , uml2-rtf@omg.org Subject: Re: issue 15400 -- UML 2 RTF issue Bran Selic wrote: - 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) [bvs] As the example aboveindicates, even the type/name combination may not be sufficient to distinguish two elements. So, this is not an option either. Also, it's not just the leaf name that would need to have a type/name combination, it's the entire path. For example, a class and a package can be identically named and a class can have nested class members. So is A::B::C, package A::package B::class C or is it package A::class B::class C? We've actually implemented a solution in our tool for the non-operation case where we allow internal lookups using a qualified name in the form: /name:nsPrefix:metaclassName so for my previous example you might have /A:uml:Package/B:uml:Package/C:uml:Class However this hasn't been a terribly satisfactory solution, although that may be more to do with how we are using them than the form itself. Cheers, Dave -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.