Issue 16567: Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model (uml2-rtf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: 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. Resolution: Revised Text: Actions taken: September 27, 2011: received issue Discussion: End of Annotations:===== m: "Rouquette, Nicolas F (313K)" To: "issues@omg.org" CC: "uml-spec-simplification@omg.org" , "sysml-rtf@omg.org" , Tomas Juknevicius Date: Tue, 27 Sep 2011 08:57:04 -0700 Subject: Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model Thread-Topic: Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model Thread-Index: Acx9LhqU4DEF81ezRyqHbDWSmkYpsQ== 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 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8RFvKvB005377 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: ... ... ... ... 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: .... .... .... This particular serialization may be surprising to some who might have expected: .... .... .... 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. - Nicolas. X-Trusted-NM: yes Subject: Re: Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model From: Nerijus Jankevicius Date: Wed, 28 Sep 2011 08:38:54 -0500 Cc: "issues@omg.org" , "uml-spec-simplification@omg.org" , "sysml-rtf@omg.org" , Tomas Juknevicius To: "Rouquette, Nicolas F (313K)" X-Mailer: Apple Mail (2.1084) Nicolas, nsPrefix for SysML 1.2 profile is "sysml", not "SysML". Did we changed it in 1.3 ? Nerijus On Sep 27, 2011, at 10:57 AM, Rouquette, Nicolas F (313K) wrote: 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: .... .... .... This particular serialization may be surprising to some who might have expected: .... .... .... 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. - Nicolas. From: "Rouquette, Nicolas F (313K)" To: "issues@omg.org" CC: "uml-spec-simplification@omg.org" , "sysml-rtf@omg.org" , Tomas Juknevicius Date: Wed, 28 Sep 2011 07:18:35 -0700 Subject: Re: Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model Thread-Topic: Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model Thread-Index: Acx96YKGipfUYppfTJqoYRBCuMZC0Q== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized For SysML 1.3, nsPrefix="SysML" and the Package URI="http://www.omg.org/spec/SysML/20110919/SysML" Yes, the nsPrefix for an OMG normative profile follows the conventions specified in UML 2.4.1, section 18.3.7 where the nsPrefix for the Profile is the name of the Profile itself. Therefore, the nsPrefix for the SysML Profile in 1.3 is SysML because SysML 1.3 is based on UML 2.4.1. - Nicolas. On Sep 28, 2011, at 6:38 AM, Nerijus Jankevicius wrote: Nicolas, nsPrefix for SysML 1.2 profile is "sysml", not "SysML". Did we changed it in 1.3 ? Nerijus On Sep 27, 2011, at 10:57 AM, Rouquette, Nicolas F (313K) wrote: 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: .... .... .... This particular serialization may be surprising to some who might have expected: .... .... .... 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. - Nicolas. From: "Rouquette, Nicolas F (313K)" To: "issues@omg.org" CC: "uml-spec-simplification@omg.org" , "sysml-rtf@omg.org" , Tomas Juknevicius Date: Wed, 28 Sep 2011 07:42:06 -0700 Subject: Re: Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model Thread-Topic: Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model Thread-Index: Acx97Mv7GEFkGj7sQPeACqy1hAlKoQ== 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 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8SEja9c018280 This issue involves 2 parts: 1) A UML issue w.r.t. clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. 2) Adding Package URIs to each of SysML 1.3's nested Packages requires re-publishing the machine-readable artifacts for SysML 1.3. My previous analysis below is incorrect in that the XMI serialization of the application of a Stereotype refers to a Stereotype using its xmi:id instead of its name. For (1), the UML spec should clarify that: 1.1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[Container Package XML namespace prefix]:[Stereotype name]>" 1.2) The "[Container Package XML namespace prefix]" is the XML namespace prefix associated to the Package containing the definition of the applied Stereotype. That container Package may be the Profile itself or nested in the Profile. 1.3) In order for an XMI processor to create an XML namespace prefix for the container Package of a Stereotype applied to an Element, the container Package must define a URI that the XMI processor can alias to an XML namespace prefix. In particular, (1.3) above means that we have to produce new XMI artifacts for SysML 1.3 one more time to define a Package URI for each of SysML 1.3's nested Packages per Fig. 4.3. For example, the SysML::Blocks Package would need a URI as shown below: ... ... ... ... Since an XMI processor has to ensure that the XML namespace prefixes are unique within the scope of a given XML document, the actual XML namespace prefixes associated to SysML's Package URI and to SysML::Blocks's Package URI could be different than shown in the example below where SysML::Blocks::Block is applied to a Class B defined in a Package A: .... .... .... - Nicolas. On Sep 27, 2011, at 8:57 AM, Rouquette, Nicolas F (313K) wrote: > 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: > > > xmlns:mofext="http://www.omg.org/spec/MOF/20110701" > xmlns:uml="http://www.omg.org/spec/UML/20110701"> > xmi:id="_OMG_SysML_20110919_SysML__0" > name="SysML" > visibility="public"> > ... > > ... > name="Block"> > ... > > ... > > > name="org.omg.xmi.nsPrefix" > value="SysML" > element="_OMG_SysML_20110919_SysML__0"/> > > > 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: > > .... > xmlns:SysML="http://www.omg.org/spec/SysML/20110919/SysML" > .... > > > > .... > .... > > .... > > .... > > > This particular serialization may be surprising to some who might have expected: > > .... > xmlns:SysML="http://www.omg.org/spec/SysML/20110919/SysML" > .... > > > > .... > .... > > .... > > .... > > > 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. > > - Nicolas. > From: Ed Seidewitz To: "Rouquette, Nicolas F (313K)" CC: "uml-spec-simplification@omg.org" , "sysml-rtf@omg.org" , Tomas Juknevicius , "issues@omg.org" Date: Wed, 28 Sep 2011 10:51:04 -0400 Subject: RE: Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model Thread-Topic: Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model Thread-Index: Acx97Mv7GEFkGj7sQPeACqy1hAlKoQAARt7w Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.225]|10.1.50.225|outbound.mailprotector.net|0|0|0|new|ugly|0|0|0|0 X-Mailprotector-Results: null_ptr subject_50_chars subject_10_spaces clean X-Mailprotector-Score: 80 X-Mailprotector-IP-Analysis: 0, 10.1.50.225, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-14804-c X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8SEst65020656 Nicolas -- You should really submit this as two issues, since one needs to be handled by a UML FTF or RTF, while the other needs to be handled by the SysML RTF. -- Ed -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, September 28, 2011 10:42 AM To: issues@omg.org Cc: uml-spec-simplification@omg.org; sysml-rtf@omg.org; Tomas Juknevicius Subject: Re: Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model This issue involves 2 parts: 1) A UML issue w.r.t. clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. 2) Adding Package URIs to each of SysML 1.3's nested Packages requires re-publishing the machine-readable artifacts for SysML 1.3. My previous analysis below is incorrect in that the XMI serialization of the application of a Stereotype refers to a Stereotype using its xmi:id instead of its name. For (1), the UML spec should clarify that: 1.1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[Container Package XML namespace prefix]:[Stereotype name]>" 1.2) The "[Container Package XML namespace prefix]" is the XML namespace prefix associated to the Package containing the definition of the applied Stereotype. That container Package may be the Profile itself or nested in the Profile. 1.3) In order for an XMI processor to create an XML namespace prefix for the container Package of a Stereotype applied to an Element, the container Package must define a URI that the XMI processor can alias to an XML namespace prefix. In particular, (1.3) above means that we have to produce new XMI artifacts for SysML 1.3 one more time to define a Package URI for each of SysML 1.3's nested Packages per Fig. 4.3. For example, the SysML::Blocks Package would need a URI as shown below: ... ... ... ... Since an XMI processor has to ensure that the XML namespace prefixes are unique within the scope of a given XML document, the actual XML namespace prefixes associated to SysML's Package URI and to SysML::Blocks's Package URI could be different than shown in the example below where SysML::Blocks::Block is applied to a Class B defined in a Package A: .... .... .... - Nicolas. On Sep 27, 2011, at 8:57 AM, Rouquette, Nicolas F (313K) wrote: > 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: > > > xmlns:mofext="http://www.omg.org/spec/MOF/20110701" > xmlns:uml="http://www.omg.org/spec/UML/20110701"> > xmi:id="_OMG_SysML_20110919_SysML__0" > name="SysML" > visibility="public"> > ... > > ... > name="Block"> > ... > > ... > > > name="org.omg.xmi.nsPrefix" > value="SysML" > element="_OMG_SysML_20110919_SysML__0"/> > > > 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: > > .... > xmlns:SysML="http://www.omg.org/spec/SysML/20110919/SysML" > .... > > > > .... > .... > > .... > > .... > > > This particular serialization may be surprising to some who might have expected: > > .... > xmlns:SysML="http://www.omg.org/spec/SysML/20110919/SysML" > .... > > > > .... > .... > > .... > > .... > > > 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. > > - Nicolas. > From: "Rouquette, Nicolas F (313K)" To: "issues@omg.org" CC: "uml-spec-simplification@omg.org" , Tomas Juknevicius , "uml-rtf@omg.org" Date: Wed, 28 Sep 2011 10:25:31 -0700 Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Topic: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Index: Acx+A6DTPSSFuNelQHSJ21sg3Co/Ig== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8SHPHso012410 This is an issue for UML 2.4.1. In 18.3.7, the semantics for Profile incompletely describes how to "Use XMI to exhange Profiles" for the case where a "Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype." (18.3.9, Stereotype Semantics). The Semantics section in 18.3.7 is missing the important constraints explaining some of the principles for the XMI serialization of the application of a Profile. The following constraints are consistent with the semantics of Stereotype Package containment specified in 18.3.9. 1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[XML namespace prefix of the Package containing the applied Stereotype]:[applied Stereotype name]>" This is illustrated in the HomeExample profile in Fig. 18.8 whose Package URI, "http://HomeExample/20101201/HomeExample.xmi", is associated to the XML namespace prefix "HomeExample". Therefore, the application of the Stereotype HomeExample::Home serializes into an XML Element tag of the form: "" as shown in the example. The spec is missing an example where a Stereotype is contained in a Package that is nested in a Profile. SysML 1.3 can provide ample material for such an example. 2) An XMI serializer must include in an XMI document all the XML namespace prefix declarations corresponding to all the container Packages of all Stereotypes whose application to an Element is serialized in that XMI document. In some cases, this means that the XML namespace prefix used for a particular Package may be different than the convention used for OMG normative profiles (See UML 2.4.1, 18.3.7) where the nsPrefix is the name of the Profile. 3) The owning Package of each Stereotype must have a Package::URI specified so that an XMI processor can: - generate an XML namespace prefix for that Package when one of its contained Stereotypes is applied - resolve a reference to an applied Stereotype to the Package containing the definition of the Stereotype via the XML namespace prefix used for the containing Package URI. This can be specified in OCL2.3 as follows: context Stereotype inv StereotypeContainerPackageMustHaveURI: self.owningPackage.URI->notEmpty() 4) All the Stereotype-containing Packages in a Profile regardless of nesting must have distinct Package URIs. This can be specified in OCL2.3 as follows: context Profile inv StereotypeContainingPackagesMustHaveDistinctURIs: let pkgs : Set(Package) = self->closure(nestedPackage)->including(self) in let allURIs : Bag(String) = pkgs.URI in let uniqueURIs : Set(String) = allURIs->asSet() in allURIs->size() = uniqueURIs->size() 5) The OMG normative profile convention in 18.3.7 must be updated to provide a sensible nsPrefix for the XML namespace corresponding to a nested Package in a Profile. The conventions in 18.3.7 was written at a time when UML 2.0 allowed Stereotypes to be directly contained in a Profile. The conventions need to be updated to provide a sensible rule for generating the nsPrefix for a Package nested in a Profile. I suggest using the "."-concatenated sequence of names of the UML Namespaces from the Profile to the nested Package. For example, the SysML 1.3 Profile is named "SysML" and it defines a nested package "SysML::Blocks". The suggested nsPrefix for the UML Package SysML::Blocks would be "SysML.Blocks". This name is legal per the normative criteria for XML namespace prefix names (see: http://www.w3.org/TR/REC-xml/#NT-Name) - Nicolas. From: "Rouquette, Nicolas F (313K)" To: Juergen Boldt CC: Pete Adaptive , Ed Seidewitz , Burkhart Roger M , Conrad Bock , Sanford Friedenthal , Fredrick A Steiner , Tomas Juknevicius , Nerijus Jankevicius Date: Wed, 28 Sep 2011 10:35:35 -0700 Subject: Fwd: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Topic: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Index: Acx+BQvjPBooIj6NSyyOU/OSPMnz+A== 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 Juergen, Can you please assign a UML issue number to this? Ed suggested filing a separate issue for the XMI of the SysML 1.3 we published last week: http://www.omg.org/cgi-bin/doc?ptc/2011-08-11 I leave it up to the SysML RTF chairs to decide whether we need to file an issue for the missing Package::URIs in the published XMI for SysML 1.3 or handle this as an editorial/publication fix. Andrew made it clear though that we should treat anything that has an OMG document number as "written once & immutable thereafter". Therefore, we will need, at minimum, to publish the SysML 1.3 XMI artifacts under new document numbers. Since the SysML 1.3 inventory & spec document refer to the XMI artifacts by document number, we will need to republish these as well. Thanks Tomas for checking the details of the vendor-specific XMI issue I filed at NoMagic about profile-nested packages! Without your diligence, I would have missed the subtle flaws in the current XMI serialization process for applied profiles! - Nicolas. Begin forwarded message: From: "Rouquette, Nicolas F (313K)" Date: September 28, 2011 10:25:31 AM PDT To: "issues@omg.org" Cc: "uml-spec-simplification@omg.org" , Tomas Juknevicius , "uml-rtf@omg.org" Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. This is an issue for UML 2.4.1. In 18.3.7, the semantics for Profile incompletely describes how to "Use XMI to exhange Profiles" for the case where a "Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype." (18.3.9, Stereotype Semantics). The Semantics section in 18.3.7 is missing the important constraints explaining some of the principles for the XMI serialization of the application of a Profile. The following constraints are consistent with the semantics of Stereotype Package containment specified in 18.3.9. 1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[XML namespace prefix of the Package containing the applied Stereotype]:[applied Stereotype name]>" This is illustrated in the HomeExample profile in Fig. 18.8 whose Package URI, "http://HomeExample/20101201/HomeExample.xmi", is associated to the XML namespace prefix "HomeExample". Therefore, the application of the Stereotype HomeExample::Home serializes into an XML Element tag of the form: "" as shown in the example. The spec is missing an example where a Stereotype is contained in a Package that is nested in a Profile. SysML 1.3 can provide ample material for such an example. 2) An XMI serializer must include in an XMI document all the XML namespace prefix declarations corresponding to all the container Packages of all Stereotypes whose application to an Element is serialized in that XMI document. In some cases, this means that the XML namespace prefix used for a particular Package may be different than the convention used for OMG normative profiles (See UML 2.4.1, 18.3.7) where the nsPrefix is the name of the Profile. 3) The owning Package of each Stereotype must have a Package::URI specified so that an XMI processor can: - generate an XML namespace prefix for that Package when one of its contained Stereotypes is applied - resolve a reference to an applied Stereotype to the Package containing the definition of the Stereotype via the XML namespace prefix used for the containing Package URI. This can be specified in OCL2.3 as follows: context Stereotype inv StereotypeContainerPackageMustHaveURI: self.owningPackage.URI->notEmpty() 4) All the Stereotype-containing Packages in a Profile regardless of nesting must have distinct Package URIs. This can be specified in OCL2.3 as follows: context Profile inv StereotypeContainingPackagesMustHaveDistinctURIs: let pkgs : Set(Package) = self->closure(nestedPackage)->including(self) in let allURIs : Bag(String) = pkgs.URI in let uniqueURIs : Set(String) = allURIs->asSet() in allURIs->size() = uniqueURIs->size() 5) The OMG normative profile convention in 18.3.7 must be updated to provide a sensible nsPrefix for the XML namespace corresponding to a nested Package in a Profile. The conventions in 18.3.7 was written at a time when UML 2.0 allowed Stereotypes to be directly contained in a Profile. The conventions need to be updated to provide a sensible rule for generating the nsPrefix for a Package nested in a Profile. I suggest using the "."-concatenated sequence of names of the UML Namespaces from the Profile to the nested Package. For example, the SysML 1.3 Profile is named "SysML" and it defines a nested package "SysML::Blocks". The suggested nsPrefix for the UML Package SysML::Blocks would be "SysML.Blocks". This name is legal per the normative criteria for XML namespace prefix names (see: http://www.w3.org/TR/REC-xml/#NT-Name) - Nicolas. From: Ed Seidewitz To: "Rouquette, Nicolas F (313K)" , "issues@omg.org" CC: "uml-spec-simplification@omg.org" , Tomas Juknevicius , "uml-rtf@omg.org" Date: Wed, 28 Sep 2011 18:40:33 -0400 Subject: RE: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Topic: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Index: Acx+A6DTPSSFuNelQHSJ21sg3Co/IgAK5g4Q Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.225]|10.1.50.225|outbound.mailprotector.net|-0.982435|0.877905|0|white|ugly|4966|44|0|0 X-Mailprotector-Results: null_ptr subject_50_chars subject_10_spaces clean X-Mailprotector-Score: 80 X-Mailprotector-IP-Analysis: 0, 10.1.50.225, Ugly c=0.877905 p=-0.982435 Source White X-Mailprotector-Scan-Diagnostics: 0-0-0-10231-c X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8SMeFEU015055 Nicolas -- It would seem simpler to just require that all the stereotypes in a profile have distinct names, whether they are directly owned by the profile or indirectly owned through a package within the profile. Then the current approach of profile nsPrefix plus stereotype name would be sufficient. And I don't think this would really be a serious restriction in practice, since packages are generally used organizationally in profiles, not to introduce namespaces to allow different stereotypes with the same name within the profile. -- Ed -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, September 28, 2011 1:26 PM To: issues@omg.org Cc: uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. This is an issue for UML 2.4.1. In 18.3.7, the semantics for Profile incompletely describes how to "Use XMI to exhange Profiles" for the case where a "Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype." (18.3.9, Stereotype Semantics). The Semantics section in 18.3.7 is missing the important constraints explaining some of the principles for the XMI serialization of the application of a Profile. The following constraints are consistent with the semantics of Stereotype Package containment specified in 18.3.9. 1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[XML namespace prefix of the Package containing the applied Stereotype]:[applied Stereotype name]>" This is illustrated in the HomeExample profile in Fig. 18.8 whose Package URI, "http://HomeExample/20101201/HomeExample.xmi", is associated to the XML namespace prefix "HomeExample". Therefore, the application of the Stereotype HomeExample::Home serializes into an XML Element tag of the form: "" as shown in the example. The spec is missing an example where a Stereotype is contained in a Package that is nested in a Profile. SysML 1.3 can provide ample material for such an example. 2) An XMI serializer must include in an XMI document all the XML namespace prefix declarations corresponding to all the container Packages of all Stereotypes whose application to an Element is serialized in that XMI document. In some cases, this means that the XML namespace prefix used for a particular Package may be different than the convention used for OMG normative profiles (See UML 2.4.1, 18.3.7) where the nsPrefix is the name of the Profile. 3) The owning Package of each Stereotype must have a Package::URI specified so that an XMI processor can: - generate an XML namespace prefix for that Package when one of its contained Stereotypes is applied - resolve a reference to an applied Stereotype to the Package containing the definition of the Stereotype via the XML namespace prefix used for the containing Package URI. This can be specified in OCL2.3 as follows: context Stereotype inv StereotypeContainerPackageMustHaveURI: self.owningPackage.URI->notEmpty() 4) All the Stereotype-containing Packages in a Profile regardless of nesting must have distinct Package URIs. This can be specified in OCL2.3 as follows: context Profile inv StereotypeContainingPackagesMustHaveDistinctURIs: let pkgs : Set(Package) = self->closure(nestedPackage)->including(self) in let allURIs : Bag(String) = pkgs.URI in let uniqueURIs : Set(String) = allURIs->asSet() in allURIs->size() = uniqueURIs->size() 5) The OMG normative profile convention in 18.3.7 must be updated to provide a sensible nsPrefix for the XML namespace corresponding to a nested Package in a Profile. The conventions in 18.3.7 was written at a time when UML 2.0 allowed Stereotypes to be directly contained in a Profile. The conventions need to be updated to provide a sensible rule for generating the nsPrefix for a Package nested in a Profile. I suggest using the "."-concatenated sequence of names of the UML Namespaces from the Profile to the nested Package. For example, the SysML 1.3 Profile is named "SysML" and it defines a nested package "SysML::Blocks". The suggested nsPrefix for the UML Package SysML::Blocks would be "SysML.Blocks". This name is legal per the normative criteria for XML namespace prefix names (see: http://www.w3.org/TR/REC-xml/#NT-Name) - Nicolas. From: "Rouquette, Nicolas F (313K)" To: Ed Seidewitz CC: "issues@omg.org" , "uml-spec-simplification@omg.org" , Tomas Juknevicius , "uml-rtf@omg.org" , "Jenkins, J Steven (3101)" Date: Wed, 28 Sep 2011 16:17:56 -0700 Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Topic: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Index: Acx+NNtx1X148tksTheO34NOvy99Fw== 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 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8SNHjhi018353 Ed, I strongly disagree with you. The UML Profile mechanism is already very constraining; the constraint you suggest would further restrict what we can do. The constraint would effectively mean that a Package nested in a Profile would have no semantic value whatsoever. The Package::URI attribute gives UML Packages a small but very useful semantics, that of denoting an identified namespace. It would be ironic that this very capability we need for the severely under-specified XMI serialization for the application of a Profile would be the very same capability that the constraint you suggest would remove! - Nicolas. On Sep 28, 2011, at 3:40 PM, Ed Seidewitz wrote: > Nicolas -- > > It would seem simpler to just require that all the stereotypes in a profile have distinct names, whether they are directly owned by the profile or indirectly owned through a package within the profile. Then the current approach of profile nsPrefix plus stereotype name would be sufficient. And I don't think this would really be a serious restriction in practice, since packages are generally used organizationally in profiles, not to introduce namespaces to allow different stereotypes with the same name within the profile. > > -- Ed > > -----Original Message----- > From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] > Sent: Wednesday, September 28, 2011 1:26 PM > To: issues@omg.org > Cc: uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org > Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. > > This is an issue for UML 2.4.1. > > In 18.3.7, the semantics for Profile incompletely describes how to "Use XMI to exhange Profiles" for the case where a "Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype." (18.3.9, Stereotype Semantics). > > The Semantics section in 18.3.7 is missing the important constraints explaining some of the principles for the XMI serialization of the application of a Profile. > The following constraints are consistent with the semantics of Stereotype Package containment specified in 18.3.9. > > 1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[XML namespace prefix of the Package containing the applied Stereotype]:[applied Stereotype name]>" > > This is illustrated in the HomeExample profile in Fig. 18.8 whose Package URI, "http://HomeExample/20101201/HomeExample.xmi", is associated to the XML namespace prefix "HomeExample". > Therefore, the application of the Stereotype HomeExample::Home serializes into an XML Element tag of the form: "" as shown in the example. > > The spec is missing an example where a Stereotype is contained in a Package that is nested in a Profile. > SysML 1.3 can provide ample material for such an example. > > 2) An XMI serializer must include in an XMI document all the XML namespace prefix declarations corresponding to all the container Packages of all Stereotypes whose application to an Element is serialized in that XMI document. > > In some cases, this means that the XML namespace prefix used for a particular Package may be different than the convention used for OMG normative profiles (See UML 2.4.1, 18.3.7) where the nsPrefix is the name of the Profile. > > 3) The owning Package of each Stereotype must have a Package::URI specified so that an XMI processor can: > > - generate an XML namespace prefix for that Package when one of its contained Stereotypes is applied > > - resolve a reference to an applied Stereotype to the Package containing the definition of the Stereotype via the XML namespace prefix used for the containing Package URI. > > This can be specified in OCL2.3 as follows: > > context Stereotype > inv StereotypeContainerPackageMustHaveURI: > self.owningPackage.URI->notEmpty() > > 4) All the Stereotype-containing Packages in a Profile regardless of nesting must have distinct Package URIs. > > This can be specified in OCL2.3 as follows: > > context Profile > inv StereotypeContainingPackagesMustHaveDistinctURIs: > let pkgs : Set(Package) = self->closure(nestedPackage)->including(self) in > let allURIs : Bag(String) = pkgs.URI in > let uniqueURIs : Set(String) = allURIs->asSet() in > allURIs->size() = uniqueURIs->size() > > 5) The OMG normative profile convention in 18.3.7 must be updated to provide a sensible nsPrefix for the XML namespace corresponding to a nested Package in a Profile. > > The conventions in 18.3.7 was written at a time when UML 2.0 allowed Stereotypes to be directly contained in a Profile. > The conventions need to be updated to provide a sensible rule for generating the nsPrefix for a Package nested in a Profile. > > I suggest using the "."-concatenated sequence of names of the UML Namespaces from the Profile to the nested Package. > For example, the SysML 1.3 Profile is named "SysML" and it defines a nested package "SysML::Blocks". > The suggested nsPrefix for the UML Package SysML::Blocks would be "SysML.Blocks". > This name is legal per the normative criteria for XML namespace prefix names (see: http://www.w3.org/TR/REC-xml/#NT-Name) > > > - Nicolas. From: Ed Seidewitz To: "Rouquette, Nicolas F (313K)" CC: "issues@omg.org" , "uml-spec-simplification@omg.org" , Tomas Juknevicius , "uml-rtf@omg.org" , "Jenkins, J Steven (3101)" Date: Wed, 28 Sep 2011 19:42:22 -0400 Subject: RE: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Topic: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Index: Acx+NNtx1X148tksTheO34NOvy99FwAAqXhA Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.225]|10.1.50.225|outbound.mailprotector.net|0|0|0|new|ugly|0|0|0|0 X-Mailprotector-Results: null_ptr subject_50_chars subject_10_spaces clean X-Mailprotector-Score: 80 X-Mailprotector-IP-Analysis: 0, 10.1.50.225, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-14360-c X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8SNg2q4020747 Nicolas -- The Package::URI attribute was added because to allow MOF 2.4 to be a strict subset of UML 2.4, because MOF packages can have URIs. You are widening its purpose for profile packages. Perhaps one could make a correspondence between profile subpackages and MOF packages (similar to the correspondence between stereotypes and MOF classes), but the current spec certainly does not make that correspondence. It is already pretty much always the case that the classes in metamodels have distinct names, whatever the packaging (at least after package merging is done). And I think the same is true of stereotypes in profiles. In fact, I think this is probably a good constraint, because having multiple stereotypes with the same name in the same profile is sure to be confusing. -- Ed -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, September 28, 2011 7:18 PM To: Ed Seidewitz Cc: issues@omg.org; uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Ed, I strongly disagree with you. The UML Profile mechanism is already very constraining; the constraint you suggest would further restrict what we can do. The constraint would effectively mean that a Package nested in a Profile would have no semantic value whatsoever. The Package::URI attribute gives UML Packages a small but very useful semantics, that of denoting an identified namespace. It would be ironic that this very capability we need for the severely under-specified XMI serialization for the application of a Profile would be the very same capability that the constraint you suggest would remove! - Nicolas. On Sep 28, 2011, at 3:40 PM, Ed Seidewitz wrote: > Nicolas -- > > It would seem simpler to just require that all the stereotypes in a profile have distinct names, whether they are directly owned by the profile or indirectly owned through a package within the profile. Then the current approach of profile nsPrefix plus stereotype name would be sufficient. And I don't think this would really be a serious restriction in practice, since packages are generally used organizationally in profiles, not to introduce namespaces to allow different stereotypes with the same name within the profile. > > -- Ed > > -----Original Message----- > From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] > Sent: Wednesday, September 28, 2011 1:26 PM > To: issues@omg.org > Cc: uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org > Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. > > This is an issue for UML 2.4.1. > > In 18.3.7, the semantics for Profile incompletely describes how to "Use XMI to exhange Profiles" for the case where a "Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype." (18.3.9, Stereotype Semantics). > > The Semantics section in 18.3.7 is missing the important constraints explaining some of the principles for the XMI serialization of the application of a Profile. > The following constraints are consistent with the semantics of Stereotype Package containment specified in 18.3.9. > > 1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[XML namespace prefix of the Package containing the applied Stereotype]:[applied Stereotype name]>" > > This is illustrated in the HomeExample profile in Fig. 18.8 whose Package URI, "http://HomeExample/20101201/HomeExample.xmi", is associated to the XML namespace prefix "HomeExample". > Therefore, the application of the Stereotype HomeExample::Home serializes into an XML Element tag of the form: "" as shown in the example. > > The spec is missing an example where a Stereotype is contained in a Package that is nested in a Profile. > SysML 1.3 can provide ample material for such an example. > > 2) An XMI serializer must include in an XMI document all the XML namespace prefix declarations corresponding to all the container Packages of all Stereotypes whose application to an Element is serialized in that XMI document. > > In some cases, this means that the XML namespace prefix used for a particular Package may be different than the convention used for OMG normative profiles (See UML 2.4.1, 18.3.7) where the nsPrefix is the name of the Profile. > > 3) The owning Package of each Stereotype must have a Package::URI specified so that an XMI processor can: > > - generate an XML namespace prefix for that Package when one of its contained Stereotypes is applied > > - resolve a reference to an applied Stereotype to the Package containing the definition of the Stereotype via the XML namespace prefix used for the containing Package URI. > > This can be specified in OCL2.3 as follows: > > context Stereotype > inv StereotypeContainerPackageMustHaveURI: > self.owningPackage.URI->notEmpty() > > 4) All the Stereotype-containing Packages in a Profile regardless of nesting must have distinct Package URIs. > > This can be specified in OCL2.3 as follows: > > context Profile > inv StereotypeContainingPackagesMustHaveDistinctURIs: > let pkgs : Set(Package) = self->closure(nestedPackage)->including(self) in > let allURIs : Bag(String) = pkgs.URI in > let uniqueURIs : Set(String) = allURIs->asSet() in > allURIs->size() = uniqueURIs->size() > > 5) The OMG normative profile convention in 18.3.7 must be updated to provide a sensible nsPrefix for the XML namespace corresponding to a nested Package in a Profile. > > The conventions in 18.3.7 was written at a time when UML 2.0 allowed Stereotypes to be directly contained in a Profile. > The conventions need to be updated to provide a sensible rule for generating the nsPrefix for a Package nested in a Profile. > > I suggest using the "."-concatenated sequence of names of the UML Namespaces from the Profile to the nested Package. > For example, the SysML 1.3 Profile is named "SysML" and it defines a nested package "SysML::Blocks". > The suggested nsPrefix for the UML Package SysML::Blocks would be "SysML.Blocks". > This name is legal per the normative criteria for XML namespace prefix names (see: http://www.w3.org/TR/REC-xml/#NT-Name) > > > - Nicolas. From: "Rouquette, Nicolas F (313K)" To: Ed Seidewitz CC: "issues@omg.org" , "uml-spec-simplification@omg.org" , Tomas Juknevicius , "uml-rtf@omg.org" , "Jenkins, J Steven (3101)" Date: Wed, 28 Sep 2011 22:46:04 -0700 Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Topic: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Index: Acx+axRxgnbmWXdcQAyHUu5Uv9N69w== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8T5jqMA016717 Ed, Global name uniqueness in the scope of a profile or a metamodel is a bad idea. For a metamodel, I hope it suffices to point out that a tool could implement the unmerged UML 2.4.1 superstructure or the merged UML 2.4.1 metamodel. Since the semantics of UML PackageMerge stipulate that the two should be equivalent, the unmerged UML 2.4.1 superstructure is as much a metamodel as the merged UML 2.4.1 package is a metamodel. The UML superstructure is certainly an example where having different concepts with identical names can be problematic; however, that doesn't mean its necessarily bad in all cases. The practice of UML metamodeling/profile development at the OMG is certainly not representative of the metamodeling/profile development practices outside the OMG. For a profile, I hope it suffices to point out that global name uniqueness for stereotypes would severely limit the extensibility of a profile -- once a name is used for defining a stereotype, that name couldn't be used for defining another stereotype in that profile even if it would be perfectly OK w.r.t. current UML namespace distinguishability rules. I believe the lure of global name uniqueness you allude to comes from the narrow view of the current UML notation which provides only two options: simple name or fully qualified name. This two-option notation is very unsatisfactory in many cases even without name collision because we can't tell which profile <> comes from when it is applied to an element. With colliding names, it's unsatisfactory within a profile and across profiles. For example, it is currently impossible to distinguish by current notation convention alone between SysML 1.3's TestCase vs. UTP 1.1's TestCase. The two concepts are very different but they are undistinguishable by notation alone, e.g.: <> A <> B We shouldn't use the flimsy excuse that the current notation for stereotype uses the simple name as an excuse for suggesting that stereotypes should have unique names in the scope of a profile. Finally, this idea is triply-bad because it would severely compromise the value of Package::URI added in UML 2.4.1. The value of this extension is that it allows us to make a strong correspondence between a UML package and arbitrary namespaces in the semantic web / world wide web. The suggestion that profiles, a special kind of package, would further impose an artificial global name uniqueness constraint that has no legitimate counterpart in practice provides is yet another factor to support my claim that this artificial constraint would be a very, very bad for UML. - Nicolas. On Sep 28, 2011, at 4:42 PM, Ed Seidewitz wrote: > Nicolas -- > > The Package::URI attribute was added because to allow MOF 2.4 to be a strict subset of UML 2.4, because MOF packages can have URIs. You are widening its purpose for profile packages. Perhaps one could make a correspondence between profile subpackages and MOF packages (similar to the correspondence between stereotypes and MOF classes), but the current spec certainly does not make that correspondence. > > It is already pretty much always the case that the classes in metamodels have distinct names, whatever the packaging (at least after package merging is done). And I think the same is true of stereotypes in profiles. In fact, I think this is probably a good constraint, because having multiple stereotypes with the same name in the same profile is sure to be confusing. > > -- Ed > > -----Original Message----- > From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] > Sent: Wednesday, September 28, 2011 7:18 PM > To: Ed Seidewitz > Cc: issues@omg.org; uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) > Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. > > Ed, > > I strongly disagree with you. > > The UML Profile mechanism is already very constraining; the constraint you suggest would further restrict what we can do. > The constraint would effectively mean that a Package nested in a Profile would have no semantic value whatsoever. > The Package::URI attribute gives UML Packages a small but very useful semantics, that of denoting an identified namespace. > It would be ironic that this very capability we need for the severely under-specified XMI serialization for the application of a Profile > would be the very same capability that the constraint you suggest would remove! > > - Nicolas. > > On Sep 28, 2011, at 3:40 PM, Ed Seidewitz wrote: > >> Nicolas -- >> >> It would seem simpler to just require that all the stereotypes in a profile have distinct names, whether they are directly owned by the profile or indirectly owned through a package within the profile. Then the current approach of profile nsPrefix plus stereotype name would be sufficient. And I don't think this would really be a serious restriction in practice, since packages are generally used organizationally in profiles, not to introduce namespaces to allow different stereotypes with the same name within the profile. >> >> -- Ed >> >> -----Original Message----- >> From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] >> Sent: Wednesday, September 28, 2011 1:26 PM >> To: issues@omg.org >> Cc: uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org >> Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >> >> This is an issue for UML 2.4.1. >> >> In 18.3.7, the semantics for Profile incompletely describes how to "Use XMI to exhange Profiles" for the case where a "Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype." (18.3.9, Stereotype Semantics). >> >> The Semantics section in 18.3.7 is missing the important constraints explaining some of the principles for the XMI serialization of the application of a Profile. >> The following constraints are consistent with the semantics of Stereotype Package containment specified in 18.3.9. >> >> 1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[XML namespace prefix of the Package containing the applied Stereotype]:[applied Stereotype name]>" >> >> This is illustrated in the HomeExample profile in Fig. 18.8 whose Package URI, "http://HomeExample/20101201/HomeExample.xmi", is associated to the XML namespace prefix "HomeExample". >> Therefore, the application of the Stereotype HomeExample::Home serializes into an XML Element tag of the form: "" as shown in the example. >> >> The spec is missing an example where a Stereotype is contained in a Package that is nested in a Profile. >> SysML 1.3 can provide ample material for such an example. >> >> 2) An XMI serializer must include in an XMI document all the XML namespace prefix declarations corresponding to all the container Packages of all Stereotypes whose application to an Element is serialized in that XMI document. >> >> In some cases, this means that the XML namespace prefix used for a particular Package may be different than the convention used for OMG normative profiles (See UML 2.4.1, 18.3.7) where the nsPrefix is the name of the Profile. >> >> 3) The owning Package of each Stereotype must have a Package::URI specified so that an XMI processor can: >> >> - generate an XML namespace prefix for that Package when one of its contained Stereotypes is applied >> >> - resolve a reference to an applied Stereotype to the Package containing the definition of the Stereotype via the XML namespace prefix used for the containing Package URI. >> >> This can be specified in OCL2.3 as follows: >> >> context Stereotype >> inv StereotypeContainerPackageMustHaveURI: >> self.owningPackage.URI->notEmpty() >> >> 4) All the Stereotype-containing Packages in a Profile regardless of nesting must have distinct Package URIs. >> >> This can be specified in OCL2.3 as follows: >> >> context Profile >> inv StereotypeContainingPackagesMustHaveDistinctURIs: >> let pkgs : Set(Package) = self->closure(nestedPackage)->including(self) in >> let allURIs : Bag(String) = pkgs.URI in >> let uniqueURIs : Set(String) = allURIs->asSet() in >> allURIs->size() = uniqueURIs->size() >> >> 5) The OMG normative profile convention in 18.3.7 must be updated to provide a sensible nsPrefix for the XML namespace corresponding to a nested Package in a Profile. >> >> The conventions in 18.3.7 was written at a time when UML 2.0 allowed Stereotypes to be directly contained in a Profile. >> The conventions need to be updated to provide a sensible rule for generating the nsPrefix for a Package nested in a Profile. >> >> I suggest using the "."-concatenated sequence of names of the UML Namespaces from the Profile to the nested Package. >> For example, the SysML 1.3 Profile is named "SysML" and it defines a nested package "SysML::Blocks". >> The suggested nsPrefix for the UML Package SysML::Blocks would be "SysML.Blocks". >> This name is legal per the normative criteria for XML namespace prefix names (see: http://www.w3.org/TR/REC-xml/#NT-Name) >> >> >> - Nicolas. > Date: Thu, 29 Sep 2011 12:23:30 +0100 From: Dave Hawkins User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0 To: "Rouquette, Nicolas F (313K)" CC: Ed Seidewitz , "issues@omg.org" , "uml-spec-simplification@omg.org" , Tomas Juknevicius , "uml-rtf@omg.org" , "Jenkins, J Steven (3101)" Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. X-Source-IP: ucsinet24.oracle.com [156.151.31.67] X-CT-RefId: str=0001.0A090204.4E845548.009E,ss=1,re=1.599,fgs=0 Nicolas, I agree with Ed here, I really don't see why constraining the names of all classifiers within a profile or metamodel to be unique is a problem. Certainly it's the way we're approaching the issue in JDeveloper. You seem to be trying to make things much more complicated than necessary. I agree this isn't explicit in the specification. However it's implicit from the schema production rules isn't it? I'm under the impression that elements within a schema have to be uniquely named, although I wasn't able to find that constraint in the XML Schema specification when I looked just now. For your UML metamodel example. The unmerged superstructure doesn't have a URI, so it isn't actually usable as a metamodel for XMI serialisation. The classifiers with the same names also all refer to fragments of the same classifier, so they aren't really distinct definitions from a serialization perspective. For a profile, I really don't see why a constraint on the name uniqueness within that profile is a severe limitation. It seems like a sensible restriction to me. It doesn't seem to cause any issues in the UML metamodel and I'd have thought that's larger than the majority of profiles. It also means that you can use short 'fully qualified' names unambiguously: <> <> Cheers, Dave On 29/09/11 06:46, Rouquette, Nicolas F (313K) wrote: Ed, Global name uniqueness in the scope of a profile or a metamodel is a bad idea. For a metamodel, I hope it suffices to point out that a tool could implement the unmerged UML 2.4.1 superstructure or the merged UML 2.4.1 metamodel. Since the semantics of UML PackageMerge stipulate that the two should be equivalent, the unmerged UML 2.4.1 superstructure is as much a metamodel as the merged UML 2.4.1 package is a metamodel. The UML superstructure is certainly an example where having different concepts with identical names can be problematic; however, that doesn't mean its necessarily bad in all cases. The practice of UML metamodeling/profile development at the OMG is certainly not representative of the metamodeling/profile development practices outside the OMG. For a profile, I hope it suffices to point out that global name uniqueness for stereotypes would severely limit the extensibility of a profile -- once a name is used for defining a stereotype, that name couldn't be used for defining another stereotype in that profile even if it would be perfectly OK w.r.t. current UML namespace distinguishability rules. I believe the lure of global name uniqueness you allude to comes from the narrow view of the current UML notation which provides only two options: simple name or fully qualified name. This two-option notation is very unsatisfactory in many cases even without name collision because we can't tell which profile<> comes from when it is applied to an element. With colliding names, it's unsatisfactory within a profile and across profiles. For example, it is currently impossible to distinguish by current notation convention alone between SysML 1.3's TestCase vs. UTP 1.1's TestCase. The two concepts are very different but they are undistinguishable by notation alone, e.g.: <> A <> B We shouldn't use the flimsy excuse that the current notation for stereotype uses the simple name as an excuse for suggesting that stereotypes should have unique names in the scope of a profile. Finally, this idea is triply-bad because it would severely compromise the value of Package::URI added in UML 2.4.1. The value of this extension is that it allows us to make a strong correspondence between a UML package and arbitrary namespaces in the semantic web / world wide web. The suggestion that profiles, a special kind of package, would further impose an artificial global name uniqueness constraint that has no legitimate counterpart in practice provides is yet another factor to support my claim that this artificial constraint would be a very, very bad for UML. - Nicolas. On Sep 28, 2011, at 4:42 PM, Ed Seidewitz wrote: Nicolas -- The Package::URI attribute was added because to allow MOF 2.4 to be a strict subset of UML 2.4, because MOF packages can have URIs. You are widening its purpose for profile packages. Perhaps one could make a correspondence between profile subpackages and MOF packages (similar to the correspondence between stereotypes and MOF classes), but the current spec certainly does not make that correspondence. It is already pretty much always the case that the classes in metamodels have distinct names, whatever the packaging (at least after package merging is done). And I think the same is true of stereotypes in profiles. In fact, I think this is probably a good constraint, because having multiple stereotypes with the same name in the same profile is sure to be confusing. -- Ed -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, September 28, 2011 7:18 PM To: Ed Seidewitz Cc: issues@omg.org; uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Ed, I strongly disagree with you. The UML Profile mechanism is already very constraining; the constraint you suggest would further restrict what we can do. The constraint would effectively mean that a Package nested in a Profile would have no semantic value whatsoever. The Package::URI attribute gives UML Packages a small but very useful semantics, that of denoting an identified namespace. It would be ironic that this very capability we need for the severely under-specified XMI serialization for the application of a Profile would be the very same capability that the constraint you suggest would remove! - Nicolas. On Sep 28, 2011, at 3:40 PM, Ed Seidewitz wrote: Nicolas -- It would seem simpler to just require that all the stereotypes in a profile have distinct names, whether they are directly owned by the profile or indirectly owned through a package within the profile. Then the current approach of profile nsPrefix plus stereotype name would be sufficient. And I don't think this would really be a serious restriction in practice, since packages are generally used organizationally in profiles, not to introduce namespaces to allow different stereotypes with the same name within the profile. -- Ed -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, September 28, 2011 1:26 PM To: issues@omg.org Cc: uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. This is an issue for UML 2.4.1. In 18.3.7, the semantics for Profile incompletely describes how to "Use XMI to exhange Profiles" for the case where a "Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype." (18.3.9, Stereotype Semantics). The Semantics section in 18.3.7 is missing the important constraints explaining some of the principles for the XMI serialization of the application of a Profile. The following constraints are consistent with the semantics of Stereotype Package containment specified in 18.3.9. 1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[XML namespace prefix of the Package containing the applied Stereotype]:[applied Stereotype name]>" This is illustrated in the HomeExample profile in Fig. 18.8 whose Package URI, "http://HomeExample/20101201/HomeExample.xmi", is associated to the XML namespace prefix "HomeExample". Therefore, the application of the Stereotype HomeExample::Home serializes into an XML Element tag of the form: "" as shown in the example. The spec is missing an example where a Stereotype is contained in a Package that is nested in a Profile. SysML 1.3 can provide ample material for such an example. 2) An XMI serializer must include in an XMI document all the XML namespace prefix declarations corresponding to all the container Packages of all Stereotypes whose application to an Element is serialized in that XMI document. In some cases, this means that the XML namespace prefix used for a particular Package may be different than the convention used for OMG normative profiles (See UML 2.4.1, 18.3.7) where the nsPrefix is the name of the Profile. 3) The owning Package of each Stereotype must have a Package::URI specified so that an XMI processor can: - generate an XML namespace prefix for that Package when one of its contained Stereotypes is applied - resolve a reference to an applied Stereotype to the Package containing the definition of the Stereotype via the XML namespace prefix used for the containing Package URI. This can be specified in OCL2.3 as follows: context Stereotype inv StereotypeContainerPackageMustHaveURI: self.owningPackage.URI->notEmpty() 4) All the Stereotype-containing Packages in a Profile regardless of nesting must have distinct Package URIs. This can be specified in OCL2.3 as follows: context Profile inv StereotypeContainingPackagesMustHaveDistinctURIs: let pkgs : Set(Package) = self->closure(nestedPackage)->including(self) in let allURIs : Bag(String) = pkgs.URI in let uniqueURIs : Set(String) = allURIs->asSet() in allURIs->size() = uniqueURIs->size() 5) The OMG normative profile convention in 18.3.7 must be updated to provide a sensible nsPrefix for the XML namespace corresponding to a nested Package in a Profile. The conventions in 18.3.7 was written at a time when UML 2.0 allowed Stereotypes to be directly contained in a Profile. The conventions need to be updated to provide a sensible rule for generating the nsPrefix for a Package nested in a Profile. I suggest using the "."-concatenated sequence of names of the UML Namespaces from the Profile to the nested Package. For example, the SysML 1.3 Profile is named "SysML" and it defines a nested package "SysML::Blocks". The suggested nsPrefix for the UML Package SysML::Blocks would be "SysML.Blocks". This name is legal per the normative criteria for XML namespace prefix names (see: http://www.w3.org/TR/REC-xml/#NT-Name) - Nicolas. -- 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. From: Ed Seidewitz To: "uml-spec-simplification@omg.org" , "uml-rtf@omg.org" CC: "issues@omg.org" , Tomas Juknevicius , "Jenkins, J Steven (3101)" Date: Thu, 29 Sep 2011 10:22:49 -0400 Subject: RE: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Topic: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Index: Acx+mkhl4TjWJSwbThGn5QvqNh02KQAF76tA Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.225]|10.1.50.225|outbound.mailprotector.net|0|0|0|new|ugly|0|0|0|0 X-Mailprotector-Results: null_ptr subject_50_chars subject_10_spaces clean X-Mailprotector-Score: 80 X-Mailprotector-IP-Analysis: 0, 10.1.50.225, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-27347-c X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8TEMlKB006388 There is also the issue of when we would be able to address the issue Nicolas has raised. I doubt there is going to be enough support to make this an urgent issue leading to UML 2.4.2. For what was supposed to be a stabilizing version before the spec simplification, UML 2.4 has seen enough churn as it is! We could certainly provide semantic clarification in UML 2.5. But if putting the new conventions for the use of profile package URIs into UML 2.5 would significantly change the interchange of models using profiles such as SysML. Without this guidance in UML 2.4, there will be no standard for tool vendors to follow and they will continue to use the current convention of :. Changing this in UML 2.5 would be a significant backward incompatibility in model interchange, which would violate the requirements of the RFP. So, I don't really see any other sensible course in UML 2.5 than to clarify that the stereotype names in a profile must all be distinct. This means adding an additional constraint that isn't in UML 2.4, but I don't think this will cause any problem with interchange backward compatibility, since the point of Nicolas' issue is that there isn't any standard way now anyway to handle stereotypes with the same name in different packages of a profile. I think it is still worth recording the issue as Nicolas proposes. Perhaps it can be discussed further in the UML 2.5 FTF. Or perhaps it is better to leave its resolution to be handled as part of submissions to the Metamodel Extension Facility RFP. -- Ed -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: Thursday, September 29, 2011 7:23 AM To: Rouquette, Nicolas F (313K) Cc: Ed Seidewitz; issues@omg.org; uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Nicolas, I agree with Ed here, I really don't see why constraining the names of all classifiers within a profile or metamodel to be unique is a problem. Certainly it's the way we're approaching the issue in JDeveloper. You seem to be trying to make things much more complicated than necessary. I agree this isn't explicit in the specification. However it's implicit from the schema production rules isn't it? I'm under the impression that elements within a schema have to be uniquely named, although I wasn't able to find that constraint in the XML Schema specification when I looked just now. For your UML metamodel example. The unmerged superstructure doesn't have a URI, so it isn't actually usable as a metamodel for XMI serialisation. The classifiers with the same names also all refer to fragments of the same classifier, so they aren't really distinct definitions from a serialization perspective. For a profile, I really don't see why a constraint on the name uniqueness within that profile is a severe limitation. It seems like a sensible restriction to me. It doesn't seem to cause any issues in the UML metamodel and I'd have thought that's larger than the majority of profiles. It also means that you can use short 'fully qualified' names unambiguously: <> <> Cheers, Dave On 29/09/11 06:46, Rouquette, Nicolas F (313K) wrote: > Ed, > > Global name uniqueness in the scope of a profile or a metamodel is a bad idea. > > For a metamodel, I hope it suffices to point out that a tool could implement the unmerged UML 2.4.1 superstructure or the merged UML 2.4.1 metamodel. Since the semantics of UML PackageMerge stipulate that the two should be equivalent, the unmerged UML 2.4.1 superstructure is as much a metamodel as the merged UML 2.4.1 package is a metamodel. > > The UML superstructure is certainly an example where having different concepts with identical names can be problematic; however, that doesn't mean its necessarily bad in all cases. > The practice of UML metamodeling/profile development at the OMG is certainly not representative of the metamodeling/profile development practices outside the OMG. > > For a profile, I hope it suffices to point out that global name uniqueness for stereotypes would severely limit the extensibility of a profile -- once a name is used for defining a stereotype, that name couldn't be used for defining another stereotype in that profile even if it would be perfectly OK w.r.t. current UML namespace distinguishability rules. > > I believe the lure of global name uniqueness you allude to comes from the narrow view of the current UML notation which provides only two options: simple name or fully qualified name. > This two-option notation is very unsatisfactory in many cases even without name collision because we can't tell which profile<> comes from when it is applied to an element. > With colliding names, it's unsatisfactory within a profile and across profiles. For example, it is currently impossible to distinguish by current notation convention alone between SysML 1.3's TestCase vs. UTP 1.1's TestCase. The two concepts are very different but they are undistinguishable by notation alone, e.g.: > > <> A > <> B > > We shouldn't use the flimsy excuse that the current notation for stereotype uses the simple name as an excuse for suggesting that stereotypes should have unique names in the scope of a profile. > > Finally, this idea is triply-bad because it would severely compromise the value of Package::URI added in UML 2.4.1. > The value of this extension is that it allows us to make a strong correspondence between a UML package and arbitrary namespaces in the semantic web / world wide web. > > The suggestion that profiles, a special kind of package, would further impose an artificial global name uniqueness constraint that has no legitimate counterpart in practice provides is yet another factor to support my claim that this artificial constraint would be a very, very bad for UML. > > - Nicolas. > > > > On Sep 28, 2011, at 4:42 PM, Ed Seidewitz wrote: > >> Nicolas -- >> >> The Package::URI attribute was added because to allow MOF 2.4 to be a strict subset of UML 2.4, because MOF packages can have URIs. You are widening its purpose for profile packages. Perhaps one could make a correspondence between profile subpackages and MOF packages (similar to the correspondence between stereotypes and MOF classes), but the current spec certainly does not make that correspondence. >> >> It is already pretty much always the case that the classes in metamodels have distinct names, whatever the packaging (at least after package merging is done). And I think the same is true of stereotypes in profiles. In fact, I think this is probably a good constraint, because having multiple stereotypes with the same name in the same profile is sure to be confusing. >> >> -- Ed >> >> -----Original Message----- >> From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] >> Sent: Wednesday, September 28, 2011 7:18 PM >> To: Ed Seidewitz >> Cc: issues@omg.org; uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) >> Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >> >> Ed, >> >> I strongly disagree with you. >> >> The UML Profile mechanism is already very constraining; the constraint you suggest would further restrict what we can do. >> The constraint would effectively mean that a Package nested in a Profile would have no semantic value whatsoever. >> The Package::URI attribute gives UML Packages a small but very useful semantics, that of denoting an identified namespace. >> It would be ironic that this very capability we need for the severely under-specified XMI serialization for the application of a Profile >> would be the very same capability that the constraint you suggest would remove! >> >> - Nicolas. >> >> On Sep 28, 2011, at 3:40 PM, Ed Seidewitz wrote: >> >>> Nicolas -- >>> >>> It would seem simpler to just require that all the stereotypes in a profile have distinct names, whether they are directly owned by the profile or indirectly owned through a package within the profile. Then the current approach of profile nsPrefix plus stereotype name would be sufficient. And I don't think this would really be a serious restriction in practice, since packages are generally used organizationally in profiles, not to introduce namespaces to allow different stereotypes with the same name within the profile. >>> >>> -- Ed >>> >>> -----Original Message----- >>> From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] >>> Sent: Wednesday, September 28, 2011 1:26 PM >>> To: issues@omg.org >>> Cc: uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org >>> Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >>> >>> This is an issue for UML 2.4.1. >>> >>> In 18.3.7, the semantics for Profile incompletely describes how to "Use XMI to exhange Profiles" for the case where a "Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype." (18.3.9, Stereotype Semantics). >>> >>> The Semantics section in 18.3.7 is missing the important constraints explaining some of the principles for the XMI serialization of the application of a Profile. >>> The following constraints are consistent with the semantics of Stereotype Package containment specified in 18.3.9. >>> >>> 1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[XML namespace prefix of the Package containing the applied Stereotype]:[applied Stereotype name]>" >>> >>> This is illustrated in the HomeExample profile in Fig. 18.8 whose Package URI, "http://HomeExample/20101201/HomeExample.xmi", is associated to the XML namespace prefix "HomeExample". >>> Therefore, the application of the Stereotype HomeExample::Home serializes into an XML Element tag of the form: "" as shown in the example. >>> >>> The spec is missing an example where a Stereotype is contained in a Package that is nested in a Profile. >>> SysML 1.3 can provide ample material for such an example. >>> >>> 2) An XMI serializer must include in an XMI document all the XML namespace prefix declarations corresponding to all the container Packages of all Stereotypes whose application to an Element is serialized in that XMI document. >>> >>> In some cases, this means that the XML namespace prefix used for a particular Package may be different than the convention used for OMG normative profiles (See UML 2.4.1, 18.3.7) where the nsPrefix is the name of the Profile. >>> >>> 3) The owning Package of each Stereotype must have a Package::URI specified so that an XMI processor can: >>> >>> - generate an XML namespace prefix for that Package when one of its contained Stereotypes is applied >>> >>> - resolve a reference to an applied Stereotype to the Package containing the definition of the Stereotype via the XML namespace prefix used for the containing Package URI. >>> >>> This can be specified in OCL2.3 as follows: >>> >>> context Stereotype >>> inv StereotypeContainerPackageMustHaveURI: >>> self.owningPackage.URI->notEmpty() >>> >>> 4) All the Stereotype-containing Packages in a Profile regardless of nesting must have distinct Package URIs. >>> >>> This can be specified in OCL2.3 as follows: >>> >>> context Profile >>> inv StereotypeContainingPackagesMustHaveDistinctURIs: >>> let pkgs : Set(Package) = self->closure(nestedPackage)->including(self) in >>> let allURIs : Bag(String) = pkgs.URI in >>> let uniqueURIs : Set(String) = allURIs->asSet() in >>> allURIs->size() = uniqueURIs->size() >>> >>> 5) The OMG normative profile convention in 18.3.7 must be updated to provide a sensible nsPrefix for the XML namespace corresponding to a nested Package in a Profile. >>> >>> The conventions in 18.3.7 was written at a time when UML 2.0 allowed Stereotypes to be directly contained in a Profile. >>> The conventions need to be updated to provide a sensible rule for generating the nsPrefix for a Package nested in a Profile. >>> >>> I suggest using the "."-concatenated sequence of names of the UML Namespaces from the Profile to the nested Package. >>> For example, the SysML 1.3 Profile is named "SysML" and it defines a nested package "SysML::Blocks". >>> The suggested nsPrefix for the UML Package SysML::Blocks would be "SysML.Blocks". >>> This name is legal per the normative criteria for XML namespace prefix names (see: http://www.w3.org/TR/REC-xml/#NT-Name) >>> >>> >>> - Nicolas. >> > -- 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. From: "Rouquette, Nicolas F (313K)" To: "uml-spec-simplification@omg.org" , "uml-rtf@omg.org" , "issues@omg.org" CC: Tomas Juknevicius , "Jenkins, J Steven (3101)" Date: Thu, 29 Sep 2011 09:43:26 -0700 Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Topic: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Index: Acx+xuqRI0LlYO5OQKSXWgMEpKIIgg== 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 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8TGhAkK025978 Yes, there is still the outstanding issue of clarifying how XMI serialization should work for profiles with nested packages. We currently have two proposals for solving this issue: a) add a constraint that, in the scope of a profile, stereotypes must have unique names regardless of their package container in that profile. This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" means that the Stereotype named [sname] must defined somewhere in the scope of the profile whose Package::URI is associated to [nsPrefix] b) add a constraint that each package containing a stereotype must have a Package::URI. This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" means that the Stereotype named [sname] must be defined as an owned type of the package whose Package::URI is associated to [nsPrefix] We need to discuss the pros/cons of each proposal. Either way, the specification will need clarifying language to: - explain how XMI serialization works for profiles with nested packages - improve the notation for UML stereotypes to show where a stereotype comes from. (a) may be simpler for a single profile and for some tools (e.g., JDeveloper and MagicDraw) but it is certainly not a scalable strategy. Consider this: Profile SysML4Testing imports SysML, UTP Now, I've got a name conflict due to SysML::Requirements::TestCase vs. UTP::TestCase Clearly, the UML specification needs to improve the notation for stereotypes to include qualifying information such as the name of the profile or the name of the container package. In practice, (a) shifts the burden of compliance to profile-scope name unicity to profile developers. For domain-specific language development with profiles, (a) is particularly annoying because we can't do simple things like this: Profile PF Stereotype PF::Electrical::Function Stereotype PF::Mechanical::Function Instead, (a) forces one to do something like this: Profile PF Stereotype PF::Electrical::Electrical.Function Stereotype PF::Mechanical::Mechanical.Function In tools that do (a) and only support the UML stereotype notation as specified, this can be a reasonable compromise, we get: <>, <>. In tools that do (a) but extend the UML stereotype notation to show the name of the profile, we get: <>, <>. Either way, nested packages have no useful purpose -- this completely defeats the purpose they were added in UML 2.3. With (b), UML namespace distinguishability is enough for everybody; some tool vendors may have to do work to support this flexible scheme. For profile developers, we don't have to distort domain-specific concepts, e.g., we can do: Profile PF Stereotype PF::Electrical::Function Stereotype PF::Mechanical::Function The only thing missing is extending the UML stereotype notation to provide options for including qualifying name information such as: - profile name + stereotype name - profile name + stereotype package container name + stereotype name - stereotype package container name + stereotype name - N-segments of the stereotype's fully qualified name from the left + M-segments of the stereotype's fully qualified name from the right - Nicolas. On Sep 29, 2011, at 7:22 AM, Ed Seidewitz wrote: > There is also the issue of when we would be able to address the issue Nicolas has raised. > > I doubt there is going to be enough support to make this an urgent issue leading to UML 2.4.2. For what was supposed to be a stabilizing version before the spec simplification, UML 2.4 has seen enough churn as it is! > > We could certainly provide semantic clarification in UML 2.5. But if putting the new conventions for the use of profile package URIs into UML 2.5 would significantly change the interchange of models using profiles such as SysML. Without this guidance in UML 2.4, there will be no standard for tool vendors to follow and they will continue to use the current convention of :. Changing this in UML 2.5 would be a significant backward incompatibility in model interchange, which would violate the requirements of the RFP. > > So, I don't really see any other sensible course in UML 2.5 than to clarify that the stereotype names in a profile must all be distinct. This means adding an additional constraint that isn't in UML 2.4, but I don't think this will cause any problem with interchange backward compatibility, since the point of Nicolas' issue is that there isn't any standard way now anyway to handle stereotypes with the same name in different packages of a profile. > > I think it is still worth recording the issue as Nicolas proposes. Perhaps it can be discussed further in the UML 2.5 FTF. Or perhaps it is better to leave its resolution to be handled as part of submissions to the Metamodel Extension Facility RFP. > > -- Ed > > -----Original Message----- > From: Dave Hawkins [mailto:dave.hawkins@oracle.com] > Sent: Thursday, September 29, 2011 7:23 AM > To: Rouquette, Nicolas F (313K) > Cc: Ed Seidewitz; issues@omg.org; uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) > Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. > > Nicolas, > > I agree with Ed here, I really don't see why constraining the > names of all classifiers within a profile or metamodel to be > unique is a problem. Certainly it's the way we're approaching > the issue in JDeveloper. You seem to be trying to make things > much more complicated than necessary. > > I agree this isn't explicit in the specification. However it's > implicit from the schema production rules isn't it? I'm under > the impression that elements within a schema have to be > uniquely named, although I wasn't able to find that constraint > in the XML Schema specification when I looked just now. > > For your UML metamodel example. The unmerged superstructure > doesn't have a URI, so it isn't actually usable as a metamodel > for XMI serialisation. The classifiers with the same names > also all refer to fragments of the same classifier, so they > aren't really distinct definitions from a serialization > perspective. > > For a profile, I really don't see why a constraint on the > name uniqueness within that profile is a severe limitation. > It seems like a sensible restriction to me. It doesn't > seem to cause any issues in the UML metamodel and I'd have > thought that's larger than the majority of profiles. It > also means that you can use short 'fully qualified' names > unambiguously: > <> > <> > > Cheers, > > Dave > > On 29/09/11 06:46, Rouquette, Nicolas F (313K) wrote: >> Ed, >> >> Global name uniqueness in the scope of a profile or a metamodel is a bad idea. >> >> For a metamodel, I hope it suffices to point out that a tool could implement the unmerged UML 2.4.1 superstructure or the merged UML 2.4.1 metamodel. Since the semantics of UML PackageMerge stipulate that the two should be equivalent, the unmerged UML 2.4.1 superstructure is as much a metamodel as the merged UML 2.4.1 package is a metamodel. >> >> The UML superstructure is certainly an example where having different concepts with identical names can be problematic; however, that doesn't mean its necessarily bad in all cases. >> The practice of UML metamodeling/profile development at the OMG is certainly not representative of the metamodeling/profile development practices outside the OMG. >> >> For a profile, I hope it suffices to point out that global name uniqueness for stereotypes would severely limit the extensibility of a profile -- once a name is used for defining a stereotype, that name couldn't be used for defining another stereotype in that profile even if it would be perfectly OK w.r.t. current UML namespace distinguishability rules. >> >> I believe the lure of global name uniqueness you allude to comes from the narrow view of the current UML notation which provides only two options: simple name or fully qualified name. >> This two-option notation is very unsatisfactory in many cases even without name collision because we can't tell which profile<> comes from when it is applied to an element. >> With colliding names, it's unsatisfactory within a profile and across profiles. For example, it is currently impossible to distinguish by current notation convention alone between SysML 1.3's TestCase vs. UTP 1.1's TestCase. The two concepts are very different but they are undistinguishable by notation alone, e.g.: >> >> <> A >> <> B >> >> We shouldn't use the flimsy excuse that the current notation for stereotype uses the simple name as an excuse for suggesting that stereotypes should have unique names in the scope of a profile. >> >> Finally, this idea is triply-bad because it would severely compromise the value of Package::URI added in UML 2.4.1. >> The value of this extension is that it allows us to make a strong correspondence between a UML package and arbitrary namespaces in the semantic web / world wide web. >> >> The suggestion that profiles, a special kind of package, would further impose an artificial global name uniqueness constraint that has no legitimate counterpart in practice provides is yet another factor to support my claim that this artificial constraint would be a very, very bad for UML. >> >> - Nicolas. >> >> >> >> On Sep 28, 2011, at 4:42 PM, Ed Seidewitz wrote: >> >>> Nicolas -- >>> >>> The Package::URI attribute was added because to allow MOF 2.4 to be a strict subset of UML 2.4, because MOF packages can have URIs. You are widening its purpose for profile packages. Perhaps one could make a correspondence between profile subpackages and MOF packages (similar to the correspondence between stereotypes and MOF classes), but the current spec certainly does not make that correspondence. >>> >>> It is already pretty much always the case that the classes in metamodels have distinct names, whatever the packaging (at least after package merging is done). And I think the same is true of stereotypes in profiles. In fact, I think this is probably a good constraint, because having multiple stereotypes with the same name in the same profile is sure to be confusing. >>> >>> -- Ed >>> >>> -----Original Message----- >>> From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] >>> Sent: Wednesday, September 28, 2011 7:18 PM >>> To: Ed Seidewitz >>> Cc: issues@omg.org; uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) >>> Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >>> >>> Ed, >>> >>> I strongly disagree with you. >>> >>> The UML Profile mechanism is already very constraining; the constraint you suggest would further restrict what we can do. >>> The constraint would effectively mean that a Package nested in a Profile would have no semantic value whatsoever. >>> The Package::URI attribute gives UML Packages a small but very useful semantics, that of denoting an identified namespace. >>> It would be ironic that this very capability we need for the severely under-specified XMI serialization for the application of a Profile >>> would be the very same capability that the constraint you suggest would remove! >>> >>> - Nicolas. >>> >>> On Sep 28, 2011, at 3:40 PM, Ed Seidewitz wrote: >>> >>>> Nicolas -- >>>> >>>> It would seem simpler to just require that all the stereotypes in a profile have distinct names, whether they are directly owned by the profile or indirectly owned through a package within the profile. Then the current approach of profile nsPrefix plus stereotype name would be sufficient. And I don't think this would really be a serious restriction in practice, since packages are generally used organizationally in profiles, not to introduce namespaces to allow different stereotypes with the same name within the profile. >>>> >>>> -- Ed >>>> >>>> -----Original Message----- >>>> From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] >>>> Sent: Wednesday, September 28, 2011 1:26 PM >>>> To: issues@omg.org >>>> Cc: uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org >>>> Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >>>> >>>> This is an issue for UML 2.4.1. >>>> >>>> In 18.3.7, the semantics for Profile incompletely describes how to "Use XMI to exhange Profiles" for the case where a "Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype." (18.3.9, Stereotype Semantics). > >>>> >>>> The Semantics section in 18.3.7 is missing the important constraints explaining some of the principles for the XMI serialization of the application of a Profile. >>>> The following constraints are consistent with the semantics of Stereotype Package containment specified in 18.3.9. >>>> >>>> 1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[XML namespace prefix of the Package containing the applied Stereotype]:[applied Stereotype name]>" >>>> >>>> This is illustrated in the HomeExample profile in Fig. 18.8 whose Package URI, "http://HomeExample/20101201/HomeExample.xmi", is associated to the XML namespace prefix "HomeExample". >>>> Therefore, the application of the Stereotype HomeExample::Home serializes into an XML Element tag of the form: "" as shown in the example. >>>> >>>> The spec is missing an example where a Stereotype is contained in a Package that is nested in a Profile. >>>> SysML 1.3 can provide ample material for such an example. >>>> >>>> 2) An XMI serializer must include in an XMI document all the XML namespace prefix declarations corresponding to all the container Packages of all Stereotypes whose application to an Element is serialized in that XMI document. >>>> >>>> In some cases, this means that the XML namespace prefix used for a particular Package may be different than the convention used for OMG normative profiles (See UML 2.4.1, 18.3.7) where the nsPrefix is the name of the Profile. >>>> >>>> 3) The owning Package of each Stereotype must have a Package::URI specified so that an XMI processor can: >>>> >>>> - generate an XML namespace prefix for that Package when one of its contained Stereotypes is applied >>>> >>>> - resolve a reference to an applied Stereotype to the Package containing the definition of the Stereotype via the XML namespace prefix used for the containing Package URI. >>>> >>>> This can be specified in OCL2.3 as follows: >>>> >>>> context Stereotype >>>> inv StereotypeContainerPackageMustHaveURI: >>>> self.owningPackage.URI->notEmpty() >>>> >>>> 4) All the Stereotype-containing Packages in a Profile regardless of nesting must have distinct Package URIs. >>>> >>>> This can be specified in OCL2.3 as follows: >>>> >>>> context Profile >>>> inv StereotypeContainingPackagesMustHaveDistinctURIs: >>>> let pkgs : Set(Package) = self->closure(nestedPackage)->including(self) in >>>> let allURIs : Bag(String) = pkgs.URI in >>>> let uniqueURIs : Set(String) = allURIs->asSet() in >>>> allURIs->size() = uniqueURIs->size() >>>> >>>> 5) The OMG normative profile convention in 18.3.7 must be updated to provide a sensible nsPrefix for the XML namespace corresponding to a nested Package in a Profile. >>>> >>>> The conventions in 18.3.7 was written at a time when UML 2.0 allowed Stereotypes to be directly contained in a Profile. >>>> The conventions need to be updated to provide a sensible rule for generating the nsPrefix for a Package nested in a Profile. >>>> >>>> I suggest using the "."-concatenated sequence of names of the UML Namespaces from the Profile to the nested Package. >>>> For example, the SysML 1.3 Profile is named "SysML" and it defines a nested package "SysML::Blocks". >>>> The suggested nsPrefix for the UML Package SysML::Blocks would be "SysML.Blocks". >>>> This name is legal per the normative criteria for XML namespace prefix names (see: http://www.w3.org/TR/REC-xml/#NT-Name) >>>> >>>> >>>> - Nicolas. >>> >> > > -- > 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. From: "Rouquette, Nicolas F (313K)" To: Kenn Hussey CC: "uml-rtf@omg.org" , "issues@omg.org" , Tomas Juknevicius , "Jenkins, J Steven (3101)" , "uml-spec-simplification@omg.org" Date: Thu, 29 Sep 2011 12:12:31 -0700 Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Topic: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Index: Acx+272FqMUAIU/5S2qDWbAtnuFcug== 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 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8TJCCVs011632 Ken, Given your experience in implementing UML2 at Eclipse, can you share your opinion on the issue below? - Nicolas. On Sep 29, 2011, at 9:43 AM, Rouquette, Nicolas F (313K) wrote: > Yes, there is still the outstanding issue of clarifying how XMI serialization should work for profiles with nested packages. > > We currently have two proposals for solving this issue: > > a) add a constraint that, in the scope of a profile, stereotypes must have unique names regardless of their package container in that profile. > > This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" means that the Stereotype named [sname] must defined somewhere in the scope of the profile whose Package::URI is associated to [nsPrefix] > > b) add a constraint that each package containing a stereotype must have a Package::URI. > > This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" means that the Stereotype named [sname] must be defined as an owned type of the package whose Package::URI is associated to [nsPrefix] > > We need to discuss the pros/cons of each proposal. > > Either way, the specification will need clarifying language to: > - explain how XMI serialization works for profiles with nested packages > - improve the notation for UML stereotypes to show where a stereotype comes from. > > (a) may be simpler for a single profile and for some tools (e.g., JDeveloper and MagicDraw) but it is certainly not a scalable strategy. > > Consider this: > > Profile SysML4Testing imports SysML, UTP > > Now, I've got a name conflict due to SysML::Requirements::TestCase vs. UTP::TestCase > Clearly, the UML specification needs to improve the notation for stereotypes to include qualifying information such as the name of the profile or the name of the container package. > > In practice, (a) shifts the burden of compliance to profile-scope name unicity to profile developers. > For domain-specific language development with profiles, (a) is particularly annoying because we can't do simple things like this: > > Profile PF > Stereotype PF::Electrical::Function > Stereotype PF::Mechanical::Function > > Instead, (a) forces one to do something like this: > > Profile PF > Stereotype PF::Electrical::Electrical.Function > Stereotype PF::Mechanical::Mechanical.Function > > In tools that do (a) and only support the UML stereotype notation as specified, this can be a reasonable compromise, we get: <>, <>. > In tools that do (a) but extend the UML stereotype notation to show the name of the profile, we get: <>, <>. > > Either way, nested packages have no useful purpose -- this completely defeats the purpose they were added in UML 2.3. > > With (b), UML namespace distinguishability is enough for everybody; some tool vendors may have to do work to support this flexible scheme. > > For profile developers, we don't have to distort domain-specific concepts, e.g., we can do: > > Profile PF > Stereotype PF::Electrical::Function > Stereotype PF::Mechanical::Function > > The only thing missing is extending the UML stereotype notation to provide options for including qualifying name information such as: > - profile name + stereotype name > - profile name + stereotype package container name + stereotype name > - stereotype package container name + stereotype name > - N-segments of the stereotype's fully qualified name from the left + M-segments of the stereotype's fully qualified name from the right > > - Nicolas. > > On Sep 29, 2011, at 7:22 AM, Ed Seidewitz wrote: > >> There is also the issue of when we would be able to address the issue Nicolas has raised. >> >> I doubt there is going to be enough support to make this an urgent issue leading to UML 2.4.2. For what was supposed to be a stabilizing version before the spec simplification, UML 2.4 has seen enough churn as it is! >> >> We could certainly provide semantic clarification in UML 2.5. But if putting the new conventions for the use of profile package URIs into UML 2.5 would significantly change the interchange of models using profiles such as SysML. Without this guidance in UML 2.4, there will be no standard for tool vendors to follow and they will continue to use the current convention of :. Changing this in UML 2.5 would be a significant backward incompatibility in model interchange, which would violate the requirements of the RFP. >> >> So, I don't really see any other sensible course in UML 2.5 than to clarify that the stereotype names in a profile must all be distinct. This means adding an additional constraint that isn't in UML 2.4, but I don't think this will cause any problem with interchange backward compatibility, since the point of Nicolas' issue is that there isn't any standard way now anyway to handle stereotypes with the same name in different packages of a profile. >> >> I think it is still worth recording the issue as Nicolas proposes. Perhaps it can be discussed further in the UML 2.5 FTF. Or perhaps it is better to leave its resolution to be handled as part of submissions to the Metamodel Extension Facility RFP. >> >> -- Ed >> >> -----Original Message----- >> From: Dave Hawkins [mailto:dave.hawkins@oracle.com] >> Sent: Thursday, September 29, 2011 7:23 AM >> To: Rouquette, Nicolas F (313K) >> Cc: Ed Seidewitz; issues@omg.org; uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) >> Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >> >> Nicolas, >> >> I agree with Ed here, I really don't see why constraining the >> names of all classifiers within a profile or metamodel to be >> unique is a problem. Certainly it's the way we're approaching >> the issue in JDeveloper. You seem to be trying to make things >> much more complicated than necessary. >> >> I agree this isn't explicit in the specification. However it's >> implicit from the schema production rules isn't it? I'm under >> the impression that elements within a schema have to be >> uniquely named, although I wasn't able to find that constraint >> in the XML Schema specification when I looked just now. >> >> For your UML metamodel example. The unmerged superstructure >> doesn't have a URI, so it isn't actually usable as a metamodel >> for XMI serialisation. The classifiers with the same names >> also all refer to fragments of the same classifier, so they >> aren't really distinct definitions from a serialization >> perspective. >> >> For a profile, I really don't see why a constraint on the >> name uniqueness within that profile is a severe limitation. >> It seems like a sensible restriction to me. It doesn't >> seem to cause any issues in the UML metamodel and I'd have >> thought that's larger than the majority of profiles. It >> also means that you can use short 'fully qualified' names >> unambiguously: >> <> >> <> >> >> Cheers, >> >> Dave >> >> On 29/09/11 06:46, Rouquette, Nicolas F (313K) wrote: >>> Ed, >>> >>> Global name uniqueness in the scope of a profile or a metamodel is a bad idea. >>> >>> For a metamodel, I hope it suffices to point out that a tool could implement the unmerged UML 2.4.1 superstructure or the merged UML 2.4.1 metamodel. Since the semantics of UML PackageMerge stipulate that the two should be equivalent, the unmerged UML 2.4.1 superstructure is as much a metamodel as the merged UML 2.4.1 package is a metamodel. >>> >>> The UML superstructure is certainly an example where having different concepts with identical names can be problematic; however, that doesn't mean its necessarily bad in all cases. >>> The practice of UML metamodeling/profile development at the OMG is certainly not representative of the metamodeling/profile development practices outside the OMG. >>> >>> For a profile, I hope it suffices to point out that global name uniqueness for stereotypes would severely limit the extensibility of a profile -- once a name is used for defining a stereotype, that name couldn't be used for defining another stereotype in that profile even if it would be perfectly OK w.r.t. current UML namespace distinguishability rules. >>> >>> I believe the lure of global name uniqueness you allude to comes from the narrow view of the current UML notation which provides only two options: simple name or fully qualified name. >>> This two-option notation is very unsatisfactory in many cases even without name collision because we can't tell which profile<> comes from when it is applied to an element. >>> With colliding names, it's unsatisfactory within a profile and across profiles. For example, it is currently impossible to distinguish by current notation convention alone between SysML 1.3's TestCase vs. UTP 1.1's TestCase. The two concepts are very different but they are undistinguishable by notation alone, e.g.: >>> >>> <> A >>> <> B >>> >>> We shouldn't use the flimsy excuse that the current notation for stereotype uses the simple name as an excuse for suggesting that stereotypes should have unique names in the scope of a profile. >>> >>> Finally, this idea is triply-bad because it would severely compromise the value of Package::URI added in UML 2.4.1. >>> The value of this extension is that it allows us to make a strong correspondence between a UML package and arbitrary namespaces in the semantic web / world wide web. >>> >>> The suggestion that profiles, a special kind of package, would further impose an artificial global name uniqueness constraint that has no legitimate counterpart in practice provides is yet another factor to support my claim that this artificial constraint would be a very, very bad for UML. >>> >>> - Nicolas. >>> >>> >>> >>> On Sep 28, 2011, at 4:42 PM, Ed Seidewitz wrote: >>> >>>> Nicolas -- >>>> >>>> The Package::URI attribute was added because to allow MOF 2.4 to be a strict subset of UML 2.4, because MOF packages can have URIs. You are widening its purpose for profile packages. Perhaps one could make a correspondence between profile subpackages and MOF packages (similar to the correspondence between stereotypes and MOF classes), but the current spec certainly does not make that correspondence. >>>> >>>> It is already pretty much always the case that the classes in metamodels have distinct names, whatever the packaging (at least after package merging is done). And I think the same is true of stereotypes in profiles. In fact, I think this is probably a good constraint, because having multiple stereotypes with the same name in the same profile is sure to be confusing. >>>> >>>> -- Ed >>>> >>>> -----Original Message----- >>>> From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] >>>> Sent: Wednesday, September 28, 2011 7:18 PM >>>> To: Ed Seidewitz >>>> Cc: issues@omg.org; uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) >>>> Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >>>> >>>> Ed, >>>> >>>> I strongly disagree with you. >>>> >>>> The UML Profile mechanism is already very constraining; the constraint you suggest would further restrict what we can do. >>>> The constraint would effectively mean that a Package nested in a Profile would have no semantic value whatsoever. >>>> The Package::URI attribute gives UML Packages a small but very useful semantics, that of denoting an identified namespace. >>>> It would be ironic that this very capability we need for the severely under-specified XMI serialization for the application of a Profile >>>> would be the very same capability that the constraint you suggest would remove! >>>> >>>> - Nicolas. >>>> >>>> On Sep 28, 2011, at 3:40 PM, Ed Seidewitz wrote: >>>> >>>>> Nicolas -- >>>>> >>>>> It would seem simpler to just require that all the stereotypes in a profile have distinct names, whether they are directly owned by the profile or indirectly owned through a package within the profile. Then the current approach of profile nsPrefix plus stereotype name would be sufficient. And I don't think this would really be a serious restriction in practice, since packages are generally used organizationally in profiles, not to introduce namespaces to allow different stereotypes with the same name within the profile. >>>>> >>>>> -- Ed >>>>> >>>>> -----Original Message----- >>>>> From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] >>>>> Sent: Wednesday, September 28, 2011 1:26 PM >>>>> To: issues@omg.org >>>>> Cc: uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org >>>>> Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >>>>> >>>>> This is an issue for UML 2.4.1. >>>>> >>>>> In 18.3.7, the semantics for Profile incompletely describes how to "Use XMI to exhange Profiles" for the case where a "Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype." (18.3.9, Stereotype Semantics). >> >>>>> >>>>> The Semantics section in 18.3.7 is missing the important constraints explaining some of the principles for the XMI serialization of the application of a Profile. >>>>> The following constraints are consistent with the semantics of Stereotype Package containment specified in 18.3.9. >>>>> >>>>> 1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[XML namespace prefix of the Package containing the applied Stereotype]:[applied Stereotype name]>" >>>>> >>>>> This is illustrated in the HomeExample profile in Fig. 18.8 whose Package URI, "http://HomeExample/20101201/HomeExample.xmi", is associated to the XML namespace prefix "HomeExample". >>>>> Therefore, the application of the Stereotype HomeExample::Home serializes into an XML Element tag of the form: "" as shown in the example. >>>>> >>>>> The spec is missing an example where a Stereotype is contained in a Package that is nested in a Profile. >>>>> SysML 1.3 can provide ample material for such an example. >>>>> >>>>> 2) An XMI serializer must include in an XMI document all the XML namespace prefix declarations corresponding to all the container Packages of all Stereotypes whose application to an Element is serialized in that XMI document. >>>>> >>>>> In some cases, this means that the XML namespace prefix used for a particular Package may be different than the convention used for OMG normative profiles (See UML 2.4.1, 18.3.7) where the nsPrefix is the name of the Profile. >>>>> >>>>> 3) The owning Package of each Stereotype must have a Package::URI specified so that an XMI processor can: >>>>> >>>>> - generate an XML namespace prefix for that Package when one of its contained Stereotypes is applied >>>>> >>>>> - resolve a reference to an applied Stereotype to the Package containing the definition of the Stereotype via the XML namespace prefix used for the containing Package URI. >>>>> >>>>> This can be specified in OCL2.3 as follows: >>>>> >>>>> context Stereotype >>>>> inv StereotypeContainerPackageMustHaveURI: >>>>> self.owningPackage.URI->notEmpty() >>>>> >>>>> 4) All the Stereotype-containing Packages in a Profile regardless of nesting must have distinct Package URIs. >>>>> >>>>> This can be specified in OCL2.3 as follows: >>>>> >>>>> context Profile >>>>> inv StereotypeContainingPackagesMustHaveDistinctURIs: >>>>> let pkgs : Set(Package) = self->closure(nestedPackage)->including(self) in >>>>> let allURIs : Bag(String) = pkgs.URI in >>>>> let uniqueURIs : Set(String) = allURIs->asSet() in >>>>> allURIs->size() = uniqueURIs->size() >>>>> >>>>> 5) The OMG normative profile convention in 18.3.7 must be updated to provide a sensible nsPrefix for the XML namespace corresponding to a nested Package in a Profile. >>>>> >>>>> The conventions in 18.3.7 was written at a time when UML 2.0 allowed Stereotypes to be directly contained in a Profile. >>>>> The conventions need to be updated to provide a sensible rule for generating the nsPrefix for a Package nested in a Profile. >>>>> >>>>> I suggest using the "."-concatenated sequence of names of the UML Namespaces from the Profile to the nested Package. >>>>> For example, the SysML 1.3 Profile is named "SysML" and it defines a nested package "SysML::Blocks". >>>>> The suggested nsPrefix for the UML Package SysML::Blocks would be "SysML.Blocks". >>>>> This name is legal per the normative criteria for XML namespace prefix names (see: http://www.w3.org/TR/REC-xml/#NT-Name) >>>>> >>>>> >>>>> - Nicolas. >>>> >>> >> >> -- >> 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. > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M9Sq6sBqKt1aJU4U4htMh6W9uoXCrvDQgzwpxgE8XJ4=; b=c+bZgMaQQoZLrbkNggb0gD9e2eaxFu7xvlWwWNeiGZjqAHaNjcAku9vETzCmm3Qz2w nNHroegv2yFp4R5faIdBf82cxsU/ON59elgG2ZqCR8CJtS8vECPD5cr0I2EPr0p2ZUqG oWjwrhteJ8fEcMZPBnX8rNnto8uNGEasL06V8= Date: Thu, 29 Sep 2011 15:27:56 -0400 Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. From: Kenn Hussey To: "Rouquette, Nicolas F (313K)" Cc: "uml-rtf@omg.org" , "issues@omg.org" , Tomas Juknevicius , "Jenkins, J Steven (3101)" , "uml-spec-simplification@omg.org" Sure. I prefer option (b), since that's the way EMF works - it assigns a namespace prefix and URI to every (nested) package (even if one hasn't been explicitly defined). This has already been implemented at Eclipse, for both dynamic and static profiles, in UML2 4.0 and seems to work fairly well. Note that, in case (b), the XMI tags for nsPrefix and nsURI would need to be serialized for any packages nested in a profile. Indeed, I think it's generally good practice to always serialize this information for a package (to aid in interchange)... Kenn On Thu, Sep 29, 2011 at 3:12 PM, Rouquette, Nicolas F (313K) wrote: Ken, Given your experience in implementing UML2 at Eclipse, can you share your opinion on the issue below? - Nicolas. On Sep 29, 2011, at 9:43 AM, Rouquette, Nicolas F (313K) wrote: > Yes, there is still the outstanding issue of clarifying how XMI serialization should work for profiles with nested packages. > > We currently have two proposals for solving this issue: > > a) add a constraint that, in the scope of a profile, stereotypes must have unique names regardless of their package container in that profile. > > This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" means that the Stereotype named [sname] must defined somewhere in the scope of the profile whose Package::URI is associated to [nsPrefix] > > b) add a constraint that each package containing a stereotype must have a Package::URI. > > This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" means that the Stereotype named [sname] must be defined as an owned type of the package whose Package::URI is associated to [nsPrefix] > > We need to discuss the pros/cons of each proposal. > > Either way, the specification will need clarifying language to: > - explain how XMI serialization works for profiles with nested packages > - improve the notation for UML stereotypes to show where a stereotype comes from. > > (a) may be simpler for a single profile and for some tools (e.g., JDeveloper and MagicDraw) but it is certainly not a scalable strategy. > > Consider this: > > Profile SysML4Testing imports SysML, UTP > > Now, I've got a name conflict due to SysML::Requirements::TestCase vs. UTP::TestCase > Clearly, the UML specification needs to improve the notation for stereotypes to include qualifying information such as the name of the profile or the name of the container package. > > In practice, (a) shifts the burden of compliance to profile-scope name unicity to profile developers. > For domain-specific language development with profiles, (a) is particularly annoying because we can't do simple things like this: > > Profile PF > Stereotype PF::Electrical::Function > Stereotype PF::Mechanical::Function > > Instead, (a) forces one to do something like this: > > Profile PF > Stereotype PF::Electrical::Electrical.Function > Stereotype PF::Mechanical::Mechanical.Function > > In tools that do (a) and only support the UML stereotype notation as specified, this can be a reasonable compromise, we get: <>, <>. > In tools that do (a) but extend the UML stereotype notation to show the name of the profile, we get: <>, <>. > > Either way, nested packages have no useful purpose -- this completely defeats the purpose they were added in UML 2.3. > > With (b), UML namespace distinguishability is enough for everybody; some tool vendors may have to do work to support this flexible scheme. > > For profile developers, we don't have to distort domain-specific concepts, e.g., we can do: > > Profile PF > Stereotype PF::Electrical::Function > Stereotype PF::Mechanical::Function > > The only thing missing is extending the UML stereotype notation to provide options for including qualifying name information such as: > - profile name + stereotype name > - profile name + stereotype package container name + stereotype name > - stereotype package container name + stereotype name > - N-segments of the stereotype's fully qualified name from the left + M-segments of the stereotype's fully qualified name from the right > > - Nicolas. > > On Sep 29, 2011, at 7:22 AM, Ed Seidewitz wrote: > >> There is also the issue of when we would be able to address the issue Nicolas has raised. >> >> I doubt there is going to be enough support to make this an urgent issue leading to UML 2.4.2. For what was supposed to be a stabilizing version before the spec simplification, UML 2.4 has seen enough churn as it is! >> >> We could certainly provide semantic clarification in UML 2.5. But if putting the new conventions for the use of profile package URIs into UML 2.5 would significantly change the interchange of models using profiles such as SysML. Without this guidance in UML 2.4, there will be no standard for tool vendors to follow and they will continue to use the current convention of :. Changing this in UML 2.5 would be a significant backward incompatibility in model interchange, which would violate the requirements of the RFP. >> >> So, I don't really see any other sensible course in UML 2.5 than to clarify that the stereotype names in a profile must all be distinct. This means adding an additional constraint that isn't in UML 2.4, but I don't think this will cause any problem with interchange backward compatibility, since the point of Nicolas' issue is that there isn't any standard way now anyway to handle stereotypes with the same name in different packages of a profile. >> >> I think it is still worth recording the issue as Nicolas proposes. Perhaps it can be discussed further in the UML 2.5 FTF. Or perhaps it is better to leave its resolution to be handled as part of submissions to the Metamodel Extension Facility RFP. >> >> -- Ed >> >> -----Original Message----- >> From: Dave Hawkins [mailto:dave.hawkins@oracle.com] >> Sent: Thursday, September 29, 2011 7:23 AM >> To: Rouquette, Nicolas F (313K) >> Cc: Ed Seidewitz; issues@omg.org; uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) >> Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >> >> Nicolas, >> >> I agree with Ed here, I really don't see why constraining the >> names of all classifiers within a profile or metamodel to be >> unique is a problem. Certainly it's the way we're approaching >> the issue in JDeveloper. You seem to be trying to make things >> much more complicated than necessary. >> >> I agree this isn't explicit in the specification. However it's >> implicit from the schema production rules isn't it? I'm under >> the impression that elements within a schema have to be >> uniquely named, although I wasn't able to find that constraint >> in the XML Schema specification when I looked just now. >> >> For your UML metamodel example. The unmerged superstructure >> doesn't have a URI, so it isn't actually usable as a metamodel >> for XMI serialisation. The classifiers with the same names >> also all refer to fragments of the same classifier, so they >> aren't really distinct definitions from a serialization >> perspective. >> >> For a profile, I really don't see why a constraint on the >> name uniqueness within that profile is a severe limitation. >> It seems like a sensible restriction to me. It doesn't >> seem to cause any issues in the UML metamodel and I'd have >> thought that's larger than the majority of profiles. It >> also means that you can use short 'fully qualified' names >> unambiguously: >> <> >> <> >> >> Cheers, >> >> Dave >> >> On 29/09/11 06:46, Rouquette, Nicolas F (313K) wrote: >>> Ed, >>> >>> Global name uniqueness in the scope of a profile or a metamodel is a bad idea. >>> >>> For a metamodel, I hope it suffices to point out that a tool could implement the unmerged UML 2.4.1 superstructure or the merged UML 2.4.1 metamodel. Since the semantics of UML PackageMerge stipulate that the two should be equivalent, the unmerged UML 2.4.1 superstructure is as much a metamodel as the merged UML 2.4.1 package is a metamodel. >>> >>> The UML superstructure is certainly an example where having different concepts with identical names can be problematic; however, that doesn't mean its necessarily bad in all cases. >>> The practice of UML metamodeling/profile development at the OMG is certainly not representative of the metamodeling/profile development practices outside the OMG. >>> >>> For a profile, I hope it suffices to point out that global name uniqueness for stereotypes would severely limit the extensibility of a profile -- once a name is used for defining a stereotype, that name couldn't be used for defining another stereotype in that profile even if it would be perfectly OK w.r.t. current UML namespace distinguishability rules. >>> >>> I believe the lure of global name uniqueness you allude to comes from the narrow view of the current UML notation which provides only two options: simple name or fully qualified name. >>> This two-option notation is very unsatisfactory in many cases even without name collision because we can't tell which profile<> comes from when it is applied to an element. >>> With colliding names, it's unsatisfactory within a profile and across profiles. For example, it is currently impossible to distinguish by current notation convention alone between SysML 1.3's TestCase vs. UTP 1.1's TestCase. The two concepts are very different but they are undistinguishable by notation alone, e.g.: >>> >>> <> A >>> <> B >>> >>> We shouldn't use the flimsy excuse that the current notation for stereotype uses the simple name as an excuse for suggesting that stereotypes should have unique names in the scope of a profile. >>> >>> Finally, this idea is triply-bad because it would severely compromise the value of Package::URI added in UML 2.4.1. >>> The value of this extension is that it allows us to make a strong correspondence between a UML package and arbitrary namespaces in the semantic web / world wide web. >>> >>> The suggestion that profiles, a special kind of package, would further impose an artificial global name uniqueness constraint that has no legitimate counterpart in practice provides is yet another factor to support my claim that this artificial constraint would be a very, very bad for UML. >>> >>> - Nicolas. >>> >>> >>> >>> On Sep 28, 2011, at 4:42 PM, Ed Seidewitz wrote: >>> >>>> Nicolas -- >>>> >>>> The Package::URI attribute was added because to allow MOF 2.4 to be a strict subset of UML 2.4, because MOF packages can have URIs. You are widening its purpose for profile packages. Perhaps one could make a correspondence between profile subpackages and MOF packages (similar to the correspondence between stereotypes and MOF classes), but the current spec certainly does not make that correspondence. >>>> >>>> It is already pretty much always the case that the classes in metamodels have distinct names, whatever the packaging (at least after package merging is done). And I think the same is true of stereotypes in profiles. In fact, I think this is probably a good constraint, because having multiple stereotypes with the same name in the same profile is sure to be confusing. >>>> >>>> -- Ed >>>> >>>> -----Original Message----- >>>> From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] >>>> Sent: Wednesday, September 28, 2011 7:18 PM >>>> To: Ed Seidewitz >>>> Cc: issues@omg.org; uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) >>>> Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >>>> >>>> Ed, >>>> >>>> I strongly disagree with you. >>>> >>>> The UML Profile mechanism is already very constraining; the constraint you suggest would further restrict what we can do. >>>> The constraint would effectively mean that a Package nested in a Profile would have no semantic value whatsoever. >>>> The Package::URI attribute gives UML Packages a small but very useful semantics, that of denoting an identified namespace. >>>> It would be ironic that this very capability we need for the severely under-specified XMI serialization for the application of a Profile >>>> would be the very same capability that the constraint you suggest would remove! >>>> >>>> - Nicolas. >>>> >>>> On Sep 28, 2011, at 3:40 PM, Ed Seidewitz wrote: >>>> >>>>> Nicolas -- >>>>> >>>>> It would seem simpler to just require that all the stereotypes in a profile have distinct names, whether they are directly owned by the profile or indirectly owned through a package within the profile. Then the current approach of profile nsPrefix plus stereotype name would be sufficient. And I don't think this would really be a serious restriction in practice, since packages are generally used organizationally in profiles, not to introduce namespaces to allow different stereotypes with the same name within the profile. >>>>> >>>>> -- Ed >>>>> >>>>> -----Original Message----- >>>>> From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] >>>>> Sent: Wednesday, September 28, 2011 1:26 PM >>>>> To: issues@omg.org >>>>> Cc: uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org >>>>> Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >>>>> >>>>> This is an issue for UML 2.4.1. >>>>> >>>>> In 18.3.7, the semantics for Profile incompletely describes how to "Use XMI to exhange Profiles" for the case where a "Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype." (18.3.9, Stereotype Semantics). >> >>>>> >>>>> The Semantics section in 18.3.7 is missing the important constraints explaining some of the principles for the XMI serialization of the application of a Profile. >>>>> The following constraints are consistent with the semantics of Stereotype Package containment specified in 18.3.9. >>>>> >>>>> 1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[XML namespace prefix of the Package containing the applied Stereotype]:[applied Stereotype name]>" >>>>> >>>>> This is illustrated in the HomeExample profile in Fig. 18.8 whose Package URI, "http://HomeExample/20101201/HomeExample.xmi", is associated to the XML namespace prefix "HomeExample". >>>>> Therefore, the application of the Stereotype HomeExample::Home serializes into an XML Element tag of the form: "" as shown in the example. >>>>> >>>>> The spec is missing an example where a Stereotype is contained in a Package that is nested in a Profile. >>>>> SysML 1.3 can provide ample material for such an example. >>>>> >>>>> 2) An XMI serializer must include in an XMI document all the XML namespace prefix declarations corresponding to all the container Packages of all Stereotypes whose application to an Element is serialized in that XMI document. >>>>> >>>>> In some cases, this means that the XML namespace prefix used for a particular Package may be different than the convention used for OMG normative profiles (See UML 2.4.1, 18.3.7) where the nsPrefix is the name of the Profile. >>>>> >>>>> 3) The owning Package of each Stereotype must have a Package::URI specified so that an XMI processor can: >>>>> >>>>> - generate an XML namespace prefix for that Package when one of its contained Stereotypes is applied >>>>> >>>>> - resolve a reference to an applied Stereotype to the Package containing the definition of the Stereotype via the XML namespace prefix used for the containing Package URI. >>>>> >>>>> This can be specified in OCL2.3 as follows: >>>>> >>>>> context Stereotype >>>>> inv StereotypeContainerPackageMustHaveURI: >>>>> self.owningPackage.URI->notEmpty() >>>>> >>>>> 4) All the Stereotype-containing Packages in a Profile regardless of nesting must have distinct Package URIs. >>>>> >>>>> This can be specified in OCL2.3 as follows: >>>>> >>>>> context Profile >>>>> inv StereotypeContainingPackagesMustHaveDistinctURIs: >>>>> let pkgs : Set(Package) = self->closure(nestedPackage)->including(self) in >>>>> let allURIs : Bag(String) = pkgs.URI in >>>>> let uniqueURIs : Set(String) = allURIs->asSet() in >>>>> allURIs->size() = uniqueURIs->size() >>>>> >>>>> 5) The OMG normative profile convention in 18.3.7 must be updated to provide a sensible nsPrefix for the XML namespace corresponding to a nested Package in a Profile. >>>>> >>>>> The conventions in 18.3.7 was written at a time when UML 2.0 allowed Stereotypes to be directly contained in a Profile. >>>>> The conventions need to be updated to provide a sensible rule for generating the nsPrefix for a Package nested in a Profile. >>>>> >>>>> I suggest using the "."-concatenated sequence of names of the UML Namespaces from the Profile to the nested Package. >>>>> For example, the SysML 1.3 Profile is named "SysML" and it defines a nested package "SysML::Blocks". >>>>> The suggested nsPrefix for the UML Package SysML::Blocks would be "SysML.Blocks". >>>>> This name is legal per the normative criteria for XML namespace prefix names (see: http://www.w3.org/TR/REC-xml/#NT-Name) >>>>> >>>>> >>>>> - Nicolas. >>>> >>> >> >> -- >> 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. > From: Ed Seidewitz To: "Rouquette, Nicolas F (313K)" CC: Tomas Juknevicius , "Jenkins, J Steven (3101)" , "uml-spec-simplification@omg.org" , "uml-rtf@omg.org" , "issues@omg.org" Date: Thu, 29 Sep 2011 17:24:47 -0400 Subject: RE: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Topic: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Index: Acx+xuqRI0LlYO5OQKSXWgMEpKIIggAIbVrw Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.226]|10.1.50.226|outbound.mailprotector.net|-0.986588|0.895885|0|white|ugly|5925|40|0|0 X-Mailprotector-Results: null_ptr subject_50_chars subject_10_spaces clean X-Mailprotector-Score: 80 X-Mailprotector-IP-Analysis: 0, 10.1.50.226, Ugly c=0.895885 p=-0.986588 Source White X-Mailprotector-Scan-Diagnostics: 0-0-0-32767-c X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8TLQ1ks023211 Nicolas -- UML 2.4 Subclause 18.3.9 Stereotype includes the following paragraph at the end of the Semantics section: "A Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype. When profiles are applied to a Package, the available stereotypes for use as extensions are defined by the applied profiles, and theses [sic] stereotypes can be identified by the fully qualified name if needed in order to distinguish stereotypes with the same name in different profiles or packages. Package and element import can be used to allow the use of unqualified names. Stereotypes directly owned by an applied profile (ownedStereotype) may be used without qualified names." So, it would seem that the use of a qualified name when applying a stereotype is already allowed (though this statement should really be in the Notation section, not the Semantics section). The only issue is serialization in XMI. In UML 2.4 Subclause 18.37 it states that "For a Profile the URI attribute (inherited from package) is used to determine the nsURI to be used to identify instances of the profile in XMI." As you note, nothing is said about URIs for any subpackages. Even if you were to include URIs for the subpackages, there is no guidance in the specification on how those should be used, so any usage would be non-standard. As far as I can see, tools conforming to the standard can only expect to be able to use the profile URI. Any clarification in UML 2.5 has to be backwardly compatible with the interchange of profile and stereotype applications per UML 2.4. I can't see how to formulate your choice (b) to allow this. In the end, Pete Rivett (from whom we haven't heard so far on this) is responsible for writing the UML 2.5 clause that includes profiles. Pete needs to take all this into advisement in drafting that clause and then the submission team and, later, the submission reviewers can comment on it. Until then, I am not sure there is any more to be said. -- Ed -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, September 29, 2011 12:43 PM To: uml-spec-simplification@omg.org; uml-rtf@omg.org; issues@omg.org Cc: Tomas Juknevicius; Jenkins, J Steven (3101) Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Yes, there is still the outstanding issue of clarifying how XMI serialization should work for profiles with nested packages. We currently have two proposals for solving this issue: a) add a constraint that, in the scope of a profile, stereotypes must have unique names regardless of their package container in that profile. This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" means that the Stereotype named [sname] must defined somewhere in the scope of the profile whose Package::URI is associated to [nsPrefix] b) add a constraint that each package containing a stereotype must have a Package::URI. This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" means that the Stereotype named [sname] must be defined as an owned type of the package whose Package::URI is associated to [nsPrefix] We need to discuss the pros/cons of each proposal. Either way, the specification will need clarifying language to: - explain how XMI serialization works for profiles with nested packages - improve the notation for UML stereotypes to show where a stereotype comes from. (a) may be simpler for a single profile and for some tools (e.g., JDeveloper and MagicDraw) but it is certainly not a scalable strategy. Consider this: Profile SysML4Testing imports SysML, UTP Now, I've got a name conflict due to SysML::Requirements::TestCase vs. UTP::TestCase Clearly, the UML specification needs to improve the notation for stereotypes to include qualifying information such as the name of the profile or the name of the container package. In practice, (a) shifts the burden of compliance to profile-scope name unicity to profile developers. For domain-specific language development with profiles, (a) is particularly annoying because we can't do simple things like this: Profile PF Stereotype PF::Electrical::Function Stereotype PF::Mechanical::Function Instead, (a) forces one to do something like this: Profile PF Stereotype PF::Electrical::Electrical.Function Stereotype PF::Mechanical::Mechanical.Function In tools that do (a) and only support the UML stereotype notation as specified, this can be a reasonable compromise, we get: <>, <>. In tools that do (a) but extend the UML stereotype notation to show the name of the profile, we get: <>, <>. Either way, nested packages have no useful purpose -- this completely defeats the purpose they were added in UML 2.3. With (b), UML namespace distinguishability is enough for everybody; some tool vendors may have to do work to support this flexible scheme. For profile developers, we don't have to distort domain-specific concepts, e.g., we can do: Profile PF Stereotype PF::Electrical::Function Stereotype PF::Mechanical::Function The only thing missing is extending the UML stereotype notation to provide options for including qualifying name information such as: - profile name + stereotype name - profile name + stereotype package container name + stereotype name - stereotype package container name + stereotype name - N-segments of the stereotype's fully qualified name from the left + M-segments of the stereotype's fully qualified name from the right - Nicolas. On Sep 29, 2011, at 7:22 AM, Ed Seidewitz wrote: > There is also the issue of when we would be able to address the issue Nicolas has raised. > > I doubt there is going to be enough support to make this an urgent issue leading to UML 2.4.2. For what was supposed to be a stabilizing version before the spec simplification, UML 2.4 has seen enough churn as it is! > > We could certainly provide semantic clarification in UML 2.5. But if putting the new conventions for the use of profile package URIs into UML 2.5 would significantly change the interchange of models using profiles such as SysML. Without this guidance in UML 2.4, there will be no standard for tool vendors to follow and they will continue to use the current convention of :. Changing this in UML 2.5 would be a significant backward incompatibility in model interchange, which would violate the requirements of the RFP. > > So, I don't really see any other sensible course in UML 2.5 than to clarify that the stereotype names in a profile must all be distinct. This means adding an additional constraint that isn't in UML 2.4, but I don't think this will cause any problem with interchange backward compatibility, since the point of Nicolas' issue is that there isn't any standard way now anyway to handle stereotypes with the same name in different packages of a profile. > > I think it is still worth recording the issue as Nicolas proposes. Perhaps it can be discussed further in the UML 2.5 FTF. Or perhaps it is better to leave its resolution to be handled as part of submissions to the Metamodel Extension Facility RFP. > > -- Ed > > -----Original Message----- > From: Dave Hawkins [mailto:dave.hawkins@oracle.com] > Sent: Thursday, September 29, 2011 7:23 AM > To: Rouquette, Nicolas F (313K) > Cc: Ed Seidewitz; issues@omg.org; uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) > Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. > > Nicolas, > > I agree with Ed here, I really don't see why constraining the > names of all classifiers within a profile or metamodel to be > unique is a problem. Certainly it's the way we're approaching > the issue in JDeveloper. You seem to be trying to make things > much more complicated than necessary. > > I agree this isn't explicit in the specification. However it's > implicit from the schema production rules isn't it? I'm under > the impression that elements within a schema have to be > uniquely named, although I wasn't able to find that constraint > in the XML Schema specification when I looked just now. > > For your UML metamodel example. The unmerged superstructure > doesn't have a URI, so it isn't actually usable as a metamodel > for XMI serialisation. The classifiers with the same names > also all refer to fragments of the same classifier, so they > aren't really distinct definitions from a serialization > perspective. > > For a profile, I really don't see why a constraint on the > name uniqueness within that profile is a severe limitation. > It seems like a sensible restriction to me. It doesn't > seem to cause any issues in the UML metamodel and I'd have > thought that's larger than the majority of profiles. It > also means that you can use short 'fully qualified' names > unambiguously: > <> > <> > > Cheers, > > Dave > > On 29/09/11 06:46, Rouquette, Nicolas F (313K) wrote: >> Ed, >> >> Global name uniqueness in the scope of a profile or a metamodel is a bad idea. >> >> For a metamodel, I hope it suffices to point out that a tool could implement the unmerged UML 2.4.1 superstructure or the merged UML 2.4.1 metamodel. Since the semantics of UML PackageMerge stipulate that the two should be equivalent, the unmerged UML 2.4.1 superstructure is as much a metamodel as the merged UML 2.4.1 package is a metamodel. >> >> The UML superstructure is certainly an example where having different concepts with identical names can be problematic; however, that doesn't mean its necessarily bad in all cases. >> The practice of UML metamodeling/profile development at the OMG is certainly not representative of the metamodeling/profile development practices outside the OMG. >> >> For a profile, I hope it suffices to point out that global name uniqueness for stereotypes would severely limit the extensibility of a profile -- once a name is used for defining a stereotype, that name couldn't be used for defining another stereotype in that profile even if it would be perfectly OK w.r.t. current UML namespace distinguishability rules. >> >> I believe the lure of global name uniqueness you allude to comes from the narrow view of the current UML notation which provides only two options: simple name or fully qualified name. >> This two-option notation is very unsatisfactory in many cases even without name collision because we can't tell which profile<> comes from when it is applied to an element. >> With colliding names, it's unsatisfactory within a profile and across profiles. For example, it is currently impossible to distinguish by current notation convention alone between SysML 1.3's TestCase vs. UTP 1.1's TestCase. The two concepts are very different but they are undistinguishable by notation alone, e.g.: >> >> <> A >> <> B >> >> We shouldn't use the flimsy excuse that the current notation for stereotype uses the simple name as an excuse for suggesting that stereotypes should have unique names in the scope of a profile. >> >> Finally, this idea is triply-bad because it would severely compromise the value of Package::URI added in UML 2.4.1. >> The value of this extension is that it allows us to make a strong correspondence between a UML package and arbitrary namespaces in the semantic web / world wide web. >> >> The suggestion that profiles, a special kind of package, would further impose an artificial global name uniqueness constraint that has no legitimate counterpart in practice provides is yet another factor to support my claim that this artificial constraint would be a very, very bad for UML. >> >> - Nicolas. >> >> >> >> On Sep 28, 2011, at 4:42 PM, Ed Seidewitz wrote: >> >>> Nicolas -- >>> >>> The Package::URI attribute was added because to allow MOF 2.4 to be a strict subset of UML 2.4, because MOF packages can have URIs. You are widening its purpose for profile packages. Perhaps one could make a correspondence between profile subpackages and MOF packages (similar to the correspondence between stereotypes and MOF classes), but the current spec certainly does not make that correspondence. >>> >>> It is already pretty much always the case that the classes in metamodels have distinct names, whatever the packaging (at least after package merging is done). And I think the same is true of stereotypes in profiles. In fact, I think this is probably a good constraint, because having multiple stereotypes with the same name in the same profile is sure to be confusing. >>> >>> -- Ed >>> >>> -----Original Message----- >>> From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] >>> Sent: Wednesday, September 28, 2011 7:18 PM >>> To: Ed Seidewitz >>> Cc: issues@omg.org; uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) >>> Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >>> >>> Ed, >>> >>> I strongly disagree with you. >>> >>> The UML Profile mechanism is already very constraining; the constraint you suggest would further restrict what we can do. >>> The constraint would effectively mean that a Package nested in a Profile would have no semantic value whatsoever. >>> The Package::URI attribute gives UML Packages a small but very useful semantics, that of denoting an identified namespace. >>> It would be ironic that this very capability we need for the severely under-specified XMI serialization for the application of a Profile >>> would be the very same capability that the constraint you suggest would remove! >>> >>> - Nicolas. >>> >>> On Sep 28, 2011, at 3:40 PM, Ed Seidewitz wrote: >>> >>>> Nicolas -- >>>> >>>> It would seem simpler to just require that all the stereotypes in a profile have distinct names, whether they are directly owned by the profile or indirectly owned through a package within the profile. Then the current approach of profile nsPrefix plus stereotype name would be sufficient. And I don't think this would really be a serious restriction in practice, since packages are generally used organizationally in profiles, not to introduce namespaces to allow different stereotypes with the same name within the profile. >>>> >>>> -- Ed >>>> >>>> -----Original Message----- >>>> From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] >>>> Sent: Wednesday, September 28, 2011 1:26 PM >>>> To: issues@omg.org >>>> Cc: uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org >>>> Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >>>> >>>> This is an issue for UML 2.4.1. >>>> >>>> In 18.3.7, the semantics for Profile incompletely describes how to "Use XMI to exhange Profiles" for the case where a "Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype." (18.3.9, Stereotype Semantics). > >>>> >>>> The Semantics section in 18.3.7 is missing the important constraints explaining some of the principles for the XMI serialization of the application of a Profile. >>>> The following constraints are consistent with the semantics of Stereotype Package containment specified in 18.3.9. >>>> >>>> 1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[XML namespace prefix of the Package containing the applied Stereotype]:[applied Stereotype name]>" >>>> >>>> This is illustrated in the HomeExample profile in Fig. 18.8 whose Package URI, "http://HomeExample/20101201/HomeExample.xmi", is associated to the XML namespace prefix "HomeExample". >>>> Therefore, the application of the Stereotype HomeExample::Home serializes into an XML Element tag of the form: "" as shown in the example. >>>> >>>> The spec is missing an example where a Stereotype is contained in a Package that is nested in a Profile. >>>> SysML 1.3 can provide ample material for such an example. >>>> >>>> 2) An XMI serializer must include in an XMI document all the XML namespace prefix declarations corresponding to all the container Packages of all Stereotypes whose application to an Element is serialized in that XMI document. >>>> >>>> In some cases, this means that the XML namespace prefix used for a particular Package may be different than the convention used for OMG normative profiles (See UML 2.4.1, 18.3.7) where the nsPrefix is the name of the Profile. >>>> >>>> 3) The owning Package of each Stereotype must have a Package::URI specified so that an XMI processor can: >>>> >>>> - generate an XML namespace prefix for that Package when one of its contained Stereotypes is applied >>>> >>>> - resolve a reference to an applied Stereotype to the Package containing the definition of the Stereotype via the XML namespace prefix used for the containing Package URI. >>>> >>>> This can be specified in OCL2.3 as follows: >>>> >>>> context Stereotype >>>> inv StereotypeContainerPackageMustHaveURI: >>>> self.owningPackage.URI->notEmpty() >>>> >>>> 4) All the Stereotype-containing Packages in a Profile regardless of nesting must have distinct Package URIs. >>>> >>>> This can be specified in OCL2.3 as follows: >>>> >>>> context Profile >>>> inv StereotypeContainingPackagesMustHaveDistinctURIs: >>>> let pkgs : Set(Package) = self->closure(nestedPackage)->including(self) in >>>> let allURIs : Bag(String) = pkgs.URI in >>>> let uniqueURIs : Set(String) = allURIs->asSet() in >>>> allURIs->size() = uniqueURIs->size() >>>> >>>> 5) The OMG normative profile convention in 18.3.7 must be updated to provide a sensible nsPrefix for the XML namespace corresponding to a nested Package in a Profile. >>>> >>>> The conventions in 18.3.7 was written at a time when UML 2.0 allowed Stereotypes to be directly contained in a Profile. >>>> The conventions need to be updated to provide a sensible rule for generating the nsPrefix for a Package nested in a Profile. >>>> >>>> I suggest using the "."-concatenated sequence of names of the UML Namespaces from the Profile to the nested Package. >>>> For example, the SysML 1.3 Profile is named "SysML" and it defines a nested package "SysML::Blocks". >>>> The suggested nsPrefix for the UML Package SysML::Blocks would be "SysML.Blocks". >>>> This name is legal per the normative criteria for XML namespace prefix names (see: http://www.w3.org/TR/REC-xml/#NT-Name) >>>> >>>> >>>> - Nicolas. >>> >> > > -- > 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. Subject: RE: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Date: Thu, 29 Sep 2011 14:53:01 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Index: Acx+xuqRI0LlYO5OQKSXWgMEpKIIggAIbVrwAAHd9UA= From: "Pete Rivett" To: "Ed Seidewitz" , "Rouquette, Nicolas F (313K)" Cc: "Tomas Juknevicius" , "Jenkins, J Steven (3101)" , , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8TLqmXO025310 I don't see the relevance of the naming part of this discussion/quotations since stereotypes are never accessed/identified by name (qualified or otherwise): they are explicitly referenced as elements (both in the tool and the XMI). That's even true of the user interface of most tools - the modeler typically selects the stereotypes from a list (where they are shown with the qualified name). Likewise in diagrams, tools usually provide the option of displaying (or not) the ownership/qualified name of an element. As I've said many times, import statements are pretty useless in practice since, as currently documented, they only affect naming. Even outside stereotype application, references by name are very infrequent - typically only in OpaqueExpressions (e.g. as used for OCL Constraints). That's the problem of basing a modeling language on a programming language paradigm . On the substantive question - whether the nsURI for a Profile should apply to all of its non-profile sub-packages - then I agree with Ed that it should. In other words the sub-packages are for management of the profile elements not for any application purposes. That I believe reflects the consensus from a long thread we had in the UML RTF around proposals from Jim Amsden. And it provides maximum flexibility - if you want a separate nsURI then you can always turn the sub-package into a sub-profile. Pete -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, September 29, 2011 2:25 PM To: Rouquette, Nicolas F (313K) Cc: Tomas Juknevicius; Jenkins, J Steven (3101); uml-spec-simplification@omg.org; uml-rtf@omg.org; issues@omg.org Subject: RE: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Nicolas -- UML 2.4 Subclause 18.3.9 Stereotype includes the following paragraph at the end of the Semantics section: "A Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype. When profiles are applied to a Package, the available stereotypes for use as extensions are defined by the applied profiles, and theses [sic] stereotypes can be identified by the fully qualified name if needed in order to distinguish stereotypes with the same name in different profiles or packages. Package and element import can be used to allow the use of unqualified names. Stereotypes directly owned by an applied profile (ownedStereotype) may be used without qualified names." So, it would seem that the use of a qualified name when applying a stereotype is already allowed (though this statement should really be in the Notation section, not the Semantics section). The only issue is serialization in XMI. In UML 2.4 Subclause 18.37 it states that "For a Profile the URI attribute (inherited from package) is used to determine the nsURI to be used to identify instances of the profile in XMI." As you note, nothing is said about URIs for any subpackages. Even if you were to include URIs for the subpackages, there is no guidance in the specification on how those should be used, so any usage would be non-standard. As far as I can see, tools conforming to the standard can only expect to be able to use the profile URI. Any clarification in UML 2.5 has to be backwardly compatible with the interchange of profile and stereotype applications per UML 2.4. I can't see how to formulate your choice (b) to allow this. In the end, Pete Rivett (from whom we haven't heard so far on this) is responsible for writing the UML 2.5 clause that includes profiles. Pete needs to take all this into advisement in drafting that clause and then the submission team and, later, the submission reviewers can comment on it. Until then, I am not sure there is any more to be said. -- Ed -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, September 29, 2011 12:43 PM To: uml-spec-simplification@omg.org; uml-rtf@omg.org; issues@omg.org Cc: Tomas Juknevicius; Jenkins, J Steven (3101) Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Yes, there is still the outstanding issue of clarifying how XMI serialization should work for profiles with nested packages. We currently have two proposals for solving this issue: a) add a constraint that, in the scope of a profile, stereotypes must have unique names regardless of their package container in that profile. This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" means that the Stereotype named [sname] must defined somewhere in the scope of the profile whose Package::URI is associated to [nsPrefix] b) add a constraint that each package containing a stereotype must have a Package::URI. This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" means that the Stereotype named [sname] must be defined as an owned type of the package whose Package::URI is associated to [nsPrefix] We need to discuss the pros/cons of each proposal. Either way, the specification will need clarifying language to: - explain how XMI serialization works for profiles with nested packages - improve the notation for UML stereotypes to show where a stereotype comes from. (a) may be simpler for a single profile and for some tools (e.g., JDeveloper and MagicDraw) but it is certainly not a scalable strategy. Consider this: Profile SysML4Testing imports SysML, UTP Now, I've got a name conflict due to SysML::Requirements::TestCase vs. UTP::TestCase Clearly, the UML specification needs to improve the notation for stereotypes to include qualifying information such as the name of the profile or the name of the container package. In practice, (a) shifts the burden of compliance to profile-scope name unicity to profile developers. For domain-specific language development with profiles, (a) is particularly annoying because we can't do simple things like this: Profile PF Stereotype PF::Electrical::Function Stereotype PF::Mechanical::Function Instead, (a) forces one to do something like this: Profile PF Stereotype PF::Electrical::Electrical.Function Stereotype PF::Mechanical::Mechanical.Function In tools that do (a) and only support the UML stereotype notation as specified, this can be a reasonable compromise, we get: <>, <>. In tools that do (a) but extend the UML stereotype notation to show the name of the profile, we get: <>, <>. Either way, nested packages have no useful purpose -- this completely defeats the purpose they were added in UML 2.3. With (b), UML namespace distinguishability is enough for everybody; some tool vendors may have to do work to support this flexible scheme. For profile developers, we don't have to distort domain-specific concepts, e.g., we can do: Profile PF Stereotype PF::Electrical::Function Stereotype PF::Mechanical::Function The only thing missing is extending the UML stereotype notation to provide options for including qualifying name information such as: - profile name + stereotype name - profile name + stereotype package container name + stereotype name - stereotype package container name + stereotype name - N-segments of the stereotype's fully qualified name from the left + M-segments of the stereotype's fully qualified name from the right - Nicolas. On Sep 29, 2011, at 7:22 AM, Ed Seidewitz wrote: > There is also the issue of when we would be able to address the issue Nicolas has raised. > > I doubt there is going to be enough support to make this an urgent issue leading to UML 2.4.2. For what was supposed to be a stabilizing version before the spec simplification, UML 2.4 has seen enough churn as it is! > > We could certainly provide semantic clarification in UML 2.5. But if putting the new conventions for the use of profile package URIs into UML 2.5 would significantly change the interchange of models using profiles such as SysML. Without this guidance in UML 2.4, there will be no standard for tool vendors to follow and they will continue to use the current convention of :. Changing this in UML 2.5 would be a significant backward incompatibility in model interchange, which would violate the requirements of the RFP. > > So, I don't really see any other sensible course in UML 2.5 than to clarify that the stereotype names in a profile must all be distinct. This means adding an additional constraint that isn't in UML 2.4, but I don't think this will cause any problem with interchange backward compatibility, since the point of Nicolas' issue is that there isn't any standard way now anyway to handle stereotypes with the same name in different packages of a profile. > > I think it is still worth recording the issue as Nicolas proposes. Perhaps it can be discussed further in the UML 2.5 FTF. Or perhaps it is better to leave its resolution to be handled as part of submissions to the Metamodel Extension Facility RFP. > > -- Ed > > -----Original Message----- > From: Dave Hawkins [mailto:dave.hawkins@oracle.com] > Sent: Thursday, September 29, 2011 7:23 AM > To: Rouquette, Nicolas F (313K) > Cc: Ed Seidewitz; issues@omg.org; uml-spec-simplification@omg.org; > Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) > Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. > > Nicolas, > > I agree with Ed here, I really don't see why constraining the names of > all classifiers within a profile or metamodel to be unique is a > problem. Certainly it's the way we're approaching the issue in > JDeveloper. You seem to be trying to make things much more complicated > than necessary. > > I agree this isn't explicit in the specification. However it's > implicit from the schema production rules isn't it? I'm under the > impression that elements within a schema have to be uniquely named, > although I wasn't able to find that constraint in the XML Schema > specification when I looked just now. > > For your UML metamodel example. The unmerged superstructure doesn't > have a URI, so it isn't actually usable as a metamodel for XMI > serialisation. The classifiers with the same names also all refer to > fragments of the same classifier, so they aren't really distinct > definitions from a serialization perspective. > > For a profile, I really don't see why a constraint on the name > uniqueness within that profile is a severe limitation. > It seems like a sensible restriction to me. It doesn't seem to cause > any issues in the UML metamodel and I'd have thought that's larger > than the majority of profiles. It also means that you can use short > 'fully qualified' names > unambiguously: > <> > <> > > Cheers, > > Dave > > On 29/09/11 06:46, Rouquette, Nicolas F (313K) wrote: >> Ed, >> >> Global name uniqueness in the scope of a profile or a metamodel is a bad idea. >> >> For a metamodel, I hope it suffices to point out that a tool could implement the unmerged UML 2.4.1 superstructure or the merged UML 2.4.1 metamodel. Since the semantics of UML PackageMerge stipulate that the two should be equivalent, the unmerged UML 2.4.1 superstructure is as much a metamodel as the merged UML 2.4.1 package is a metamodel. >> >> The UML superstructure is certainly an example where having different concepts with identical names can be problematic; however, that doesn't mean its necessarily bad in all cases. >> The practice of UML metamodeling/profile development at the OMG is certainly not representative of the metamodeling/profile development practices outside the OMG. >> >> For a profile, I hope it suffices to point out that global name uniqueness for stereotypes would severely limit the extensibility of a profile -- once a name is used for defining a stereotype, that name couldn't be used for defining another stereotype in that profile even if it would be perfectly OK w.r.t. current UML namespace distinguishability rules. >> >> I believe the lure of global name uniqueness you allude to comes from the narrow view of the current UML notation which provides only two options: simple name or fully qualified name. >> This two-option notation is very unsatisfactory in many cases even without name collision because we can't tell which profile<> comes from when it is applied to an element. >> With colliding names, it's unsatisfactory within a profile and across profiles. For example, it is currently impossible to distinguish by current notation convention alone between SysML 1.3's TestCase vs. UTP 1.1's TestCase. The two concepts are very different but they are undistinguishable by notation alone, e.g.: >> >> <> A >> <> B >> >> We shouldn't use the flimsy excuse that the current notation for stereotype uses the simple name as an excuse for suggesting that stereotypes should have unique names in the scope of a profile. >> >> Finally, this idea is triply-bad because it would severely compromise the value of Package::URI added in UML 2.4.1. >> The value of this extension is that it allows us to make a strong correspondence between a UML package and arbitrary namespaces in the semantic web / world wide web. >> >> The suggestion that profiles, a special kind of package, would further impose an artificial global name uniqueness constraint that has no legitimate counterpart in practice provides is yet another factor to support my claim that this artificial constraint would be a very, very bad for UML. >> >> - Nicolas. >> >> >> >> On Sep 28, 2011, at 4:42 PM, Ed Seidewitz wrote: >> >>> Nicolas -- >>> >>> The Package::URI attribute was added because to allow MOF 2.4 to be a strict subset of UML 2.4, because MOF packages can have URIs. You are widening its purpose for profile packages. Perhaps one could make a correspondence between profile subpackages and MOF packages (similar to the correspondence between stereotypes and MOF classes), but the current spec certainly does not make that correspondence. >>> >>> It is already pretty much always the case that the classes in metamodels have distinct names, whatever the packaging (at least after package merging is done). And I think the same is true of stereotypes in profiles. In fact, I think this is probably a good constraint, because having multiple stereotypes with the same name in the same profile is sure to be confusing. >>> >>> -- Ed >>> >>> -----Original Message----- >>> From: Rouquette, Nicolas F (313K) >>> [mailto:nicolas.f.rouquette@jpl.nasa.gov] >>> Sent: Wednesday, September 28, 2011 7:18 PM >>> To: Ed Seidewitz >>> Cc: issues@omg.org; uml-spec-simplification@omg.org; Tomas >>> Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) >>> Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >>> >>> Ed, >>> >>> I strongly disagree with you. >>> >>> The UML Profile mechanism is already very constraining; the constraint you suggest would further restrict what we can do. >>> The constraint would effectively mean that a Package nested in a Profile would have no semantic value whatsoever. >>> The Package::URI attribute gives UML Packages a small but very useful semantics, that of denoting an identified namespace. >>> It would be ironic that this very capability we need for the >>> severely under-specified XMI serialization for the application of a Profile would be the very same capability that the constraint you suggest would remove! >>> >>> - Nicolas. >>> >>> On Sep 28, 2011, at 3:40 PM, Ed Seidewitz wrote: >>> >>>> Nicolas -- >>>> >>>> It would seem simpler to just require that all the stereotypes in a profile have distinct names, whether they are directly owned by the profile or indirectly owned through a package within the profile. Then the current approach of profile nsPrefix plus stereotype name would be sufficient. And I don't think this would really be a serious restriction in practice, since packages are generally used organizationally in profiles, not to introduce namespaces to allow different stereotypes with the same name within the profile. >>>> >>>> -- Ed >>>> >>>> -----Original Message----- >>>> From: Rouquette, Nicolas F (313K) >>>> [mailto:nicolas.f.rouquette@jpl.nasa.gov] >>>> Sent: Wednesday, September 28, 2011 1:26 PM >>>> To: issues@omg.org >>>> Cc: uml-spec-simplification@omg.org; Tomas Juknevicius; >>>> uml-rtf@omg.org >>>> Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >>>> >>>> This is an issue for UML 2.4.1. >>>> >>>> In 18.3.7, the semantics for Profile incompletely describes how to "Use XMI to exhange Profiles" for the case where a "Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype." (18.3.9, Stereotype Semantics). > >>>> >>>> The Semantics section in 18.3.7 is missing the important constraints explaining some of the principles for the XMI serialization of the application of a Profile. >>>> The following constraints are consistent with the semantics of Stereotype Package containment specified in 18.3.9. >>>> >>>> 1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[XML namespace prefix of the Package containing the applied Stereotype]:[applied Stereotype name]>" >>>> >>>> This is illustrated in the HomeExample profile in Fig. 18.8 whose Package URI, "http://HomeExample/20101201/HomeExample.xmi", is associated to the XML namespace prefix "HomeExample". >>>> Therefore, the application of the Stereotype HomeExample::Home serializes into an XML Element tag of the form: "" as shown in the example. >>>> >>>> The spec is missing an example where a Stereotype is contained in a Package that is nested in a Profile. >>>> SysML 1.3 can provide ample material for such an example. >>>> >>>> 2) An XMI serializer must include in an XMI document all the XML namespace prefix declarations corresponding to all the container Packages of all Stereotypes whose application to an Element is serialized in that XMI document. >>>> >>>> In some cases, this means that the XML namespace prefix used for a particular Package may be different than the convention used for OMG normative profiles (See UML 2.4.1, 18.3.7) where the nsPrefix is the name of the Profile. >>>> >>>> 3) The owning Package of each Stereotype must have a Package::URI specified so that an XMI processor can: >>>> >>>> - generate an XML namespace prefix for that Package when one of its >>>> contained Stereotypes is applied >>>> >>>> - resolve a reference to an applied Stereotype to the Package containing the definition of the Stereotype via the XML namespace prefix used for the containing Package URI. >>>> >>>> This can be specified in OCL2.3 as follows: >>>> >>>> context Stereotype >>>> inv StereotypeContainerPackageMustHaveURI: >>>> self.owningPackage.URI->notEmpty() >>>> >>>> 4) All the Stereotype-containing Packages in a Profile regardless of nesting must have distinct Package URIs. >>>> >>>> This can be specified in OCL2.3 as follows: >>>> >>>> context Profile >>>> inv StereotypeContainingPackagesMustHaveDistinctURIs: >>>> let pkgs : Set(Package) = >>>> self->closure(nestedPackage)->including(self) in let allURIs : >>>> Bag(String) = pkgs.URI in let uniqueURIs : Set(String) = >>>> allURIs->asSet() in >>>> allURIs->size() = uniqueURIs->size() >>>> >>>> 5) The OMG normative profile convention in 18.3.7 must be updated to provide a sensible nsPrefix for the XML namespace corresponding to a nested Package in a Profile. >>>> >>>> The conventions in 18.3.7 was written at a time when UML 2.0 allowed Stereotypes to be directly contained in a Profile. >>>> The conventions need to be updated to provide a sensible rule for generating the nsPrefix for a Package nested in a Profile. >>>> >>>> I suggest using the "."-concatenated sequence of names of the UML Namespaces from the Profile to the nested Package. >>>> For example, the SysML 1.3 Profile is named "SysML" and it defines a nested package "SysML::Blocks". >>>> The suggested nsPrefix for the UML Package SysML::Blocks would be "SysML.Blocks". >>>> This name is legal per the normative criteria for XML namespace >>>> prefix names (see: http://www.w3.org/TR/REC-xml/#NT-Name) >>>> >>>> >>>> - Nicolas. >>> >> > > -- > 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. From: Ed Seidewitz To: "uml-spec-simplification@omg.org" , "uml-rtf@omg.org" CC: Tomas Juknevicius , "Jenkins, J Steven (3101)" Date: Thu, 29 Sep 2011 18:01:02 -0400 Subject: RE: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Topic: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Index: Acx+xuqRI0LlYO5OQKSXWgMEpKIIggAIbVrwAAHd9UAAAKvrQA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.225]|10.1.50.225|outbound.mailprotector.net|0|0|0|new|ugly|0|0|0|0 X-Mailprotector-Results: null_ptr subject_50_chars subject_10_spaces clean X-Mailprotector-Score: 80 X-Mailprotector-IP-Analysis: 0, 10.1.50.225, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-32767-c X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8TM0cuG025758 Pete said: "Likewise in diagrams, tools usually provide the option of displaying (or not) the ownership/qualified name of an element." Yes, that's why the paragraph I quoted from the spec on qualified names for stereotypes belongs under notation, not semantics. It is still worth mentioning, though, just to make it clear that using a qualified name in the stereotype guillemet notation is a legal presentation option. "if you want a separate nsURI then you can always turn the sub-package into a sub-profile." Exactly! This is a key point. I wish I had thought to mention it earlier myself! -- Ed -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, September 29, 2011 5:53 PM To: Ed Seidewitz; Rouquette, Nicolas F (313K) Cc: Tomas Juknevicius; Jenkins, J Steven (3101); uml-spec-simplification@omg.org; uml-rtf@omg.org Subject: RE: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. I don't see the relevance of the naming part of this discussion/quotations since stereotypes are never accessed/identified by name (qualified or otherwise): they are explicitly referenced as elements (both in the tool and the XMI). That's even true of the user interface of most tools - the modeler typically selects the stereotypes from a list (where they are shown with the qualified name). Likewise in diagrams, tools usually provide the option of displaying (or not) the ownership/qualified name of an element. As I've said many times, import statements are pretty useless in practice since, as currently documented, they only affect naming. Even outside stereotype application, references by name are very infrequent - typically only in OpaqueExpressions (e.g. as used for OCL Constraints). That's the problem of basing a modeling language on a programming language paradigm . On the substantive question - whether the nsURI for a Profile should apply to all of its non-profile sub-packages - then I agree with Ed that it should. In other words the sub-packages are for management of the profile elements not for any application purposes. That I believe reflects the consensus from a long thread we had in the UML RTF around proposals from Jim Amsden. And it provides maximum flexibility - if you want a separate nsURI then you can always turn the sub-package into a sub-profile. Pete -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, September 29, 2011 2:25 PM To: Rouquette, Nicolas F (313K) Cc: Tomas Juknevicius; Jenkins, J Steven (3101); uml-spec-simplification@omg.org; uml-rtf@omg.org; issues@omg.org Subject: RE: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Nicolas -- UML 2.4 Subclause 18.3.9 Stereotype includes the following paragraph at the end of the Semantics section: "A Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype. When profiles are applied to a Package, the available stereotypes for use as extensions are defined by the applied profiles, and theses [sic] stereotypes can be identified by the fully qualified name if needed in order to distinguish stereotypes with the same name in different profiles or packages. Package and element import can be used to allow the use of unqualified names. Stereotypes directly owned by an applied profile (ownedStereotype) may be used without qualified names." So, it would seem that the use of a qualified name when applying a stereotype is already allowed (though this statement should really be in the Notation section, not the Semantics section). The only issue is serialization in XMI. In UML 2.4 Subclause 18.37 it states that "For a Profile the URI attribute (inherited from package) is used to determine the nsURI to be used to identify instances of the profile in XMI." As you note, nothing is said about URIs for any subpackages. Even if you were to include URIs for the subpackages, there is no guidance in the specification on how those should be used, so any usage would be non-standard. As far as I can see, tools conforming to the standard can only expect to be able to use the profile URI. Any clarification in UML 2.5 has to be backwardly compatible with the interchange of profile and stereotype applications per UML 2.4. I can't see how to formulate your choice (b) to allow this. In the end, Pete Rivett (from whom we haven't heard so far on this) is responsible for writing the UML 2.5 clause that includes profiles. Pete needs to take all this into advisement in drafting that clause and then the submission team and, later, the submission reviewers can comment on it. Until then, I am not sure there is any more to be said. -- Ed -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, September 29, 2011 12:43 PM To: uml-spec-simplification@omg.org; uml-rtf@omg.org; issues@omg.org Cc: Tomas Juknevicius; Jenkins, J Steven (3101) Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Yes, there is still the outstanding issue of clarifying how XMI serialization should work for profiles with nested packages. We currently have two proposals for solving this issue: a) add a constraint that, in the scope of a profile, stereotypes must have unique names regardless of their package container in that profile. This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" means that the Stereotype named [sname] must defined somewhere in the scope of the profile whose Package::URI is associated to [nsPrefix] b) add a constraint that each package containing a stereotype must have a Package::URI. This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" means that the Stereotype named [sname] must be defined as an owned type of the package whose Package::URI is associated to [nsPrefix] We need to discuss the pros/cons of each proposal. Either way, the specification will need clarifying language to: - explain how XMI serialization works for profiles with nested packages - improve the notation for UML stereotypes to show where a stereotype comes from. (a) may be simpler for a single profile and for some tools (e.g., JDeveloper and MagicDraw) but it is certainly not a scalable strategy. Consider this: Profile SysML4Testing imports SysML, UTP Now, I've got a name conflict due to SysML::Requirements::TestCase vs. UTP::TestCase Clearly, the UML specification needs to improve the notation for stereotypes to include qualifying information such as the name of the profile or the name of the container package. In practice, (a) shifts the burden of compliance to profile-scope name unicity to profile developers. For domain-specific language development with profiles, (a) is particularly annoying because we can't do simple things like this: Profile PF Stereotype PF::Electrical::Function Stereotype PF::Mechanical::Function Instead, (a) forces one to do something like this: Profile PF Stereotype PF::Electrical::Electrical.Function Stereotype PF::Mechanical::Mechanical.Function In tools that do (a) and only support the UML stereotype notation as specified, this can be a reasonable compromise, we get: <>, <>. In tools that do (a) but extend the UML stereotype notation to show the name of the profile, we get: <>, <>. Either way, nested packages have no useful purpose -- this completely defeats the purpose they were added in UML 2.3. With (b), UML namespace distinguishability is enough for everybody; some tool vendors may have to do work to support this flexible scheme. For profile developers, we don't have to distort domain-specific concepts, e.g., we can do: Profile PF Stereotype PF::Electrical::Function Stereotype PF::Mechanical::Function The only thing missing is extending the UML stereotype notation to provide options for including qualifying name information such as: - profile name + stereotype name - profile name + stereotype package container name + stereotype name - stereotype package container name + stereotype name - N-segments of the stereotype's fully qualified name from the left + M-segments of the stereotype's fully qualified name from the right - Nicolas. On Sep 29, 2011, at 7:22 AM, Ed Seidewitz wrote: > There is also the issue of when we would be able to address the issue Nicolas has raised. > > I doubt there is going to be enough support to make this an urgent issue leading to UML 2.4.2. For what was supposed to be a stabilizing version before the spec simplification, UML 2.4 has seen enough churn as it is! > > We could certainly provide semantic clarification in UML 2.5. But if putting the new conventions for the use of profile package URIs into UML 2.5 would significantly change the interchange of models using profiles such as SysML. Without this guidance in UML 2.4, there will be no standard for tool vendors to follow and they will continue to use the current convention of :. Changing this in UML 2.5 would be a significant backward incompatibility in model interchange, which would violate the requirements of the RFP. > > So, I don't really see any other sensible course in UML 2.5 than to clarify that the stereotype names in a profile must all be distinct. This means adding an additional constraint that isn't in UML 2.4, but I don't think this will cause any problem with interchange backward compatibility, since the point of Nicolas' issue is that there isn't any standard way now anyway to handle stereotypes with the same name in different packages of a profile. > > I think it is still worth recording the issue as Nicolas proposes. Perhaps it can be discussed further in the UML 2.5 FTF. Or perhaps it is better to leave its resolution to be handled as part of submissions to the Metamodel Extension Facility RFP. > > -- Ed > > -----Original Message----- > From: Dave Hawkins [mailto:dave.hawkins@oracle.com] > Sent: Thursday, September 29, 2011 7:23 AM > To: Rouquette, Nicolas F (313K) > Cc: Ed Seidewitz; issues@omg.org; uml-spec-simplification@omg.org; > Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) > Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. > > Nicolas, > > I agree with Ed here, I really don't see why constraining the names of > all classifiers within a profile or metamodel to be unique is a > problem. Certainly it's the way we're approaching the issue in > JDeveloper. You seem to be trying to make things much more complicated > than necessary. > > I agree this isn't explicit in the specification. However it's > implicit from the schema production rules isn't it? I'm under the > impression that elements within a schema have to be uniquely named, > although I wasn't able to find that constraint in the XML Schema > specification when I looked just now. > > For your UML metamodel example. The unmerged superstructure doesn't > have a URI, so it isn't actually usable as a metamodel for XMI > serialisation. The classifiers with the same names also all refer to > fragments of the same classifier, so they aren't really distinct > definitions from a serialization perspective. > > For a profile, I really don't see why a constraint on the name > uniqueness within that profile is a severe limitation. > It seems like a sensible restriction to me. It doesn't seem to cause > any issues in the UML metamodel and I'd have thought that's larger > than the majority of profiles. It also means that you can use short > 'fully qualified' names > unambiguously: > <> > <> > > Cheers, > > Dave > > On 29/09/11 06:46, Rouquette, Nicolas F (313K) wrote: >> Ed, >> >> Global name uniqueness in the scope of a profile or a metamodel is a bad idea. >> >> For a metamodel, I hope it suffices to point out that a tool could implement the unmerged UML 2.4.1 superstructure or the merged UML 2.4.1 metamodel. Since the semantics of UML PackageMerge stipulate that the two should be equivalent, the unmerged UML 2.4.1 superstructure is as much a metamodel as the merged UML 2.4.1 package is a metamodel. >> >> The UML superstructure is certainly an example where having different concepts with identical names can be problematic; however, that doesn't mean its necessarily bad in all cases. >> The practice of UML metamodeling/profile development at the OMG is certainly not representative of the metamodeling/profile development practices outside the OMG. >> >> For a profile, I hope it suffices to point out that global name uniqueness for stereotypes would severely limit the extensibility of a profile -- once a name is used for defining a stereotype, that name couldn't be used for defining another stereotype in that profile even if it would be perfectly OK w.r.t. current UML namespace distinguishability rules. >> >> I believe the lure of global name uniqueness you allude to comes from the narrow view of the current UML notation which provides only two options: simple name or fully qualified name. >> This two-option notation is very unsatisfactory in many cases even without name collision because we can't tell which profile<> comes from when it is applied to an element. >> With colliding names, it's unsatisfactory within a profile and across profiles. For example, it is currently impossible to distinguish by current notation convention alone between SysML 1.3's TestCase vs. UTP 1.1's TestCase. The two concepts are very different but they are undistinguishable by notation alone, e.g.: >> >> <> A >> <> B >> >> We shouldn't use the flimsy excuse that the current notation for stereotype uses the simple name as an excuse for suggesting that stereotypes should have unique names in the scope of a profile. >> >> Finally, this idea is triply-bad because it would severely compromise the value of Package::URI added in UML 2.4.1. >> The value of this extension is that it allows us to make a strong correspondence between a UML package and arbitrary namespaces in the semantic web / world wide web. >> >> The suggestion that profiles, a special kind of package, would further impose an artificial global name uniqueness constraint that has no legitimate counterpart in practice provides is yet another factor to support my claim that this artificial constraint would be a very, very bad for UML. >> >> - Nicolas. >> >> >> >> On Sep 28, 2011, at 4:42 PM, Ed Seidewitz wrote: >> >>> Nicolas -- >>> >>> The Package::URI attribute was added because to allow MOF 2.4 to be a strict subset of UML 2.4, because MOF packages can have URIs. You are widening its purpose for profile packages. Perhaps one could make a correspondence between profile subpackages and MOF packages (similar to the correspondence between stereotypes and MOF classes), but the current spec certainly does not make that correspondence. >>> >>> It is already pretty much always the case that the classes in metamodels have distinct names, whatever the packaging (at least after package merging is done). And I think the same is true of stereotypes in profiles. In fact, I think this is probably a good constraint, because having multiple stereotypes with the same name in the same profile is sure to be confusing. >>> >>> -- Ed >>> >>> -----Original Message----- >>> From: Rouquette, Nicolas F (313K) >>> [mailto:nicolas.f.rouquette@jpl.nasa.gov] >>> Sent: Wednesday, September 28, 2011 7:18 PM >>> To: Ed Seidewitz >>> Cc: issues@omg.org; uml-spec-simplification@omg.org; Tomas >>> Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) >>> Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >>> >>> Ed, >>> >>> I strongly disagree with you. >>> >>> The UML Profile mechanism is already very constraining; the constraint you suggest would further restrict what we can do. >>> The constraint would effectively mean that a Package nested in a Profile would have no semantic value whatsoever. >>> The Package::URI attribute gives UML Packages a small but very useful semantics, that of denoting an identified namespace. >>> It would be ironic that this very capability we need for the >>> severely under-specified XMI serialization for the application of a Profile would be the very same capability that the constraint you suggest would remove! >>> >>> - Nicolas. >>> >>> On Sep 28, 2011, at 3:40 PM, Ed Seidewitz wrote: >>> >>>> Nicolas -- >>>> >>>> It would seem simpler to just require that all the stereotypes in a profile have distinct names, whether they are directly owned by the profile or indirectly owned through a package within the profile. Then the current approach of profile nsPrefix plus stereotype name would be sufficient. And I don't think this would really be a serious restriction in practice, since packages are generally used organizationally in profiles, not to introduce namespaces to allow different stereotypes with the same name within the profile. >>>> >>>> -- Ed >>>> >>>> -----Original Message----- >>>> From: Rouquette, Nicolas F (313K) >>>> [mailto:nicolas.f.rouquette@jpl.nasa.gov] >>>> Sent: Wednesday, September 28, 2011 1:26 PM >>>> To: issues@omg.org >>>> Cc: uml-spec-simplification@omg.org; Tomas Juknevicius; >>>> uml-rtf@omg.org >>>> Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >>>> >>>> This is an issue for UML 2.4.1. >>>> >>>> In 18.3.7, the semantics for Profile incompletely describes how to "Use XMI to exhange Profiles" for the case where a "Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype." (18.3.9, Stereotype Semantics). > >>>> >>>> The Semantics section in 18.3.7 is missing the important constraints explaining some of the principles for the XMI serialization of the application of a Profile. >>>> The following constraints are consistent with the semantics of Stereotype Package containment specified in 18.3.9. >>>> >>>> 1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[XML namespace prefix of the Package containing the applied Stereotype]:[applied Stereotype name]>" >>>> >>>> This is illustrated in the HomeExample profile in Fig. 18.8 whose Package URI, "http://HomeExample/20101201/HomeExample.xmi", is associated to the XML namespace prefix "HomeExample". >>>> Therefore, the application of the Stereotype HomeExample::Home serializes into an XML Element tag of the form: "" as shown in the example. >>>> >>>> The spec is missing an example where a Stereotype is contained in a Package that is nested in a Profile. >>>> SysML 1.3 can provide ample material for such an example. >>>> >>>> 2) An XMI serializer must include in an XMI document all the XML namespace prefix declarations corresponding to all the container Packages of all Stereotypes whose application to an Element is serialized in that XMI document. >>>> >>>> In some cases, this means that the XML namespace prefix used for a particular Package may be different than the convention used for OMG normative profiles (See UML 2.4.1, 18.3.7) where the nsPrefix is the name of the Profile. >>>> >>>> 3) The owning Package of each Stereotype must have a Package::URI specified so that an XMI processor can: >>>> >>>> - generate an XML namespace prefix for that Package when one of its >>>> contained Stereotypes is applied >>>> >>>> - resolve a reference to an applied Stereotype to the Package containing the definition of the Stereotype via the XML namespace prefix used for the containing Package URI. >>>> >>>> This can be specified in OCL2.3 as follows: >>>> >>>> context Stereotype >>>> inv StereotypeContainerPackageMustHaveURI: >>>> self.owningPackage.URI->notEmpty() >>>> >>>> 4) All the Stereotype-containing Packages in a Profile regardless of nesting must have distinct Package URIs. >>>> >>>> This can be specified in OCL2.3 as follows: >>>> >>>> context Profile >>>> inv StereotypeContainingPackagesMustHaveDistinctURIs: >>>> let pkgs : Set(Package) = >>>> self->closure(nestedPackage)->including(self) in let allURIs : >>>> Bag(String) = pkgs.URI in let uniqueURIs : Set(String) = >>>> allURIs->asSet() in >>>> allURIs->size() = uniqueURIs->size() >>>> >>>> 5) The OMG normative profile convention in 18.3.7 must be updated to provide a sensible nsPrefix for the XML namespace corresponding to a nested Package in a Profile. >>>> >>>> The conventions in 18.3.7 was written at a time when UML 2.0 allowed Stereotypes to be directly contained in a Profile. >>>> The conventions need to be updated to provide a sensible rule for generating the nsPrefix for a Package nested in a Profile. >>>> >>>> I suggest using the "."-concatenated sequence of names of the UML Namespaces from the Profile to the nested Package. >>>> For example, the SysML 1.3 Profile is named "SysML" and it defines a nested package "SysML::Blocks". >>>> The suggested nsPrefix for the UML Package SysML::Blocks would be "SysML.Blocks". >>>> This name is legal per the normative criteria for XML namespace >>>> prefix names (see: http://www.w3.org/TR/REC-xml/#NT-Name) >>>> >>>> >>>> - Nicolas. >>> >> > > -- > 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. From: "Rouquette, Nicolas F (313K)" To: Ed Seidewitz CC: Tomas Juknevicius , "Jenkins, J Steven (3101)" , "uml-spec-simplification@omg.org" , "uml-rtf@omg.org" , "issues@omg.org" , Kenn Hussey Date: Thu, 29 Sep 2011 15:36:10 -0700 Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Topic: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Index: Acx++DDwo87NBxB5SYWM9AMZFWWXpw== 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 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8TMZsr8027804 Ed, Good point about Pete. In fact, MOF/XMI 2.4 (ptc/2010-12-06) includes in 7.8.1 (Namespace Qualified XML Element Names) the following paragraph: Each namespace is assigned a logical URI. The logical URI is placed in the namespace declaration of the top level element in XML documents that contain instances of the model. The XML namespace specification assigns logical names to namespaces that are expected to remain fixed throughout the life of all uses of the namespace since it provides a permanent global name for the resource. According to this, an XML processor must resolve "" according to the nsPrefix defined for SysML, that is: http://www.omg.org/spec/SysML/20110919/SysML which corresponds to the logical namespace for the SysML profile itself. I don't see how one could say in compliance with MOF/XMI 2.4 that "" could be interpreted to mean SysML::Blocks::Block at all. That would require a non-standard MOF/XMI processor. - Nicolas. On Sep 29, 2011, at 2:24 PM, Ed Seidewitz wrote: > Nicolas -- > > UML 2.4 Subclause 18.3.9 Stereotype includes the following paragraph at the end of the Semantics section: > > "A Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype. When profiles are applied to a Package, the available stereotypes for use as extensions are defined by the applied profiles, and theses [sic] stereotypes can be identified by the fully qualified name if needed in order to distinguish stereotypes with the same name in different profiles or packages. Package and element import can be used to allow the use of unqualified names. Stereotypes directly owned by an applied profile (ownedStereotype) may be used without qualified names." > > So, it would seem that the use of a qualified name when applying a stereotype is already allowed (though this statement should really be in the Notation section, not the Semantics section). The only issue is serialization in XMI. > > In UML 2.4 Subclause 18.37 it states that > > "For a Profile the URI attribute (inherited from package) is used to determine the nsURI to be used to identify instances of the profile in XMI." > > As you note, nothing is said about URIs for any subpackages. Even if you were to include URIs for the subpackages, there is no guidance in the specification on how those should be used, so any usage would be non-standard. As far as I can see, tools conforming to the standard can only expect to be able to use the profile URI. > > Any clarification in UML 2.5 has to be backwardly compatible with the interchange of profile and stereotype applications per UML 2.4. I can't see how to formulate your choice (b) to allow this. > > In the end, Pete Rivett (from whom we haven't heard so far on this) is responsible for writing the UML 2.5 clause that includes profiles. Pete needs to take all this into advisement in drafting that clause and then the submission team and, later, the submission reviewers can comment on it. Until then, I am not sure there is any more to be said. > > -- Ed > > -----Original Message----- > From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] > Sent: Thursday, September 29, 2011 12:43 PM > To: uml-spec-simplification@omg.org; uml-rtf@omg.org; issues@omg.org > Cc: Tomas Juknevicius; Jenkins, J Steven (3101) > Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. > > Yes, there is still the outstanding issue of clarifying how XMI serialization should work for profiles with nested packages. > > We currently have two proposals for solving this issue: > > a) add a constraint that, in the scope of a profile, stereotypes must have unique names regardless of their package container in that profile. > > This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" means that the Stereotype named [sname] must defined somewhere in the scope of the profile whose Package::URI is associated to [nsPrefix] > > b) add a constraint that each package containing a stereotype must have a Package::URI. > > This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" means that the Stereotype named [sname] must be defined as an owned type of the package whose Package::URI is associated to [nsPrefix] > > We need to discuss the pros/cons of each proposal. > > Either way, the specification will need clarifying language to: > - explain how XMI serialization works for profiles with nested packages > - improve the notation for UML stereotypes to show where a stereotype comes from. > > (a) may be simpler for a single profile and for some tools (e.g., JDeveloper and MagicDraw) but it is certainly not a scalable strategy. > > Consider this: > > Profile SysML4Testing imports SysML, UTP > > Now, I've got a name conflict due to SysML::Requirements::TestCase vs. UTP::TestCase > Clearly, the UML specification needs to improve the notation for stereotypes to include qualifying information such as the name of the profile or the name of the container package. > > In practice, (a) shifts the burden of compliance to profile-scope name unicity to profile developers. > For domain-specific language development with profiles, (a) is particularly annoying because we can't do simple things like this: > > Profile PF > Stereotype PF::Electrical::Function > Stereotype PF::Mechanical::Function > > Instead, (a) forces one to do something like this: > > Profile PF > Stereotype PF::Electrical::Electrical.Function > Stereotype PF::Mechanical::Mechanical.Function > > In tools that do (a) and only support the UML stereotype notation as specified, this can be a reasonable compromise, we get: <>, <>. > In tools that do (a) but extend the UML stereotype notation to show the name of the profile, we get: <>, <>. > > Either way, nested packages have no useful purpose -- this completely defeats the purpose they were added in UML 2.3. > > With (b), UML namespace distinguishability is enough for everybody; some tool vendors may have to do work to support this flexible scheme. > > For profile developers, we don't have to distort domain-specific concepts, e.g., we can do: > > Profile PF > Stereotype PF::Electrical::Function > Stereotype PF::Mechanical::Function > > The only thing missing is extending the UML stereotype notation to provide options for including qualifying name information such as: > - profile name + stereotype name > - profile name + stereotype package container name + stereotype name > - stereotype package container name + stereotype name > - N-segments of the stereotype's fully qualified name from the left + M-segments of the stereotype's fully qualified name from the right > > - Nicolas. > > On Sep 29, 2011, at 7:22 AM, Ed Seidewitz wrote: > >> There is also the issue of when we would be able to address the issue Nicolas has raised. >> >> I doubt there is going to be enough support to make this an urgent issue leading to UML 2.4.2. For what was supposed to be a stabilizing version before the spec simplification, UML 2.4 has seen enough churn as it is! >> >> We could certainly provide semantic clarification in UML 2.5. But if putting the new conventions for the use of profile package URIs into UML 2.5 would significantly change the interchange of models using profiles such as SysML. Without this guidance in UML 2.4, there will be no standard for tool vendors to follow and they will continue to use the current convention of :. Changing this in UML 2.5 would be a significant backward incompatibility in model interchange, which would violate the requirements of the RFP. >> >> So, I don't really see any other sensible course in UML 2.5 than to clarify that the stereotype names in a profile must all be distinct. This means adding an additional constraint that isn't in UML 2.4, but I don't think this will cause any problem with interchange backward compatibility, since the point of Nicolas' issue is that there isn't any standard way now anyway to handle stereotypes with the same name in different packages of a profile. >> >> I think it is still worth recording the issue as Nicolas proposes. Perhaps it can be discussed further in the UML 2.5 FTF. Or perhaps it is better to leave its resolution to be handled as part of submissions to the Metamodel Extension Facility RFP. >> >> -- Ed >> >> -----Original Message----- >> From: Dave Hawkins [mailto:dave.hawkins@oracle.com] >> Sent: Thursday, September 29, 2011 7:23 AM >> To: Rouquette, Nicolas F (313K) >> Cc: Ed Seidewitz; issues@omg.org; uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) >> Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >> >> Nicolas, >> >> I agree with Ed here, I really don't see why constraining the >> names of all classifiers within a profile or metamodel to be >> unique is a problem. Certainly it's the way we're approaching >> the issue in JDeveloper. You seem to be trying to make things >> much more complicated than necessary. >> >> I agree this isn't explicit in the specification. However it's >> implicit from the schema production rules isn't it? I'm under >> the impression that elements within a schema have to be >> uniquely named, although I wasn't able to find that constraint >> in the XML Schema specification when I looked just now. >> >> For your UML metamodel example. The unmerged superstructure >> doesn't have a URI, so it isn't actually usable as a metamodel >> for XMI serialisation. The classifiers with the same names >> also all refer to fragments of the same classifier, so they >> aren't really distinct definitions from a serialization >> perspective. >> >> For a profile, I really don't see why a constraint on the >> name uniqueness within that profile is a severe limitation. >> It seems like a sensible restriction to me. It doesn't >> seem to cause any issues in the UML metamodel and I'd have >> thought that's larger than the majority of profiles. It >> also means that you can use short 'fully qualified' names >> unambiguously: >> <> >> <> >> >> Cheers, >> >> Dave >> >> On 29/09/11 06:46, Rouquette, Nicolas F (313K) wrote: >>> Ed, >>> >>> Global name uniqueness in the scope of a profile or a metamodel is a bad idea. >>> >>> For a metamodel, I hope it suffices to point out that a tool could implement the unmerged UML 2.4.1 superstructure or the merged UML 2.4.1 metamodel. Since the semantics of UML PackageMerge stipulate that the two should be equivalent, the unmerged UML 2.4.1 superstructure is as much a metamodel as the merged UML 2.4.1 package is a metamodel. >>> >>> The UML superstructure is certainly an example where having different concepts with identical names can be problematic; however, that doesn't mean its necessarily bad in all cases. >>> The practice of UML metamodeling/profile development at the OMG is certainly not representative of the metamodeling/profile development practices outside the OMG. >>> >>> For a profile, I hope it suffices to point out that global name uniqueness for stereotypes would severely limit the extensibility of a profile -- once a name is used for defining a stereotype, that name couldn't be used for defining another stereotype in that profile even if it would be perfectly OK w.r.t. current UML namespace distinguishability rules. >>> >>> I believe the lure of global name uniqueness you allude to comes from the narrow view of the current UML notation which provides only two options: simple name or fully qualified name. >>> This two-option notation is very unsatisfactory in many cases even without name collision because we can't tell which profile<> comes from when it is applied to an element. >>> With colliding names, it's unsatisfactory within a profile and across profiles. For example, it is currently impossible to distinguish by current notation convention alone between SysML 1.3's TestCase vs. UTP 1.1's TestCase. The two concepts are very different but they are undistinguishable by notation alone, e.g.: >>> >>> <> A >>> <> B >>> >>> We shouldn't use the flimsy excuse that the current notation for stereotype uses the simple name as an excuse for suggesting that stereotypes should have unique names in the scope of a profile. >>> >>> Finally, this idea is triply-bad because it would severely compromise the value of Package::URI added in UML 2.4.1. >>> The value of this extension is that it allows us to make a strong correspondence between a UML package and arbitrary namespaces in the semantic web / world wide web. >>> >>> The suggestion that profiles, a special kind of package, would further impose an artificial global name uniqueness constraint that has no legitimate counterpart in practice provides is yet another factor to support my claim that this artificial constraint would be a very, very bad for UML. >>> >>> - Nicolas. >>> >>> >>> >>> On Sep 28, 2011, at 4:42 PM, Ed Seidewitz wrote: >>> >>>> Nicolas -- >>>> >>>> The Package::URI attribute was added because to allow MOF 2.4 to be a strict subset of UML 2.4, because MOF packages can have URIs. You are widening its purpose for profile packages. Perhaps one could make a correspondence between profile subpackages and MOF packages (similar to the correspondence between stereotypes and MOF classes), but the current spec certainly does not make that correspondence. >>>> >>>> It is already pretty much always the case that the classes in metamodels have distinct names, whatever the packaging (at least after package merging is done). And I think the same is true of stereotypes in profiles. In fact, I think this is probably a good constraint, because having multiple stereotypes with the same name in the same profile is sure to be confusing. >>>> >>>> -- Ed >>>> >>>> -----Original Message----- >>>> From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] >>>> Sent: Wednesday, September 28, 2011 7:18 PM >>>> To: Ed Seidewitz >>>> Cc: issues@omg.org; uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) >>>> Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >>>> >>>> Ed, >>>> >>>> I strongly disagree with you. >>>> >>>> The UML Profile mechanism is already very constraining; the constraint you suggest would further restrict what we can do. >>>> The constraint would effectively mean that a Package nested in a Profile would have no semantic value whatsoever. >>>> The Package::URI attribute gives UML Packages a small but very useful semantics, that of denoting an identified namespace. >>>> It would be ironic that this very capability we need for the severely under-specified XMI serialization for the application of a Profile >>>> would be the very same capability that the constraint you suggest would remove! >>>> >>>> - Nicolas. >>>> >>>> On Sep 28, 2011, at 3:40 PM, Ed Seidewitz wrote: >>>> >>>>> Nicolas -- >>>>> >>>>> It would seem simpler to just require that all the stereotypes in a profile have distinct names, whether they are directly owned by the profile or indirectly owned through a package within the profile. Then the current approach of profile nsPrefix plus stereotype name would be sufficient. And I don't think this would really be a serious restriction in practice, since packages are generally used organizationally in profiles, not to introduce namespaces to allow different stereotypes with the same name within the profile. >>>>> >>>>> -- Ed >>>>> >>>>> -----Original Message----- >>>>> From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] >>>>> Sent: Wednesday, September 28, 2011 1:26 PM >>>>> To: issues@omg.org >>>>> Cc: uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org >>>>> Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >>>>> >>>>> This is an issue for UML 2.4.1. >>>>> >>>>> In 18.3.7, the semantics for Profile incompletely describes how to "Use XMI to exhange Profiles" for the case where a "Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype." (18.3.9, Stereotype Semantics). >> >>>>> >>>>> The Semantics section in 18.3.7 is missing the important constraints explaining some of the principles for the XMI serialization of the application of a Profile. >>>>> The following constraints are consistent with the semantics of Stereotype Package containment specified in 18.3.9. >>>>> >>>>> 1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[XML namespace prefix of the Package containing the applied Stereotype]:[applied Stereotype name]>" >>>>> >>>>> This is illustrated in the HomeExample profile in Fig. 18.8 whose Package URI, "http://HomeExample/20101201/HomeExample.xmi", is associated to the XML namespace prefix "HomeExample". >>>>> Therefore, the application of the Stereotype HomeExample::Home serializes into an XML Element tag of the form: "" as shown in the example. >>>>> >>>>> The spec is missing an example where a Stereotype is contained in a Package that is nested in a Profile. >>>>> SysML 1.3 can provide ample material for such an example. >>>>> >>>>> 2) An XMI serializer must include in an XMI document all the XML namespace prefix declarations corresponding to all the container Packages of all Stereotypes whose application to an Element is serialized in that XMI document. >>>>> >>>>> In some cases, this means that the XML namespace prefix used for a particular Package may be different than the convention used for OMG normative profiles (See UML 2.4.1, 18.3.7) where the nsPrefix is the name of the Profile. >>>>> >>>>> 3) The owning Package of each Stereotype must have a Package::URI specified so that an XMI processor can: >>>>> >>>>> - generate an XML namespace prefix for that Package when one of its contained Stereotypes is applied >>>>> >>>>> - resolve a reference to an applied Stereotype to the Package containing the definition of the Stereotype via the XML namespace prefix used for the containing Package URI. >>>>> >>>>> This can be specified in OCL2.3 as follows: >>>>> >>>>> context Stereotype >>>>> inv StereotypeContainerPackageMustHaveURI: >>>>> self.owningPackage.URI->notEmpty() >>>>> >>>>> 4) All the Stereotype-containing Packages in a Profile regardless of nesting must have distinct Package URIs. >>>>> >>>>> This can be specified in OCL2.3 as follows: >>>>> >>>>> context Profile >>>>> inv StereotypeContainingPackagesMustHaveDistinctURIs: >>>>> let pkgs : Set(Package) = self->closure(nestedPackage)->including(self) in >>>>> let allURIs : Bag(String) = pkgs.URI in >>>>> let uniqueURIs : Set(String) = allURIs->asSet() in >>>>> allURIs->size() = uniqueURIs->size() >>>>> >>>>> 5) The OMG normative profile convention in 18.3.7 must be updated to provide a sensible nsPrefix for the XML namespace corresponding to a nested Package in a Profile. >>>>> >>>>> The conventions in 18.3.7 was written at a time when UML 2.0 allowed Stereotypes to be directly contained in a Profile. >>>>> The conventions need to be updated to provide a sensible rule for generating the nsPrefix for a Package nested in a Profile. >>>>> >>>>> I suggest using the "."-concatenated sequence of names of the UML Namespaces from the Profile to the nested Package. >>>>> For example, the SysML 1.3 Profile is named "SysML" and it defines a nested package "SysML::Blocks". >>>>> The suggested nsPrefix for the UML Package SysML::Blocks would be "SysML.Blocks". >>>>> This name is legal per the normative criteria for XML namespace prefix names (see: http://www.w3.org/TR/REC-xml/#NT-Name) >>>>> >>>>> >>>>> - Nicolas. >>>> >>> >> >> -- >> 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. > From: Ed Seidewitz To: "Rouquette, Nicolas F (313K)" CC: Tomas Juknevicius , "Jenkins, J Steven (3101)" , "uml-spec-simplification@omg.org" , "uml-rtf@omg.org" , "issues@omg.org" , Kenn Hussey Date: Thu, 29 Sep 2011 18:41:17 -0400 Subject: RE: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Topic: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Index: Acx++DDwo87NBxB5SYWM9AMZFWWXpwAAFRJg Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.225]|10.1.50.225|outbound.mailprotector.net|0|0|0|new|ugly|0|0|0|0 X-Mailprotector-Results: null_ptr subject_50_chars subject_10_spaces clean X-Mailprotector-Score: 80 X-Mailprotector-IP-Analysis: 0, 10.1.50.225, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-32767-c X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8TMes3O028174 Nicolas -- You have to be careful not to confuse XML namespaces with UML namespaces. The section of the XMI spec you quote is about XML namespaces and summarizes what the XML namespace standard. It does not say that XML namespaces correspond one-to-one to UML namespaces. A MOF package that represents a metamodel can have a single XML namespace (based on its package URI) for all elements that are either directly in the metamodel package or indirectly in subpackages. The same is true for profiles with subpackages. -- Ed -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, September 29, 2011 6:36 PM To: Ed Seidewitz Cc: Tomas Juknevicius; Jenkins, J Steven (3101); uml-spec-simplification@omg.org; uml-rtf@omg.org; issues@omg.org; Kenn Hussey Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Ed, Good point about Pete. In fact, MOF/XMI 2.4 (ptc/2010-12-06) includes in 7.8.1 (Namespace Qualified XML Element Names) the following paragraph: Each namespace is assigned a logical URI. The logical URI is placed in the namespace declaration of the top level element in XML documents that contain instances of the model. The XML namespace specification assigns logical names to namespaces that are expected to remain fixed throughout the life of all uses of the namespace since it provides a permanent global name for the resource. According to this, an XML processor must resolve "" according to the nsPrefix defined for SysML, that is: http://www.omg.org/spec/SysML/20110919/SysML which corresponds to the logical namespace for the SysML profile itself. I don't see how one could say in compliance with MOF/XMI 2.4 that "" could be interpreted to mean SysML::Blocks::Block at all. That would require a non-standard MOF/XMI processor. - Nicolas. On Sep 29, 2011, at 2:24 PM, Ed Seidewitz wrote: > Nicolas -- > > UML 2.4 Subclause 18.3.9 Stereotype includes the following paragraph at the end of the Semantics section: > > "A Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype. When profiles are applied to a Package, the available stereotypes for use as extensions are defined by the applied profiles, and theses [sic] stereotypes can be identified by the fully qualified name if needed in order to distinguish stereotypes with the same name in different profiles or packages. Package and element import can be used to allow the use of unqualified names. Stereotypes directly owned by an applied profile (ownedStereotype) may be used without qualified names." > > So, it would seem that the use of a qualified name when applying a stereotype is already allowed (though this statement should really be in the Notation section, not the Semantics section). The only issue is serialization in XMI. > > In UML 2.4 Subclause 18.37 it states that > > "For a Profile the URI attribute (inherited from package) is used to determine the nsURI to be used to identify instances of the profile in XMI." > > As you note, nothing is said about URIs for any subpackages. Even if you were to include URIs for the subpackages, there is no guidance in the specification on how those should be used, so any usage would be non-standard. As far as I can see, tools conforming to the standard can only expect to be able to use the profile URI. > > Any clarification in UML 2.5 has to be backwardly compatible with the interchange of profile and stereotype applications per UML 2.4. I can't see how to formulate your choice (b) to allow this. > > In the end, Pete Rivett (from whom we haven't heard so far on this) is responsible for writing the UML 2.5 clause that includes profiles. Pete needs to take all this into advisement in drafting that clause and then the submission team and, later, the submission reviewers can comment on it. Until then, I am not sure there is any more to be said. > > -- Ed > > -----Original Message----- > From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] > Sent: Thursday, September 29, 2011 12:43 PM > To: uml-spec-simplification@omg.org; uml-rtf@omg.org; issues@omg.org > Cc: Tomas Juknevicius; Jenkins, J Steven (3101) > Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. > > Yes, there is still the outstanding issue of clarifying how XMI serialization should work for profiles with nested packages. > > We currently have two proposals for solving this issue: > > a) add a constraint that, in the scope of a profile, stereotypes must have unique names regardless of their package container in that profile. > > This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" means that the Stereotype named [sname] must defined somewhere in the scope of the profile whose Package::URI is associated to [nsPrefix] > > b) add a constraint that each package containing a stereotype must have a Package::URI. > > This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" means that the Stereotype named [sname] must be defined as an owned type of the package whose Package::URI is associated to [nsPrefix] > > We need to discuss the pros/cons of each proposal. > > Either way, the specification will need clarifying language to: > - explain how XMI serialization works for profiles with nested packages > - improve the notation for UML stereotypes to show where a stereotype comes from. > > (a) may be simpler for a single profile and for some tools (e.g., JDeveloper and MagicDraw) but it is certainly not a scalable strategy. > > Consider this: > > Profile SysML4Testing imports SysML, UTP > > Now, I've got a name conflict due to SysML::Requirements::TestCase vs. UTP::TestCase > Clearly, the UML specification needs to improve the notation for stereotypes to include qualifying information such as the name of the profile or the name of the container package. > > In practice, (a) shifts the burden of compliance to profile-scope name unicity to profile developers. > For domain-specific language development with profiles, (a) is particularly annoying because we can't do simple things like this: > > Profile PF > Stereotype PF::Electrical::Function > Stereotype PF::Mechanical::Function > > Instead, (a) forces one to do something like this: > > Profile PF > Stereotype PF::Electrical::Electrical.Function > Stereotype PF::Mechanical::Mechanical.Function > > In tools that do (a) and only support the UML stereotype notation as specified, this can be a reasonable compromise, we get: <>, <>. > In tools that do (a) but extend the UML stereotype notation to show the name of the profile, we get: <>, <>. > > Either way, nested packages have no useful purpose -- this completely defeats the purpose they were added in UML 2.3. > > With (b), UML namespace distinguishability is enough for everybody; some tool vendors may have to do work to support this flexible scheme. > > For profile developers, we don't have to distort domain-specific concepts, e.g., we can do: > > Profile PF > Stereotype PF::Electrical::Function > Stereotype PF::Mechanical::Function > > The only thing missing is extending the UML stereotype notation to provide options for including qualifying name information such as: > - profile name + stereotype name > - profile name + stereotype package container name + stereotype name > - stereotype package container name + stereotype name > - N-segments of the stereotype's fully qualified name from the left + M-segments of the stereotype's fully qualified name from the right > > - Nicolas. > > On Sep 29, 2011, at 7:22 AM, Ed Seidewitz wrote: > >> There is also the issue of when we would be able to address the issue Nicolas has raised. >> >> I doubt there is going to be enough support to make this an urgent issue leading to UML 2.4.2. For what was supposed to be a stabilizing version before the spec simplification, UML 2.4 has seen enough churn as it is! >> >> We could certainly provide semantic clarification in UML 2.5. But if putting the new conventions for the use of profile package URIs into UML 2.5 would significantly change the interchange of models using profiles such as SysML. Without this guidance in UML 2.4, there will be no standard for tool vendors to follow and they will continue to use the current convention of :. Changing this in UML 2.5 would be a significant backward incompatibility in model interchange, which would violate the requirements of the RFP. >> >> So, I don't really see any other sensible course in UML 2.5 than to clarify that the stereotype names in a profile must all be distinct. This means adding an additional constraint that isn't in UML 2.4, but I don't think this will cause any problem with interchange backward compatibility, since the point of Nicolas' issue is that there isn't any standard way now anyway to handle stereotypes with the same name in different packages of a profile. >> >> I think it is still worth recording the issue as Nicolas proposes. Perhaps it can be discussed further in the UML 2.5 FTF. Or perhaps it is better to leave its resolution to be handled as part of submissions to the Metamodel Extension Facility RFP. >> >> -- Ed >> >> -----Original Message----- >> From: Dave Hawkins [mailto:dave.hawkins@oracle.com] >> Sent: Thursday, September 29, 2011 7:23 AM >> To: Rouquette, Nicolas F (313K) >> Cc: Ed Seidewitz; issues@omg.org; uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) >> Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >> >> Nicolas, >> >> I agree with Ed here, I really don't see why constraining the >> names of all classifiers within a profile or metamodel to be >> unique is a problem. Certainly it's the way we're approaching >> the issue in JDeveloper. You seem to be trying to make things >> much more complicated than necessary. >> >> I agree this isn't explicit in the specification. However it's >> implicit from the schema production rules isn't it? I'm under >> the impression that elements within a schema have to be >> uniquely named, although I wasn't able to find that constraint >> in the XML Schema specification when I looked just now. >> >> For your UML metamodel example. The unmerged superstructure >> doesn't have a URI, so it isn't actually usable as a metamodel >> for XMI serialisation. The classifiers with the same names >> also all refer to fragments of the same classifier, so they >> aren't really distinct definitions from a serialization >> perspective. >> >> For a profile, I really don't see why a constraint on the >> name uniqueness within that profile is a severe limitation. >> It seems like a sensible restriction to me. It doesn't >> seem to cause any issues in the UML metamodel and I'd have >> thought that's larger than the majority of profiles. It >> also means that you can use short 'fully qualified' names >> unambiguously: >> <> >> <> >> >> Cheers, >> >> Dave >> >> On 29/09/11 06:46, Rouquette, Nicolas F (313K) wrote: >>> Ed, >>> >>> Global name uniqueness in the scope of a profile or a metamodel is a bad idea. >>> >>> For a metamodel, I hope it suffices to point out that a tool could implement the unmerged UML 2.4.1 superstructure or the merged UML 2.4.1 metamodel. Since the semantics of UML PackageMerge stipulate that the two should be equivalent, the unmerged UML 2.4.1 superstructure is as much a metamodel as the merged UML 2.4.1 package is a metamodel. >>> >>> The UML superstructure is certainly an example where having different concepts with identical names can be problematic; however, that doesn't mean its necessarily bad in all cases. >>> The practice of UML metamodeling/profile development at the OMG is certainly not representative of the metamodeling/profile development practices outside the OMG. >>> >>> For a profile, I hope it suffices to point out that global name uniqueness for stereotypes would severely limit the extensibility of a profile -- once a name is used for defining a stereotype, that name couldn't be used for defining another stereotype in that profile even if it would be perfectly OK w.r.t. current UML namespace distinguishability rules. >>> >>> I believe the lure of global name uniqueness you allude to comes from the narrow view of the current UML notation which provides only two options: simple name or fully qualified name. >>> This two-option notation is very unsatisfactory in many cases even without name collision because we can't tell which profile<> comes from when it is applied to an element. >>> With colliding names, it's unsatisfactory within a profile and across profiles. For example, it is currently impossible to distinguish by current notation convention alone between SysML 1.3's TestCase vs. UTP 1.1's TestCase. The two concepts are very different but they are undistinguishable by notation alone, e.g.: >>> >>> <> A >>> <> B >>> >>> We shouldn't use the flimsy excuse that the current notation for stereotype uses the simple name as an excuse for suggesting that stereotypes should have unique names in the scope of a profile. >>> >>> Finally, this idea is triply-bad because it would severely compromise the value of Package::URI added in UML 2.4.1. >>> The value of this extension is that it allows us to make a strong correspondence between a UML package and arbitrary namespaces in the semantic web / world wide web. >>> >>> The suggestion that profiles, a special kind of package, would further impose an artificial global name uniqueness constraint that has no legitimate counterpart in practice provides is yet another factor to support my claim that this artificial constraint would be a very, very bad for UML. >>> >>> - Nicolas. >>> >>> >>> >>> On Sep 28, 2011, at 4:42 PM, Ed Seidewitz wrote: >>> >>>> Nicolas -- >>>> >>>> The Package::URI attribute was added because to allow MOF 2.4 to be a strict subset of UML 2.4, because MOF packages can have URIs. You are widening its purpose for profile packages. Perhaps one could make a correspondence between profile subpackages and MOF packages (similar to the correspondence between stereotypes and MOF classes), but the current spec certainly does not make that correspondence. >>>> >>>> It is already pretty much always the case that the classes in metamodels have distinct names, whatever the packaging (at least after package merging is done). And I think the same is true of stereotypes in profiles. In fact, I think this is probably a good constraint, because having multiple stereotypes with the same name in the same profile is sure to be confusing. >>>> >>>> -- Ed >>>> >>>> -----Original Message----- >>>> From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] >>>> Sent: Wednesday, September 28, 2011 7:18 PM >>>> To: Ed Seidewitz >>>> Cc: issues@omg.org; uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) >>>> Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >>>> >>>> Ed, >>>> >>>> I strongly disagree with you. >>>> >>>> The UML Profile mechanism is already very constraining; the constraint you suggest would further restrict what we can do. >>>> The constraint would effectively mean that a Package nested in a Profile would have no semantic value whatsoever. >>>> The Package::URI attribute gives UML Packages a small but very useful semantics, that of denoting an identified namespace. >>>> It would be ironic that this very capability we need for the severely under-specified XMI serialization for the application of a Profile >>>> would be the very same capability that the constraint you suggest would remove! >>>> >>>> - Nicolas. >>>> >>>> On Sep 28, 2011, at 3:40 PM, Ed Seidewitz wrote: >>>> >>>>> Nicolas -- >>>>> >>>>> It would seem simpler to just require that all the stereotypes in a profile have distinct names, whether they are directly owned by the profile or indirectly owned through a package within the profile. Then the current approach of profile nsPrefix plus stereotype name would be sufficient. And I don't think this would really be a serious restriction in practice, since packages are generally used organizationally in profiles, not to introduce namespaces to allow different stereotypes with the same name within the profile. >>>>> >>>>> -- Ed >>>>> >>>>> -----Original Message----- >>>>> From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] >>>>> Sent: Wednesday, September 28, 2011 1:26 PM >>>>> To: issues@omg.org >>>>> Cc: uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org >>>>> Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. >>>>> >>>>> This is an issue for UML 2.4.1. >>>>> >>>>> In 18.3.7, the semantics for Profile incompletely describes how to "Use XMI to exhange Profiles" for the case where a "Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype." (18.3.9, Stereotype Semantics). >> >>>>> >>>>> The Semantics section in 18.3.7 is missing the important constraints explaining some of the principles for the XMI serialization of the application of a Profile. >>>>> The following constraints are consistent with the semantics of Stereotype Package containment specified in 18.3.9. >>>>> >>>>> 1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[XML namespace prefix of the Package containing the applied Stereotype]:[applied Stereotype name]>" >>>>> >>>>> This is illustrated in the HomeExample profile in Fig. 18.8 whose Package URI, "http://HomeExample/20101201/HomeExample.xmi", is associated to the XML namespace prefix "HomeExample". >>>>> Therefore, the application of the Stereotype HomeExample::Home serializes into an XML Element tag of the form: "" as shown in the example. >>>>> >>>>> The spec is missing an example where a Stereotype is contained in a Package that is nested in a Profile. >>>>> SysML 1.3 can provide ample material for such an example. >>>>> >>>>> 2) An XMI serializer must include in an XMI document all the XML namespace prefix declarations corresponding to all the container Packages of all Stereotypes whose application to an Element is serialized in that XMI document. >>>>> >>>>> In some cases, this means that the XML namespace prefix used for a particular Package may be different than the convention used for OMG normative profiles (See UML 2.4.1, 18.3.7) where the nsPrefix is the name of the Profile. >>>>> >>>>> 3) The owning Package of each Stereotype must have a Package::URI specified so that an XMI processor can: >>>>> >>>>> - generate an XML namespace prefix for that Package when one of its contained Stereotypes is applied >>>>> >>>>> - resolve a reference to an applied Stereotype to the Package containing the definition of the Stereotype via the XML namespace prefix used for the containing Package URI. >>>>> >>>>> This can be specified in OCL2.3 as follows: >>>>> >>>>> context Stereotype >>>>> inv StereotypeContainerPackageMustHaveURI: >>>>> self.owningPackage.URI->notEmpty() >>>>> >>>>> 4) All the Stereotype-containing Packages in a Profile regardless of nesting must have distinct Package URIs. >>>>> >>>>> This can be specified in OCL2.3 as follows: >>>>> >>>>> context Profile >>>>> inv StereotypeContainingPackagesMustHaveDistinctURIs: >>>>> let pkgs : Set(Package) = self->closure(nestedPackage)->including(self) in >>>>> let allURIs : Bag(String) = pkgs.URI in >>>>> let uniqueURIs : Set(String) = allURIs->asSet() in >>>>> allURIs->size() = uniqueURIs->size() >>>>> >>>>> 5) The OMG normative profile convention in 18.3.7 must be updated to provide a sensible nsPrefix for the XML namespace corresponding to a nested Package in a Profile. >>>>> >>>>> The conventions in 18.3.7 was written at a time when UML 2.0 allowed Stereotypes to be directly contained in a Profile. >>>>> The conventions need to be updated to provide a sensible rule for generating the nsPrefix for a Package nested in a Profile. >>>>> >>>>> I suggest using the "."-concatenated sequence of names of the UML Namespaces from the Profile to the nested Package. >>>>> For example, the SysML 1.3 Profile is named "SysML" and it defines a nested package "SysML::Blocks". >>>>> The suggested nsPrefix for the UML Package SysML::Blocks would be "SysML.Blocks". >>>>> This name is legal per the normative criteria for XML namespace prefix names (see: http://www.w3.org/TR/REC-xml/#NT-Name) >>>>> >>>>> >>>>> - Nicolas. >>>> >>> >> >> -- >> 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. > From: "Rouquette, Nicolas F (313K)" To: Pete Rivett CC: Ed Seidewitz , Tomas Juknevicius , "Jenkins, J Steven (3101)" , "uml-spec-simplification@omg.org" , "uml-rtf@omg.org" Date: Thu, 29 Sep 2011 16:07:42 -0700 Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Topic: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Index: Acx+/Je4yAngGZapReejl0bKBRSqyA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8TN7Msc029760 Pete: Have you really analyzed the implications of what you are saying? This amounts to a radical weakening of Package::URI as currently specified in UML 2.4.1 and as used in MOF/XMI 2.4 - Nicolas. On Sep 29, 2011, at 2:53 PM, Pete Rivett wrote: > On the substantive question - whether the nsURI for a Profile should > apply to all of its non-profile sub-packages - then I agree with Ed that > it should. > In other words the sub-packages are for management of the profile > elements not for any application purposes. > That I believe reflects the consensus from a long thread we had in the > UML RTF around proposals from Jim Amsden. > And it provides maximum flexibility - if you want a separate nsURI then > you can always turn the sub-package into a sub-profile. > > Pete From: "Pete Rivett" To: thread-index: Acx+/Je4yAngGZapReejl0bKBRSqyAACx8Ey Cc: , , , , Thread-Topic: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Date: Thu, 29 Sep 2011 20:27:20 -0400 (EDT) X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8U0QvXS003880 No I don't see the implications you mean. As Ed wrote, there is a difference between the uri used to reference the package itself and what is used for the namespace when serializing its instances. Sent from my Verizon Wireless Phone ----- Reply message ----- From: "Rouquette, Nicolas F (313K)" Date: Thu, Sep 29, 2011 4:08 pm Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. To: "Pete Rivett" Cc: "Ed Seidewitz" , "Tomas Juknevicius" , "Jenkins, J Steven (3101)" , "uml-spec-simplification@omg.org" , "uml-rtf@omg.org" Pete: Have you really analyzed the implications of what you are saying? This amounts to a radical weakening of Package::URI as currently specified in UML 2.4.1 and as used in MOF/XMI 2.4 - Nicolas. On Sep 29, 2011, at 2:53 PM, Pete Rivett wrote: > On the substantive question - whether the nsURI for a Profile should > apply to all of its non-profile sub-packages - then I agree with Ed that > it should. > In other words the sub-packages are for management of the profile > elements not for any application purposes. > That I believe reflects the consensus from a long thread we had in the > UML RTF around proposals from Jim Amsden. > And it provides maximum flexibility - if you want a separate nsURI then > you can always turn the sub-package into a sub-profile. > > Pete From: "Rouquette, Nicolas F (313K)" To: Pete Rivett CC: "uml-rtf@omg.org" , "tomasjkn@nomagic.com" , "ed-s@modeldriven.com" , "uml-spec-simplification@omg.org" , "Jenkins, J Steven (3101)" Date: Thu, 29 Sep 2011 18:53:02 -0700 Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Topic: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Index: Acx/E7Dr99yFCqeZTIyRXMa6CLafOQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8U1qh1b011124 You claim that: >> the nsURI for a Profile should >> apply to all of its non-profile sub-packages then it should follow that: 1) if a profile P1 has a nested profile P2, then the stereotypes defined in P2 are to be serialized using P2's nsURI, not P1's. 2) the Package::URI for a non-profile sub-package is semantically irrelevant even if it is specified. Is this consistent with the difference you are making for XMI serialization of profiles & nested packages/profiles? - Nicolas. On Sep 29, 2011, at 5:27 PM, Pete Rivett wrote: > > No I don't see the implications you mean. As Ed wrote, there is a difference between the uri used to > reference the package itself and what is used for the namespace when serializing its instances. > > Sent from my Verizon Wireless Phone > > > > ----- Reply message ----- > From: "Rouquette, Nicolas F (313K)" > Date: Thu, Sep 29, 2011 4:08 pm > Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. > To: "Pete Rivett" > Cc: "Ed Seidewitz" , "Tomas Juknevicius" , "Jenkins, J Steven (3101)" , "uml-spec-simplification@omg.org" , "uml-rtf@omg.org" > > Pete: > > Have you really analyzed the implications of what you are saying? > > This amounts to a radical weakening of Package::URI as currently specified in UML 2.4.1 and as used in MOF/XMI 2.4 > > - Nicolas. > > On Sep 29, 2011, at 2:53 PM, Pete Rivett wrote: > >> On the substantive question - whether the nsURI for a Profile should >> apply to all of its non-profile sub-packages - then I agree with Ed that >> it should. >> In other words the sub-packages are for management of the profile >> elements not for any application purposes. >> That I believe reflects the consensus from a long thread we had in the >> UML RTF around proposals from Jim Amsden. >> And it provides maximum flexibility - if you want a separate nsURI then >> you can always turn the sub-package into a sub-profile. >> >> Pete > Date: Fri, 30 Sep 2011 17:17:26 +0100 From: Dave Hawkins User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0 To: Ed Seidewitz CC: "uml-spec-simplification@omg.org" , "uml-rtf@omg.org" , Tomas Juknevicius , "Jenkins, J Steven (3101)" Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090208.4E85EBAD.002D,ss=1,re=1.599,fgs=0 Having sub-profiles isn't quite so straightforward though is it? How does that work with profile application, which I don't think has been mentioned in this thread? Which profiles would you need to apply? Having seen Nicolas's second Function example, I'm understanding what he's trying to do better. Using URIs on subpackages makes sense there, although it does mean the notation is a little more verbose. However, I don't think you'd want to require a URI on each subpackage and so a constraint on the uniqueness of names within the scope of a URI is still necessary. Cheers, Dave On 29/09/11 23:01, Ed Seidewitz wrote: Pete said: "Likewise in diagrams, tools usually provide the option of displaying (or not) the ownership/qualified name of an element." Yes, that's why the paragraph I quoted from the spec on qualified names for stereotypes belongs under notation, not semantics. It is still worth mentioning, though, just to make it clear that using a qualified name in the stereotype guillemet notation is a legal presentation option. "if you want a separate nsURI then you can always turn the sub-package into a sub-profile." Exactly! This is a key point. I wish I had thought to mention it earlier myself! -- Ed -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, September 29, 2011 5:53 PM To: Ed Seidewitz; Rouquette, Nicolas F (313K) Cc: Tomas Juknevicius; Jenkins, J Steven (3101); uml-spec-simplification@omg.org; uml-rtf@omg.org Subject: RE: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. I don't see the relevance of the naming part of this discussion/quotations since stereotypes are never accessed/identified by name (qualified or otherwise): they are explicitly referenced as elements (both in the tool and the XMI). That's even true of the user interface of most tools - the modeler typically selects the stereotypes from a list (where they are shown with the qualified name). Likewise in diagrams, tools usually provide the option of displaying (or not) the ownership/qualified name of an element. As I've said many times, import statements are pretty useless in practice since, as currently documented, they only affect naming. Even outside stereotype application, references by name are very infrequent - typically only in OpaqueExpressions (e.g. as used for OCL Constraints). That's the problem of basing a modeling language on a programming language paradigm . On the substantive question - whether the nsURI for a Profile should apply to all of its non-profile sub-packages - then I agree with Ed that it should. In other words the sub-packages are for management of the profile elements not for any application purposes. That I believe reflects the consensus from a long thread we had in the UML RTF around proposals from Jim Amsden. And it provides maximum flexibility - if you want a separate nsURI then you can always turn the sub-package into a sub-profile. Pete -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, September 29, 2011 2:25 PM To: Rouquette, Nicolas F (313K) Cc: Tomas Juknevicius; Jenkins, J Steven (3101); uml-spec-simplification@omg.org; uml-rtf@omg.org; issues@omg.org Subject: RE: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Nicolas -- UML 2.4 Subclause 18.3.9 Stereotype includes the following paragraph at the end of the Semantics section: "A Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype. When profiles are applied to a Package, the available stereotypes for use as extensions are defined by the applied profiles, and theses [sic] stereotypes can be identified by the fully qualified name if needed in order to distinguish stereotypes with the same name in different profiles or packages. Package and element import can be used to allow the use of unqualified names. Stereotypes directly owned by an applied profile (ownedStereotype) may be used without qualified names." So, it would seem that the use of a qualified name when applying a stereotype is already allowed (though this statement should really be in the Notation section, not the Semantics section). The only issue is serialization in XMI. In UML 2.4 Subclause 18.37 it states that "For a Profile the URI attribute (inherited from package) is used to determine the nsURI to be used to identify instances of the profile in XMI." As you note, nothing is said about URIs for any subpackages. Even if you were to include URIs for the subpackages, there is no guidance in the specification on how those should be used, so any usage would be non-standard. As far as I can see, tools conforming to the standard can only expect to be able to use the profile URI. Any clarification in UML 2.5 has to be backwardly compatible with the interchange of profile and stereotype applications per UML 2.4. I can't see how to formulate your choice (b) to allow this. In the end, Pete Rivett (from whom we haven't heard so far on this) is responsible for writing the UML 2.5 clause that includes profiles. Pete needs to take all this into advisement in drafting that clause and then the submission team and, later, the submission reviewers can comment on it. Until then, I am not sure there is any more to be said. -- Ed -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, September 29, 2011 12:43 PM To: uml-spec-simplification@omg.org; uml-rtf@omg.org; issues@omg.org Cc: Tomas Juknevicius; Jenkins, J Steven (3101) Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Yes, there is still the outstanding issue of clarifying how XMI serialization should work for profiles with nested packages. We currently have two proposals for solving this issue: a) add a constraint that, in the scope of a profile, stereotypes must have unique names regardless of their package container in that profile. This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" means that the Stereotype named [sname] must defined somewhere in the scope of the profile whose Package::URI is associated to [nsPrefix] b) add a constraint that each package containing a stereotype must have a Package::URI. This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" means that the Stereotype named [sname] must be defined as an owned type of the package whose Package::URI is associated to [nsPrefix] We need to discuss the pros/cons of each proposal. Either way, the specification will need clarifying language to: - explain how XMI serialization works for profiles with nested packages - improve the notation for UML stereotypes to show where a stereotype comes from. (a) may be simpler for a single profile and for some tools (e.g., JDeveloper and MagicDraw) but it is certainly not a scalable strategy. Consider this: Profile SysML4Testing imports SysML, UTP Now, I've got a name conflict due to SysML::Requirements::TestCase vs. UTP::TestCase Clearly, the UML specification needs to improve the notation for stereotypes to include qualifying information such as the name of the profile or the name of the container package. In practice, (a) shifts the burden of compliance to profile-scope name unicity to profile developers. For domain-specific language development with profiles, (a) is particularly annoying because we can't do simple things like this: Profile PF Stereotype PF::Electrical::Function Stereotype PF::Mechanical::Function Instead, (a) forces one to do something like this: Profile PF Stereotype PF::Electrical::Electrical.Function Stereotype PF::Mechanical::Mechanical.Function In tools that do (a) and only support the UML stereotype notation as specified, this can be a reasonable compromise, we get: <>,<>. In tools that do (a) but extend the UML stereotype notation to show the name of the profile, we get:<>, <>. Either way, nested packages have no useful purpose -- this completely defeats the purpose they were added in UML 2.3. With (b), UML namespace distinguishability is enough for everybody; some tool vendors may have to do work to support this flexible scheme. For profile developers, we don't have to distort domain-specific concepts, e.g., we can do: Profile PF Stereotype PF::Electrical::Function Stereotype PF::Mechanical::Function The only thing missing is extending the UML stereotype notation to provide options for including qualifying name information such as: - profile name + stereotype name - profile name + stereotype package container name + stereotype name - stereotype package container name + stereotype name - N-segments of the stereotype's fully qualified name from the left + M-segments of the stereotype's fully qualified name from the right - Nicolas. On Sep 29, 2011, at 7:22 AM, Ed Seidewitz wrote: There is also the issue of when we would be able to address the issue Nicolas has raised. I doubt there is going to be enough support to make this an urgent issue leading to UML 2.4.2. For what was supposed to be a stabilizing version before the spec simplification, UML 2.4 has seen enough churn as it is! We could certainly provide semantic clarification in UML 2.5. But if putting the new conventions for the use of profile package URIs into UML 2.5 would significantly change the interchange of models using profiles such as SysML. Without this guidance in UML 2.4, there will be no standard for tool vendors to follow and they will continue to use the current convention of:. Changing this in UML 2.5 would be a significant backward incompatibility in model interchange, which would violate the requirements of the RFP. So, I don't really see any other sensible course in UML 2.5 than to clarify that the stereotype names in a profile must all be distinct. This means adding an additional constraint that isn't in UML 2.4, but I don't think this will cause any problem with interchange backward compatibility, since the point of Nicolas' issue is that there isn't any standard way now anyway to handle stereotypes with the same name in different packages of a profile. I think it is still worth recording the issue as Nicolas proposes. Perhaps it can be discussed further in the UML 2.5 FTF. Or perhaps it is better to leave its resolution to be handled as part of submissions to the Metamodel Extension Facility RFP. -- Ed -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: Thursday, September 29, 2011 7:23 AM To: Rouquette, Nicolas F (313K) Cc: Ed Seidewitz; issues@omg.org; uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Nicolas, I agree with Ed here, I really don't see why constraining the names of all classifiers within a profile or metamodel to be unique is a problem. Certainly it's the way we're approaching the issue in JDeveloper. You seem to be trying to make things much more complicated than necessary. I agree this isn't explicit in the specification. However it's implicit from the schema production rules isn't it? I'm under the impression that elements within a schema have to be uniquely named, although I wasn't able to find that constraint in the XML Schema specification when I looked just now. For your UML metamodel example. The unmerged superstructure doesn't have a URI, so it isn't actually usable as a metamodel for XMI serialisation. The classifiers with the same names also all refer to fragments of the same classifier, so they aren't really distinct definitions from a serialization perspective. For a profile, I really don't see why a constraint on the name uniqueness within that profile is a severe limitation. It seems like a sensible restriction to me. It doesn't seem to cause any issues in the UML metamodel and I'd have thought that's larger than the majority of profiles. It also means that you can use short 'fully qualified' names unambiguously: <> <> Cheers, Dave On 29/09/11 06:46, Rouquette, Nicolas F (313K) wrote: Ed, Global name uniqueness in the scope of a profile or a metamodel is a bad idea. For a metamodel, I hope it suffices to point out that a tool could implement the unmerged UML 2.4.1 superstructure or the merged UML 2.4.1 metamodel. Since the semantics of UML PackageMerge stipulate that the two should be equivalent, the unmerged UML 2.4.1 superstructure is as much a metamodel as the merged UML 2.4.1 package is a metamodel. The UML superstructure is certainly an example where having different concepts with identical names can be problematic; however, that doesn't mean its necessarily bad in all cases. The practice of UML metamodeling/profile development at the OMG is certainly not representative of the metamodeling/profile development practices outside the OMG. For a profile, I hope it suffices to point out that global name uniqueness for stereotypes would severely limit the extensibility of a profile -- once a name is used for defining a stereotype, that name couldn't be used for defining another stereotype in that profile even if it would be perfectly OK w.r.t. current UML namespace distinguishability rules. I believe the lure of global name uniqueness you allude to comes from the narrow view of the current UML notation which provides only two options: simple name or fully qualified name. This two-option notation is very unsatisfactory in many cases even without name collision because we can't tell which profile<> comes from when it is applied to an element. With colliding names, it's unsatisfactory within a profile and across profiles. For example, it is currently impossible to distinguish by current notation convention alone between SysML 1.3's TestCase vs. UTP 1.1's TestCase. The two concepts are very different but they are undistinguishable by notation alone, e.g.: <> A <> B We shouldn't use the flimsy excuse that the current notation for stereotype uses the simple name as an excuse for suggesting that stereotypes should have unique names in the scope of a profile. Finally, this idea is triply-bad because it would severely compromise the value of Package::URI added in UML 2.4.1. The value of this extension is that it allows us to make a strong correspondence between a UML package and arbitrary namespaces in the semantic web / world wide web. The suggestion that profiles, a special kind of package, would further impose an artificial global name uniqueness constraint that has no legitimate counterpart in practice provides is yet another factor to support my claim that this artificial constraint would be a very, very bad for UML. - Nicolas. On Sep 28, 2011, at 4:42 PM, Ed Seidewitz wrote: Nicolas -- The Package::URI attribute was added because to allow MOF 2.4 to be a strict subset of UML 2.4, because MOF packages can have URIs. You are widening its purpose for profile packages. Perhaps one could make a correspondence between profile subpackages and MOF packages (similar to the correspondence between stereotypes and MOF classes), but the current spec certainly does not make that correspondence. It is already pretty much always the case that the classes in metamodels have distinct names, whatever the packaging (at least after package merging is done). And I think the same is true of stereotypes in profiles. In fact, I think this is probably a good constraint, because having multiple stereotypes with the same name in the same profile is sure to be confusing. -- Ed -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, September 28, 2011 7:18 PM To: Ed Seidewitz Cc: issues@omg.org; uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Ed, I strongly disagree with you. The UML Profile mechanism is already very constraining; the constraint you suggest would further restrict what we can do. The constraint would effectively mean that a Package nested in a Profile would have no semantic value whatsoever. The Package::URI attribute gives UML Packages a small but very useful semantics, that of denoting an identified namespace. It would be ironic that this very capability we need for the severely under-specified XMI serialization for the application of a Profile would be the very same capability that the constraint you suggest would remove! - Nicolas. On Sep 28, 2011, at 3:40 PM, Ed Seidewitz wrote: Nicolas -- It would seem simpler to just require that all the stereotypes in a profile have distinct names, whether they are directly owned by the profile or indirectly owned through a package within the profile. Then the current approach of profile nsPrefix plus stereotype name would be sufficient. And I don't think this would really be a serious restriction in practice, since packages are generally used organizationally in profiles, not to introduce namespaces to allow different stereotypes with the same name within the profile. -- Ed -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, September 28, 2011 1:26 PM To: issues@omg.org Cc: uml-spec-simplification@omg.org; Tomas Juknevicius; uml-rtf@omg.org Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. This is an issue for UML 2.4.1. In 18.3.7, the semantics for Profile incompletely describes how to "Use XMI to exhange Profiles" for the case where a "Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype." (18.3.9, Stereotype Semantics). The Semantics section in 18.3.7 is missing the important constraints explaining some of the principles for the XMI serialization of the application of a Profile. The following constraints are consistent with the semantics of Stereotype Package containment specified in 18.3.9. 1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[XML namespace prefix of the Package containing the applied Stereotype]:[applied Stereotype name]>" This is illustrated in the HomeExample profile in Fig. 18.8 whose Package URI, "http://HomeExample/20101201/HomeExample.xmi", is associated to the XML namespace prefix "HomeExample". Therefore, the application of the Stereotype HomeExample::Home serializes into an XML Element tag of the form: "" as shown in the example. The spec is missing an example where a Stereotype is contained in a Package that is nested in a Profile. SysML 1.3 can provide ample material for such an example. 2) An XMI serializer must include in an XMI document all the XML namespace prefix declarations corresponding to all the container Packages of all Stereotypes whose application to an Element is serialized in that XMI document. In some cases, this means that the XML namespace prefix used for a particular Package may be different than the convention used for OMG normative profiles (See UML 2.4.1, 18.3.7) where the nsPrefix is the name of the Profile. 3) The owning Package of each Stereotype must have a Package::URI specified so that an XMI processor can: - generate an XML namespace prefix for that Package when one of its contained Stereotypes is applied - resolve a reference to an applied Stereotype to the Package containing the definition of the Stereotype via the XML namespace prefix used for the containing Package URI. This can be specified in OCL2.3 as follows: context Stereotype inv StereotypeContainerPackageMustHaveURI: self.owningPackage.URI->notEmpty() 4) All the Stereotype-containing Packages in a Profile regardless of nesting must have distinct Package URIs. This can be specified in OCL2.3 as follows: context Profile inv StereotypeContainingPackagesMustHaveDistinctURIs: let pkgs : Set(Package) = self->closure(nestedPackage)->including(self) in let allURIs : Bag(String) = pkgs.URI in let uniqueURIs : Set(String) = allURIs->asSet() in allURIs->size() = uniqueURIs->size() 5) The OMG normative profile convention in 18.3.7 must be updated to provide a sensible nsPrefix for the XML namespace corresponding to a nested Package in a Profile. The conventions in 18.3.7 was written at a time when UML 2.0 allowed Stereotypes to be directly contained in a Profile. The conventions need to be updated to provide a sensible rule for generating the nsPrefix for a Package nested in a Profile. I suggest using the "."-concatenated sequence of names of the UML Namespaces from the Profile to the nested Package. For example, the SysML 1.3 Profile is named "SysML" and it defines a nested package "SysML::Blocks". The suggested nsPrefix for the UML Package SysML::Blocks would be "SysML.Blocks". This name is legal per the normative criteria for XML namespace prefix names (see: http://www.w3.org/TR/REC-xml/#NT-Name) - Nicolas. -- 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. -- 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. From: Ed Seidewitz To: Dave Hawkins CC: "uml-spec-simplification@omg.org" , "uml-rtf@omg.org" , Tomas Juknevicius , "Jenkins, J Steven (3101)" Date: Fri, 30 Sep 2011 12:58:54 -0400 Subject: RE: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Topic: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Thread-Index: Acx/jIFVlVHyvzPOTAqPDsT0wWqVFgABQrAw Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.226]|10.1.50.226|outbound.mailprotector.net|0|0|0|new|ugly|0|0|0|0 X-Mailprotector-Results: null_ptr subject_50_chars subject_10_spaces clean X-Mailprotector-Score: 80 X-Mailprotector-IP-Analysis: 0, 10.1.50.226, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-32767-c X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8UGwSEG029637 Dave -- This is covered in the Semantics section of Subclause 18.3.8 Profile Application, which says in the first paragraph "Applying a profile means recursively applying all its nested and imported [profiles]." (The spec is actually unfortunately missing the final word "profiles", but that was what was intended to be in the sentence.) A later paragraph adds: "A nested profile can be applied individually. However, the nested profile must specify any required metaclass and/or metamodel references if it contains any stereotypes and may use PackageImport to indicate other dependent packages. Metaclass and/or metamodel references are not inherited from a containing profile." As Pete noted previously, the current semantics for nested packages and profiles are the result of a great deal of discussion on the RTF that had to balance quite a few conflicting desires, as well as take into account the common practices on the use of nested packages and profiles in existing standard profiles that actually did not really conform to the spec prior to UML 2.3. -- Ed -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: Friday, September 30, 2011 12:17 PM To: Ed Seidewitz Cc: uml-spec-simplification@omg.org; uml-rtf@omg.org; Tomas Juknevicius; Jenkins, J Steven (3101) Subject: Re: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. Having sub-profiles isn't quite so straightforward though is it? How does that work with profile application, which I don't think has been mentioned in this thread? Which profiles would you need to apply? Having seen Nicolas's second Function example, I'm understanding what he's trying to do better. Using URIs on subpackages makes sense there, although it does mean the notation is a little more verbose. However, I don't think you'd want to require a URI on each subpackage and so a constraint on the uniqueness of names within the scope of a URI is still necessary. Cheers, Dave On 29/09/11 23:01, Ed Seidewitz wrote: > Pete said: > > "Likewise in diagrams, tools usually provide the option of displaying (or not) the ownership/qualified name of an element." > > Yes, that's why the paragraph I quoted from the spec on qualified names for stereotypes belongs under notation, not semantics. It is still worth mentioning, though, just to make it clear that using a qualified name in the stereotype guillemet notation is a legal presentation option. > > "if you want a separate nsURI then you can always turn the sub-package into a sub-profile." > > Exactly! This is a key point. I wish I had thought to mention it earlier myself! > > -- Ed > > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: Thursday, September 29, 2011 5:53 PM > To: Ed Seidewitz; Rouquette, Nicolas F (313K) > Cc: Tomas Juknevicius; Jenkins, J Steven (3101); uml-spec-simplification@omg.org; uml-rtf@omg.org > Subject: RE: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. > > I don't see the relevance of the naming part of this > discussion/quotations since stereotypes are never accessed/identified by > name (qualified or otherwise): they are explicitly referenced as > elements (both in the tool and the XMI). > That's even true of the user interface of most tools - the modeler > typically selects the stereotypes from a list (where they are shown with > the qualified name). > Likewise in diagrams, tools usually provide the option of displaying (or > not) the ownership/qualified name of an element. > > As I've said many times, import statements are pretty useless in > practice since, as currently documented, they only affect naming. Even > outside stereotype application, references by name are very infrequent - > typically only in OpaqueExpressions (e.g. as used for OCL Constraints). > That's the problem of basing a modeling language on a programming > language paradigm . > > On the substantive question - whether the nsURI for a Profile should > apply to all of its non-profile sub-packages - then I agree with Ed that > it should. > In other words the sub-packages are for management of the profile > elements not for any application purposes. > That I believe reflects the consensus from a long thread we had in the > UML RTF around proposals from Jim Amsden. > And it provides maximum flexibility - if you want a separate nsURI then > you can always turn the sub-package into a sub-profile. > > Pete > > -----Original Message----- > From: Ed Seidewitz [mailto:ed-s@modeldriven.com] > Sent: Thursday, September 29, 2011 2:25 PM > To: Rouquette, Nicolas F (313K) > Cc: Tomas Juknevicius; Jenkins, J Steven (3101); > uml-spec-simplification@omg.org; uml-rtf@omg.org; issues@omg.org > Subject: RE: Clarifying the serialization of the application of > Stereotypes defined in a Package nested in a Profile. > > Nicolas -- > > UML 2.4 Subclause 18.3.9 Stereotype includes the following paragraph at > the end of the Semantics section: > > "A Stereotype may be contained in a Profile or Package which defines the > namespace for the Stereotype. When profiles are applied to a Package, > the available stereotypes for use as extensions are defined by the > applied profiles, and theses [sic] stereotypes can be identified by the > fully qualified name if needed in order to distinguish stereotypes with > the same name in different profiles or packages. Package and element > import can be used to allow the use of unqualified names. Stereotypes > directly owned by an applied profile (ownedStereotype) may be used > without qualified names." > > So, it would seem that the use of a qualified name when applying a > stereotype is already allowed (though this statement should really be in > the Notation section, not the Semantics section). The only issue is > serialization in XMI. > > In UML 2.4 Subclause 18.37 it states that > > "For a Profile the URI attribute (inherited from package) is used to > determine the nsURI to be used to identify instances of the profile in > XMI." > > As you note, nothing is said about URIs for any subpackages. Even if you > were to include URIs for the subpackages, there is no guidance in the > specification on how those should be used, so any usage would be > non-standard. As far as I can see, tools conforming to the standard can > only expect to be able to use the profile URI. > > Any clarification in UML 2.5 has to be backwardly compatible with the > interchange of profile and stereotype applications per UML 2.4. I can't > see how to formulate your choice (b) to allow this. > > In the end, Pete Rivett (from whom we haven't heard so far on this) is > responsible for writing the UML 2.5 clause that includes profiles. Pete > needs to take all this into advisement in drafting that clause and then > the submission team and, later, the submission reviewers can comment on > it. Until then, I am not sure there is any more to be said. > > -- Ed > > -----Original Message----- > From: Rouquette, Nicolas F (313K) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > Sent: Thursday, September 29, 2011 12:43 PM > To: uml-spec-simplification@omg.org; uml-rtf@omg.org; issues@omg.org > Cc: Tomas Juknevicius; Jenkins, J Steven (3101) > Subject: Re: Clarifying the serialization of the application of > Stereotypes defined in a Package nested in a Profile. > > Yes, there is still the outstanding issue of clarifying how XMI > serialization should work for profiles with nested packages. > > We currently have two proposals for solving this issue: > > a) add a constraint that, in the scope of a profile, stereotypes must > have unique names regardless of their package container in that profile. > > This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" > means that the Stereotype named [sname] must defined somewhere in the > scope of the profile whose Package::URI is associated to [nsPrefix] > > b) add a constraint that each package containing a stereotype must have > a Package::URI. > > This entails clarifying XMI serialization where "<[nsPrefix]:[sname]>" > means that the Stereotype named [sname] must be defined as an owned type > of the package whose Package::URI is associated to [nsPrefix] > > We need to discuss the pros/cons of each proposal. > > Either way, the specification will need clarifying language to: > - explain how XMI serialization works for profiles with nested packages > - improve the notation for UML stereotypes to show where a stereotype > comes from. > > (a) may be simpler for a single profile and for some tools (e.g., > JDeveloper and MagicDraw) but it is certainly not a scalable strategy. > > Consider this: > > Profile SysML4Testing imports SysML, UTP > > Now, I've got a name conflict due to SysML::Requirements::TestCase vs. > UTP::TestCase Clearly, the UML specification needs to improve the > notation for stereotypes to include qualifying information such as the > name of the profile or the name of the container package. > > In practice, (a) shifts the burden of compliance to profile-scope name > unicity to profile developers. > For domain-specific language development with profiles, (a) is > particularly annoying because we can't do simple things like this: > > Profile PF > Stereotype PF::Electrical::Function > Stereotype PF::Mechanical::Function > > Instead, (a) forces one to do something like this: > > Profile PF > Stereotype PF::Electrical::Electrical.Function > Stereotype PF::Mechanical::Mechanical.Function > > In tools that do (a) and only support the UML stereotype notation as > specified, this can be a reasonable compromise, we get: > <>,<>. > In tools that do (a) but extend the UML stereotype notation to show the > name of the profile, we get:<>, > <>. > > Either way, nested packages have no useful purpose -- this completely > defeats the purpose they were added in UML 2.3. > > With (b), UML namespace distinguishability is enough for everybody; some > tool vendors may have to do work to support this flexible scheme. > > For profile developers, we don't have to distort domain-specific > concepts, e.g., we can do: > > Profile PF > Stereotype PF::Electrical::Function > Stereotype PF::Mechanical::Function > > The only thing missing is extending the UML stereotype notation to > provide options for including qualifying name information such as: > - profile name + stereotype name > - profile name + stereotype package container name + stereotype name > - stereotype package container name + stereotype name > - N-segments of the stereotype's fully qualified name from the left + > M-segments of the stereotype's fully qualified name from the right > > - Nicolas. > > On Sep 29, 2011, at 7:22 AM, Ed Seidewitz wrote: > >> There is also the issue of when we would be able to address the issue > Nicolas has raised. >> >> I doubt there is going to be enough support to make this an urgent > issue leading to UML 2.4.2. For what was supposed to be a stabilizing > version before the spec simplification, UML 2.4 has seen enough churn as > it is! >> >> We could certainly provide semantic clarification in UML 2.5. But if > putting the new conventions for the use of profile package URIs into UML > 2.5 would significantly change the interchange of models using profiles > such as SysML. Without this guidance in UML 2.4, there will be no > standard for tool vendors to follow and they will continue to use the > current convention of:. Changing > this in UML 2.5 would be a significant backward incompatibility in model > interchange, which would violate the requirements of the RFP. >> >> So, I don't really see any other sensible course in UML 2.5 than to > clarify that the stereotype names in a profile must all be distinct. > This means adding an additional constraint that isn't in UML 2.4, but I > don't think this will cause any problem with interchange backward > compatibility, since the point of Nicolas' issue is that there isn't any > standard way now anyway to handle stereotypes with the same name in > different packages of a profile. >> >> I think it is still worth recording the issue as Nicolas proposes. > Perhaps it can be discussed further in the UML 2.5 FTF. Or perhaps it is > better to leave its resolution to be handled as part of submissions to > the Metamodel Extension Facility RFP. >> >> -- Ed >> >> -----Original Message----- >> From: Dave Hawkins [mailto:dave.hawkins@oracle.com] >> Sent: Thursday, September 29, 2011 7:23 AM >> To: Rouquette, Nicolas F (313K) >> Cc: Ed Seidewitz; issues@omg.org; uml-spec-simplification@omg.org; >> Tomas Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) >> Subject: Re: Clarifying the serialization of the application of > Stereotypes defined in a Package nested in a Profile. >> >> Nicolas, >> >> I agree with Ed here, I really don't see why constraining the names of > >> all classifiers within a profile or metamodel to be unique is a >> problem. Certainly it's the way we're approaching the issue in >> JDeveloper. You seem to be trying to make things much more complicated > >> than necessary. >> >> I agree this isn't explicit in the specification. However it's >> implicit from the schema production rules isn't it? I'm under the >> impression that elements within a schema have to be uniquely named, >> although I wasn't able to find that constraint in the XML Schema >> specification when I looked just now. >> >> For your UML metamodel example. The unmerged superstructure doesn't >> have a URI, so it isn't actually usable as a metamodel for XMI >> serialisation. The classifiers with the same names also all refer to >> fragments of the same classifier, so they aren't really distinct >> definitions from a serialization perspective. >> >> For a profile, I really don't see why a constraint on the name >> uniqueness within that profile is a severe limitation. >> It seems like a sensible restriction to me. It doesn't seem to cause >> any issues in the UML metamodel and I'd have thought that's larger >> than the majority of profiles. It also means that you can use short >> 'fully qualified' names >> unambiguously: >> <> >> <> >> >> Cheers, >> >> Dave >> >> On 29/09/11 06:46, Rouquette, Nicolas F (313K) wrote: >>> Ed, >>> >>> Global name uniqueness in the scope of a profile or a metamodel is a > bad idea. >>> >>> For a metamodel, I hope it suffices to point out that a tool could > implement the unmerged UML 2.4.1 superstructure or the merged UML 2.4.1 > metamodel. Since the semantics of UML PackageMerge stipulate that the > two should be equivalent, the unmerged UML 2.4.1 superstructure is as > much a metamodel as the merged UML 2.4.1 package is a metamodel. >>> >>> The UML superstructure is certainly an example where having different > concepts with identical names can be problematic; however, that doesn't > mean its necessarily bad in all cases. >>> The practice of UML metamodeling/profile development at the OMG is > certainly not representative of the metamodeling/profile development > practices outside the OMG. >>> >>> For a profile, I hope it suffices to point out that global name > uniqueness for stereotypes would severely limit the extensibility of a > profile -- once a name is used for defining a stereotype, that name > couldn't be used for defining another stereotype in that profile even if > it would be perfectly OK w.r.t. current UML namespace distinguishability > rules. >>> >>> I believe the lure of global name uniqueness you allude to comes from > the narrow view of the current UML notation which provides only two > options: simple name or fully qualified name. >>> This two-option notation is very unsatisfactory in many cases even > without name collision because we can't tell which profile<> comes > from when it is applied to an element. >>> With colliding names, it's unsatisfactory within a profile and across > profiles. For example, it is currently impossible to distinguish by > current notation convention alone between SysML 1.3's TestCase vs. UTP > 1.1's TestCase. The two concepts are very different but they are > undistinguishable by notation alone, e.g.: >>> >>> <> A >>> <> B >>> >>> We shouldn't use the flimsy excuse that the current notation for > stereotype uses the simple name as an excuse for suggesting that > stereotypes should have unique names in the scope of a profile. >>> >>> Finally, this idea is triply-bad because it would severely compromise > the value of Package::URI added in UML 2.4.1. >>> The value of this extension is that it allows us to make a strong > correspondence between a UML package and arbitrary namespaces in the > semantic web / world wide web. >>> >>> The suggestion that profiles, a special kind of package, would > further impose an artificial global name uniqueness constraint that has > no legitimate counterpart in practice provides is yet another factor to > support my claim that this artificial constraint would be a very, very > bad for UML. >>> >>> - Nicolas. >>> >>> >>> >>> On Sep 28, 2011, at 4:42 PM, Ed Seidewitz wrote: >>> >>>> Nicolas -- >>>> >>>> The Package::URI attribute was added because to allow MOF 2.4 to be > a strict subset of UML 2.4, because MOF packages can have URIs. You are > widening its purpose for profile packages. Perhaps one could make a > correspondence between profile subpackages and MOF packages (similar to > the correspondence between stereotypes and MOF classes), but the current > spec certainly does not make that correspondence. >>>> >>>> It is already pretty much always the case that the classes in > metamodels have distinct names, whatever the packaging (at least after > package merging is done). And I think the same is true of stereotypes in > profiles. In fact, I think this is probably a good constraint, because > having multiple stereotypes with the same name in the same profile is > sure to be confusing. >>>> >>>> -- Ed >>>> >>>> -----Original Message----- >>>> From: Rouquette, Nicolas F (313K) >>>> [mailto:nicolas.f.rouquette@jpl.nasa.gov] >>>> Sent: Wednesday, September 28, 2011 7:18 PM >>>> To: Ed Seidewitz >>>> Cc: issues@omg.org; uml-spec-simplification@omg.org; Tomas >>>> Juknevicius; uml-rtf@omg.org; Jenkins, J Steven (3101) >>>> Subject: Re: Clarifying the serialization of the application of > Stereotypes defined in a Package nested in a Profile. >>>> >>>> Ed, >>>> >>>> I strongly disagree with you. >>>> >>>> The UML Profile mechanism is already very constraining; the > constraint you suggest would further restrict what we can do. >>>> The constraint would effectively mean that a Package nested in a > Profile would have no semantic value whatsoever. >>>> The Package::URI attribute gives UML Packages a small but very > useful semantics, that of denoting an identified namespace. >>>> It would be ironic that this very capability we need for the >>>> severely under-specified XMI serialization for the application of a > Profile would be the very same capability that the constraint you > suggest would remove! >>>> >>>> - Nicolas. >>>> >>>> On Sep 28, 2011, at 3:40 PM, Ed Seidewitz wrote: >>>> >>>>> Nicolas -- >>>>> >>>>> It would seem simpler to just require that all the stereotypes in a > profile have distinct names, whether they are directly owned by the > profile or indirectly owned through a package within the profile. Then > the current approach of profile nsPrefix plus stereotype name would be > sufficient. And I don't think this would really be a serious restriction > in practice, since packages are generally used organizationally in > profiles, not to introduce namespaces to allow different stereotypes > with the same name within the profile. >>>>> >>>>> -- Ed >>>>> >>>>> -----Original Message----- >>>>> From: Rouquette, Nicolas F (313K) >>>>> [mailto:nicolas.f.rouquette@jpl.nasa.gov] >>>>> Sent: Wednesday, September 28, 2011 1:26 PM >>>>> To: issues@omg.org >>>>> Cc: uml-spec-simplification@omg.org; Tomas Juknevicius; >>>>> uml-rtf@omg.org >>>>> Subject: Clarifying the serialization of the application of > Stereotypes defined in a Package nested in a Profile. >>>>> >>>>> This is an issue for UML 2.4.1. >>>>> >>>>> In 18.3.7, the semantics for Profile incompletely describes how to > "Use XMI to exhange Profiles" for the case where a "Stereotype may be > contained in a Profile or Package which defines the namespace for the > Stereotype." (18.3.9, Stereotype Semantics). >> >>>>> >>>>> The Semantics section in 18.3.7 is missing the important > constraints explaining some of the principles for the XMI serialization > of the application of a Profile. >>>>> The following constraints are consistent with the semantics of > Stereotype Package containment specified in 18.3.9. >>>>> >>>>> 1) The XMI serialization of the application of a Stereotype is an > XML Element tag of the form: "<[XML namespace prefix of the Package > containing the applied Stereotype]:[applied Stereotype name]>" >>>>> >>>>> This is illustrated in the HomeExample profile in Fig. 18.8 whose > Package URI, "http://HomeExample/20101201/HomeExample.xmi", is > associated to the XML namespace prefix "HomeExample". >>>>> Therefore, the application of the Stereotype HomeExample::Home > serializes into an XML Element tag of the form: "" as > shown in the example. >>>>> >>>>> The spec is missing an example where a Stereotype is contained in a > Package that is nested in a Profile. >>>>> SysML 1.3 can provide ample material for such an example. >>>>> >>>>> 2) An XMI serializer must include in an XMI document all the XML > namespace prefix declarations corresponding to all the container > Packages of all Stereotypes whose application to an Element is > serialized in that XMI document. >>>>> >>>>> In some cases, this means that the XML namespace prefix used for a > particular Package may be different than the convention used for OMG > normative profiles (See UML 2.4.1, 18.3.7) where the nsPrefix is the > name of the Profile. >>>>> >>>>> 3) The owning Package of each Stereotype must have a Package::URI > specified so that an XMI processor can: >>>>> >>>>> - generate an XML namespace prefix for that Package when one of its > >>>>> contained Stereotypes is applied >>>>> >>>>> - resolve a reference to an applied Stereotype to the Package > containing the definition of the Stereotype via the XML namespace prefix > used for the containing Package URI. >>>>> >>>>> This can be specified in OCL2.3 as follows: >>>>> >>>>> context Stereotype >>>>> inv StereotypeContainerPackageMustHaveURI: >>>>> self.owningPackage.URI->notEmpty() >>>>> >>>>> 4) All the Stereotype-containing Packages in a Profile regardless > of nesting must have distinct Package URIs. >>>>> >>>>> This can be specified in OCL2.3 as follows: >>>>> >>>>> context Profile >>>>> inv StereotypeContainingPackagesMustHaveDistinctURIs: >>>>> let pkgs : Set(Package) = >>>>> self->closure(nestedPackage)->including(self) in let allURIs : >>>>> Bag(String) = pkgs.URI in let uniqueURIs : Set(String) = >>>>> allURIs->asSet() in >>>>> allURIs->size() = uniqueURIs->size() >>>>> >>>>> 5) The OMG normative profile convention in 18.3.7 must be updated > to provide a sensible nsPrefix for the XML namespace corresponding to a > nested Package in a Profile. >>>>> >>>>> The conventions in 18.3.7 was written at a time when UML 2.0 > allowed Stereotypes to be directly contained in a Profile. >>>>> The conventions need to be updated to provide a sensible rule for > generating the nsPrefix for a Package nested in a Profile. >>>>> >>>>> I suggest using the "."-concatenated sequence of names of the UML > Namespaces from the Profile to the nested Package. >>>>> For example, the SysML 1.3 Profile is named "SysML" and it defines > a nested package "SysML::Blocks". >>>>> The suggested nsPrefix for the UML Package SysML::Blocks would be > "SysML.Blocks". >>>>> This name is legal per the normative criteria for XML namespace >>>>> prefix names (see: http://www.w3.org/TR/REC-xml/#NT-Name) >>>>> >>>>> >>>>> - Nicolas. >>>> >>> >> >> -- >> 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. > -- 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.