Issue 18112: Location: Annex C Keywords P. 777 - Previously unmentioned constraints given in Keywords Annex (uml25-ftf) Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com) Nature: Revision Severity: Significant Summary: The first paragraph gives a number of constraints on model element names, in particular stereotypes. I don't believe this is mentioned in either the NamedElement description or the Stereotype description. I don't think this is a constraint that should be left to an annex, if indeed it should exist: the EJB profile example in figure 12-19 has an Entity stereotype that extends Component as does StandardProfile. Resolution: Revised Text: Actions taken: September 28, 2012: received issue Discussion: End of Annotations:===== s is issue # 18112 Problem: C.043 Severity: Significant Type: Revision Location: Annex C Keywords P. 777 Title: Previously unmentioned constraints given in Keywords Annex Summary: The first paragraph gives a number of constraints on model element names, in particular stereotypes. I don't believe this is mentioned in either the NamedElement description or the Stereotype description. I don't think this is a constraint that should be left to an annex, if indeed it should exist: the EJB profile example in figure 12-19 has an Entity stereotype that extends Component as does StandardProfile. Source: dave.hawkins@oracle.com Date: Tue, 19 Mar 2013 15:41:16 +0000 From: Dave Hawkins User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 To: "Manfred R. Koethe" CC: "uml25-ftf@omg.org" Subject: [UML 2.5 FTF] Ballot 3 - Preview 3 - Issue 18112 X-Source-IP: userp1040.oracle.com [156.151.31.81] X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR0YqyA= X-Brightmail-Tracker: AAAAAA== I've realised that there actually is a constraint on Stereotype that covers this: name_not_clash. There's no such constraint on NamedElement. However there doesn't need to be because the guillemets presentation of keywords means that the only way for ambiguity to exist is with user-defined stereotypes. In which case the text "cannot be used to name user-defined model elements..." is unnecessarily imprecise. In the issue I give the example of the EJB Entity stereotype, which is defined in figure 12.19. This extends Component. As the standard profile Entity stereotype also extends Component, this means the example EJB Profile is invalid. This needs to be fixed. (Although I think it would be preferable to have a mechanism to resolve ambiguous stereotype applications rather than banning them. Entity, for example, is used in many different contexts. Would users ever actually think the UML standard profile was the appropriate one?) Cheers, Dave On 16/03/13 21:03, Manfred R. Koethe wrote: Dear Colleagues, Here is Preview 3 of Ballot 3. Issue 8274 and 17933 are withdrawn from this ballot. Kind regards, Manfred --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (617) 848 0525 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- -- 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: "Chonoles, Michael J" To: "Steve.Cook@microsoft.com" , Dave Hawkins , "Manfred R. Koethe" CC: "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] Ballot 3 - Preview 3 - Issue 18112 Thread-Topic: [UML 2.5 FTF] Ballot 3 - Preview 3 - Issue 18112 Thread-Index: AQHOKgt0GBczYVnKlEW7/ZmFILpnw5jDCjnw Date: Tue, 2 Apr 2013 14:35:35 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.90] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-04-02_06:2013-04-02,2013-04-02,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r32EchgI032173 X-Brightmail-Tracker: AAAAAh1cw4YdXfyH X-Brightmail-Tracker: AAAAAA== Sounds reasonable, though it would be useful to have an appendix listing the standard , perhaps another one. Michael -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, March 26, 2013 6:19 AM To: Dave Hawkins; Manfred R. Koethe Cc: uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] Ballot 3 - Preview 3 - Issue 18112 Dave It seems to me to be quite silly to require all stereotype names across all profiles to be unique. Surely the way to resolve clashes between stereotype names is to qualify them? In which case EJB::Entity is distinct from StandardProfile::Entity, and the names would have to be qualified where any ambiguity arose. Indeed, clause 12 says exactly this: "If multiple appliedProfiles have Stereotypes with the same name, it may be necessary to qualify the name of the Stereotype ...". The problem arises, I think, because the term "keyword" has been extended to include the names of "standard stereotypes", thus giving the StandardProfile a primacy that it does not deserve. If Annex C did not include the standard stereotypes at all, then only genuine keywords would be covered by "name_not_clash". I therefore propose to resolve 18112 (in a future ballot) by removing all of the standard stereotypes from the list of keywords in Annex C, and removing the constraining sentences from the first paragraph. This is entirely consistent with the existing statement that "not all words appearing between guillemets are necessarily keywords". Do you agree? Thanks -- Steve -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: 19 March 2013 15:41 To: Manfred R. Koethe Cc: uml25-ftf@omg.org Subject: [UML 2.5 FTF] Ballot 3 - Preview 3 - Issue 18112 I've realised that there actually is a constraint on Stereotype that covers this: name_not_clash. There's no such constraint on NamedElement. However there doesn't need to be because the guillemets presentation of keywords means that the only way for ambiguity to exist is with user-defined stereotypes. In which case the text "cannot be used to name user-defined model elements..." is unnecessarily imprecise. In the issue I give the example of the EJB Entity stereotype, which is defined in figure 12.19. This extends Component. As the standard profile Entity stereotype also extends Component, this means the example EJB Profile is invalid. This needs to be fixed. (Although I think it would be preferable to have a mechanism to resolve ambiguous stereotype applications rather than banning them. Entity, for example, is used in many different contexts. Would users ever actually think the UML standard profile was the appropriate one?) Cheers, Dave On 16/03/13 21:03, Manfred R. Koethe wrote: > Dear Colleagues, > > Here is Preview 3 of Ballot 3. Issue 8274 and 17933 are withdrawn from this ballot. > > Kind regards, > > Manfred > > --------------------------------------------------------------- > Manfred R. Koethe 88solutions Corporation > tel: +1 (617) 848 0525 fax: +1 (815) 550 2086 > mailto: koethe@88solutions.com > web: http://www.88solutions.com > --------(Model-Driven Modeling Solutions)-------- > > > > > > > -- 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: Steve Cook To: "Chonoles, Michael J" , Dave Hawkins , "Manfred R. Koethe" CC: "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] Ballot 3 - Preview 3 - Issue 18112 Thread-Topic: [UML 2.5 FTF] Ballot 3 - Preview 3 - Issue 18112 Thread-Index: AQHOJLh9RV5pBmjEh0+GDIcH3JKNMpi3yL3ggAtMfoCAAAKQUA== Date: Tue, 2 Apr 2013 14:46:43 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.100] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(199002)(189002)(51704002)(13464002)(71364001)(377454001)(24454001)(5403001)(479174001)(47736001)(50986001)(59766001)(54356001)(31966008)(5343655001)(55846006)(50466001)(47976001)(49866001)(80022001)(5343635001)(77982001)(63696002)(20776003)(16601075001)(65816001)(47776003)(46406002)(79102001)(76482001)(33656001)(46102001)(51856001)(56776001)(16406001)(56816002)(54316002)(15202345001)(81342001)(74502001)(69226001)(74662001)(47446002)(23726001)(4396001)(44976002)(53806001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB028;H:TK5EX14HUBC103.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08041D247D X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r32EmlAi001095 X-Brightmail-Tracker: AAAAAR1cw4Y= X-Brightmail-Tracker: AAAAAA== Michael We have an entire and separate chapter listing and defining the standard stereotypes, including a model of them. It is called Clause 22. -- Steve -----Original Message----- From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: 02 April 2013 15:36 To: Steve Cook; Dave Hawkins; Manfred R. Koethe Cc: uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] Ballot 3 - Preview 3 - Issue 18112 Sounds reasonable, though it would be useful to have an appendix listing the standard , perhaps another one. Michael -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, March 26, 2013 6:19 AM To: Dave Hawkins; Manfred R. Koethe Cc: uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] Ballot 3 - Preview 3 - Issue 18112 Dave It seems to me to be quite silly to require all stereotype names across all profiles to be unique. Surely the way to resolve clashes between stereotype names is to qualify them? In which case EJB::Entity is distinct from StandardProfile::Entity, and the names would have to be qualified where any ambiguity arose. Indeed, clause 12 says exactly this: "If multiple appliedProfiles have Stereotypes with the same name, it may be necessary to qualify the name of the Stereotype ...". The problem arises, I think, because the term "keyword" has been extended to include the names of "standard stereotypes", thus giving the StandardProfile a primacy that it does not deserve. If Annex C did not include the standard stereotypes at all, then only genuine keywords would be covered by "name_not_clash". I therefore propose to resolve 18112 (in a future ballot) by removing all of the standard stereotypes from the list of keywords in Annex C, and removing the constraining sentences from the first paragraph. This is entirely consistent with the existing statement that "not all words appearing between guillemets are necessarily keywords". Do you agree? Thanks -- Steve -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: 19 March 2013 15:41 To: Manfred R. Koethe Cc: uml25-ftf@omg.org Subject: [UML 2.5 FTF] Ballot 3 - Preview 3 - Issue 18112 I've realised that there actually is a constraint on Stereotype that covers this: name_not_clash. There's no such constraint on NamedElement. However there doesn't need to be because the guillemets presentation of keywords means that the only way for ambiguity to exist is with user-defined stereotypes. In which case the text "cannot be used to name user-defined model elements..." is unnecessarily imprecise. In the issue I give the example of the EJB Entity stereotype, which is defined in figure 12.19. This extends Component. As the standard profile Entity stereotype also extends Component, this means the example EJB Profile is invalid. This needs to be fixed. (Although I think it would be preferable to have a mechanism to resolve ambiguous stereotype applications rather than banning them. Entity, for example, is used in many different contexts. Would users ever actually think the UML standard profile was the appropriate one?) Cheers, Dave On 16/03/13 21:03, Manfred R. Koethe wrote: > Dear Colleagues, > > Here is Preview 3 of Ballot 3. Issue 8274 and 17933 are withdrawn from this ballot. > > Kind regards, > > Manfred > > --------------------------------------------------------------- > Manfred R. Koethe 88solutions Corporation > tel: +1 (617) 848 0525 fax: +1 (815) 550 2086 > mailto: koethe@88solutions.com > web: http://www.88solutions.com > --------(Model-Driven Modeling Solutions)-------- > > > > > > > -- 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: "Chonoles, Michael J" To: Steve Cook , Dave Hawkins , "Manfred R. Koethe" CC: "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] Ballot 3 - Preview 3 - Issue 18112 Thread-Topic: [UML 2.5 FTF] Ballot 3 - Preview 3 - Issue 18112 Thread-Index: AQHOKgt0GBczYVnKlEW7/ZmFILpnw5jDCjnwgABGhoD//716sA== Date: Tue, 2 Apr 2013 14:48:44 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.90] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-04-02_06:2013-04-02,2013-04-02,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r32EogxQ001414 X-Brightmail-Tracker: AAAAAh1cw4YdXfyH X-Brightmail-Tracker: AAAAAA== Of course -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, April 02, 2013 10:47 AM To: Chonoles, Michael J; Dave Hawkins; Manfred R. Koethe Cc: uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] Ballot 3 - Preview 3 - Issue 18112 Michael We have an entire and separate chapter listing and defining the standard stereotypes, including a model of them. It is called Clause 22. -- Steve -----Original Message----- From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: 02 April 2013 15:36 To: Steve Cook; Dave Hawkins; Manfred R. Koethe Cc: uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] Ballot 3 - Preview 3 - Issue 18112 Sounds reasonable, though it would be useful to have an appendix listing the standard , perhaps another one. Michael -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, March 26, 2013 6:19 AM To: Dave Hawkins; Manfred R. Koethe Cc: uml25-ftf@omg.org Subject: EXTERNAL: RE: [UML 2.5 FTF] Ballot 3 - Preview 3 - Issue 18112 Dave It seems to me to be quite silly to require all stereotype names across all profiles to be unique. Surely the way to resolve clashes between stereotype names is to qualify them? In which case EJB::Entity is distinct from StandardProfile::Entity, and the names would have to be qualified where any ambiguity arose. Indeed, clause 12 says exactly this: "If multiple appliedProfiles have Stereotypes with the same name, it may be necessary to qualify the name of the Stereotype ...". The problem arises, I think, because the term "keyword" has been extended to include the names of "standard stereotypes", thus giving the StandardProfile a primacy that it does not deserve. If Annex C did not include the standard stereotypes at all, then only genuine keywords would be covered by "name_not_clash". I therefore propose to resolve 18112 (in a future ballot) by removing all of the standard stereotypes from the list of keywords in Annex C, and removing the constraining sentences from the first paragraph. This is entirely consistent with the existing statement that "not all words appearing between guillemets are necessarily keywords". Do you agree? Thanks -- Steve -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: 19 March 2013 15:41 To: Manfred R. Koethe Cc: uml25-ftf@omg.org Subject: [UML 2.5 FTF] Ballot 3 - Preview 3 - Issue 18112 I've realised that there actually is a constraint on Stereotype that covers this: name_not_clash. There's no such constraint on NamedElement. However there doesn't need to be because the guillemets presentation of keywords means that the only way for ambiguity to exist is with user-defined stereotypes. In which case the text "cannot be used to name user-defined model elements..." is unnecessarily imprecise. In the issue I give the example of the EJB Entity stereotype, which is defined in figure 12.19. This extends Component. As the standard profile Entity stereotype also extends Component, this means the example EJB Profile is invalid. This needs to be fixed. (Although I think it would be preferable to have a mechanism to resolve ambiguous stereotype applications rather than banning them. Entity, for example, is used in many different contexts. Would users ever actually think the UML standard profile was the appropriate one?) Cheers, Dave On 16/03/13 21:03, Manfred R. Koethe wrote: > Dear Colleagues, > > Here is Preview 3 of Ballot 3. Issue 8274 and 17933 are withdrawn from this ballot. > > Kind regards, > > Manfred > > --------------------------------------------------------------- > Manfred R. Koethe 88solutions Corporation > tel: +1 (617) 848 0525 fax: +1 (815) 550 2086 > mailto: koethe@88solutions.com > web: http://www.88solutions.com > --------(Model-Driven Modeling Solutions)-------- > > > > > > > -- 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.