Issue 12774: Regression in XMI from UML 2.1.2 to UML 2.2 (uml2-rtf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Revision Severity: Serious Summary: At 03:12 PM 8/13/2008, Pete Rivett wrote: Well-spotted Nicolas: though from your example fragments you’re wrong to say that at 2.2 the ends are given a generic name – they are given a generic xmi:id and no name at all! Both the change of name and (to a lesser extent) xmi:id, without being mandated by an issue resolution are IMHO serious bugs. The xmi:id case is more controversial, since xmi:ids do not in general have to be stable. However, since they are frequently used for referencing the elements from outside the file (e.g. using XMI hrefs) then for standard metamodels I think we should keep them stable. In fact I’d say that we should probably treat this as an urgent issue and produce a new XMI file ASAP. >From the difference between the 2 fragments I spotted another discrepancy/bug in UML 2.2 – there is an incorrect owningAssociation attribute on the Property. This must not be serialized since it’s the opposite of the composite owner of the Property (Association.ownedEnd) and so redundant. Clearly we should do more to perform diffs between the different versions of XMI files in order to catch inadvertent changes such as this. Pete From: Nicolas Rouquette [ mailto:nicolas.rouquette@jpl.nasa.gov] Sent: 13 August 2008 19:15 To: uml2-rtf@omg.org; executableUMLFoundation@omg.org; Conrad Bock; Bran Selic; Ed Seidewitz; Stephen Mellor Subject: unalabelled association-owned memberEnd property names affect the name of an association I noticed strange differences between the XMI serialization of the UML superstructure in: UML 2.1.2, i.e: http://www.omg.org/spec/UML/20061001/Superstructure.cmof UML 2.2 beta1, i.e: http://www.omg.org/cgi-bin/doc?ptc/08-05-12 For example, in UML 2.1.2, we have: <ownedMember xmi:type="cmof:Association" xmi:id="Actions-CompleteActions-A_result_readExtentAction" name="A_result_readExtentAction" memberEnd="Actions-CompleteActions-ReadExtentAction-result Actions-CompleteActions-A_result_readExtentAction-readExtentAction"> <ownedEnd xmi:type="cmof:Property" xmi:id="Actions-CompleteActions-A_result_readExtentAction-readExtentAction" name="readExtentAction" lower="0" type="Actions-CompleteActions-ReadExtentAction" association="Actions-CompleteActions-A_result_readExtentAction"/> </ownedMember> whereas in UML 2.2beta1, we have: <ownedMember xmi:type="cmof:Association" xmi:id="Actions-CompleteActions-A_result_readExtentAction" name="A_result_readExtentAction" memberEnd="Actions-CompleteActions-ReadExtentAction-result Actions-CompleteActions-A_result_readExtentAction-_ownedEnd.0"> <ownedEnd xmi:type="cmof:Property" xmi:id="Actions-CompleteActions-A_result_readExtentAction-_ownedEnd.0" type="Actions-CompleteActions-ReadExtentAction" lower="0" owningAssociation="Actions-CompleteActions-A_result_readExtentAction" association="Actions-CompleteActions-A_result_readExtentAction"/> </ownedMember> In both cases, this association is described in Fig. 11.13 Object Actions (CompleteActions) in a way where the name of an association-owned memberEnd property isn't shown whereas the name of a class-owned memberEnd property is shown according to the conventions specified in clause 6.4.2 of the UML superstructure spec. http://www.omg.org/cgi-bin/doc?ptc/08-05-05 http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/ The problem here is that the unlabelled association-owned memberEnd properties have been given generic names such as ownedEnd.0 instead of the convention defined in clause 6.4.2 -- i.e., the name of the class with a lowercase initial. Is it OK for association names to change in this manner from one rev to another or is this a bug? Regardless of whether it is a bug or not w.r.t. current OMG specs, there is certainly a very undesirable consequence in name-level changes between revisions for a given concept when these revisions have not changed the semantics of that concept. Such incidental name-level changes create a lot of problems w.r.t. a stable notion of identity across revisions for detecting semantically-relevant changes from semantically irrelevant changes. Resolution: Revised Text: Actions taken: August 13, 2008: received issue Discussion: End of Annotations:===== te: Wed, 13 Aug 2008 11:15:01 -0700 From: Nicolas Rouquette User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) To: uml2-rtf@omg.org, executableUMLFoundation@omg.org, Conrad Bock , Bran Selic , Ed Seidewitz , Stephen Mellor Subject: unalabelled association-owned memberEnd property names affect the name of an association X-Source-IP: rse6g.jpl.nasa.gov [137.78.29.64] X-Source-Sender: nicolas.rouquette@jpl.nasa.gov X-AUTH: Authorized X-AUTH: Authorized I noticed strange differences between the XMI serialization of the UML superstructure in: UML 2.1.2, i.e: http://www.omg.org/spec/UML/20061001/Superstructure.cmof UML 2.2 beta1, i.e: http://www.omg.org/cgi-bin/doc?ptc/08-05-12 For example, in UML 2.1.2, we have: whereas in UML 2.2beta1, we have: In both cases, this association is described in Fig. 11.13 Object Actions (CompleteActions) in a way where the name of an association-owned memberEnd property isn't shown whereas the name of a class-owned memberEnd property is shown according to the conventions specified in clause 6.4.2 of the UML superstructure spec. http://www.omg.org/cgi-bin/doc?ptc/08-05-05 http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/ The problem here is that the unlabelled association-owned memberEnd properties have been given generic names such as ownedEnd.0 instead of the convention defined in clause 6.4.2 -- i.e., the name of the class with a lowercase initial. Is it OK for association names to change in this manner from one rev to another or is this a bug? Regardless of whether it is a bug or not w.r.t. current OMG specs, there is certainly a very undesirable consequence in name-level changes between revisions for a given concept when these revisions have not changed the semantics of that concept. Such incidental name-level changes create a lot of problems w.r.t. a stable notion of identity across revisions for detecting semantically-relevant changes from semantically irrelevant changes. -- Nicolas. Subject: RE: unalabelled association-owned memberEnd property names affect the name of an association Date: Wed, 13 Aug 2008 12:12:59 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: unalabelled association-owned memberEnd property names affect the name of an association Thread-Index: Acj9cJv1+x0Pl0UxTImX30CvUskh7gABZdEQ From: "Pete Rivett" To: "Nicolas Rouquette" , , , "Conrad Bock" , "Bran Selic" , "Ed Seidewitz" , "Stephen Mellor" , "Kenn Hussey" Cc: "Andrew Watson" Well-spotted Nicolas: though from your example fragments you.re wrong to say that at 2.2 the ends are given a generic name . they are given a generic xmi:id and no name at all! Both the change of name and (to a lesser extent) xmi:id, without being mandated by an issue resolution are IMHO serious bugs. The xmi:id case is more controversial, since xmi:ids do not in general have to be stable. However, since they are frequently used for referencing the elements from outside the file (e.g. using XMI hrefs) then for standard metamodels I think we should keep them stable. In fact I.d say that we should probably treat this as an urgent issue and produce a new XMI file ASAP. From the difference between the 2 fragments I spotted another discrepancy/bug in UML 2.2 . there is an incorrect owningAssociation attribute on the Property. This must not be serialized since it.s the opposite of the composite owner of the Property (Association.ownedEnd) and so redundant. Clearly we should do more to perform diffs between the different versions of XMI files in order to catch inadvertent changes such as this. Pete From: Nicolas Rouquette [mailto:nicolas.rouquette@jpl.nasa.gov] Sent: 13 August 2008 19:15 To: uml2-rtf@omg.org; executableUMLFoundation@omg.org; Conrad Bock; Bran Selic; Ed Seidewitz; Stephen Mellor Subject: unalabelled association-owned memberEnd property names affect the name of an association I noticed strange differences between the XMI serialization of the UML superstructure in: UML 2.1.2, i.e: http://www.omg.org/spec/UML/20061001/Superstructure.cmof UML 2.2 beta1, i.e: http://www.omg.org/cgi-bin/doc?ptc/08-05-12 For example, in UML 2.1.2, we have: whereas in UML 2.2beta1, we have: In both cases, this association is described in Fig. 11.13 Object Actions (CompleteActions) in a way where the name of an association-owned memberEnd property isn't shown whereas the name of a class-owned memberEnd property is shown according to the conventions specified in clause 6.4.2 of the UML superstructure spec. http://www.omg.org/cgi-bin/doc?ptc/08-05-05 http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/ The problem here is that the unlabelled association-owned memberEnd properties have been given generic names such as ownedEnd.0 instead of the convention defined in clause 6.4.2 -- i.e., the name of the class with a lowercase initial. Is it OK for association names to change in this manner from one rev to another or is this a bug? Regardless of whether it is a bug or not w.r.t. current OMG specs, there is certainly a very undesirable consequence in name-level changes between revisions for a given concept when these revisions have not changed the semantics of that concept. Such incidental name-level changes create a lot of problems w.r.t. a stable notion of identity across revisions for detecting semantically-relevant changes from semantically irrelevant changes. -- Nicolas. X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Aug 2008 15:19:55 -0400 To: "Pete Rivett" , "Nicolas Rouquette" , , , "Conrad Bock" , "Bran Selic" , "Ed Seidewitz" , "Stephen Mellor" , "Kenn Hussey" From: Juergen Boldt Subject: RE: unalabelled association-owned memberEnd property names affect the name of an association Cc: "Andrew Watson" should I handle this one as one issue or should I assign two issue numbers? -Juergen At 03:12 PM 8/13/2008, Pete Rivett wrote: Well-spotted Nicolas: though from your example fragments you.re wrong to say that at 2.2 the ends are given a generic name . they are given a generic xmi:id and no name at all! Both the change of name and (to a lesser extent) xmi:id, without being mandated by an issue resolution are IMHO serious bugs. The xmi:id case is more controversial, since xmi:ids do not in general have to be stable. However, since they are frequently used for referencing the elements from outside the file (e.g. using XMI hrefs) then for standard metamodels I think we should keep them stable. In fact I.d say that we should probably treat this as an urgent issue and produce a new XMI file ASAP. From the difference between the 2 fragments I spotted another discrepancy/bug in UML 2.2 . there is an incorrect owningAssociation attribute on the Property. This must not be serialized since it.s the opposite of the composite owner of the Property (Association.ownedEnd) and so redundant. Clearly we should do more to perform diffs between the different versions of XMI files in order to catch inadvertent changes such as this. Pete From: Nicolas Rouquette [ mailto:nicolas.rouquette@jpl.nasa.gov] Sent: 13 August 2008 19:15 To: uml2-rtf@omg.org; executableUMLFoundation@omg.org; Conrad Bock; Bran Selic; Ed Seidewitz; Stephen Mellor Subject: unalabelled association-owned memberEnd property names affect the name of an association I noticed strange differences between the XMI serialization of the UML superstructure in: UML 2.1.2, i.e: http://www.omg.org/spec/UML/20061001/Superstructure.cmof UML 2.2 beta1, i.e: http://www.omg.org/cgi-bin/doc?ptc/08-05-12 For example, in UML 2.1.2, we have: whereas in UML 2.2beta1, we have: In both cases, this association is described in Fig. 11.13 Object Actions (CompleteActions) in a way where the name of an association-owned memberEnd property isn't shown whereas the name of a class-owned memberEnd property is shown according to the conventions specified in clause 6.4.2 of the UML superstructure spec. http://www.omg.org/cgi-bin/doc?ptc/08-05-05 http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/ The problem here is that the unlabelled association-owned memberEnd properties have been given generic names such as ownedEnd.0 instead of the convention defined in clause 6.4.2 -- i.e., the name of the class with a lowercase initial. Is it OK for association names to change in this manner from one rev to another or is this a bug? Regardless of whether it is a bug or not w.r.t. current OMG specs, there is certainly a very undesirable consequence in name-level changes between revisions for a given concept when these revisions have not changed the semantics of that concept. Such incidental name-level changes create a lot of problems w.r.t. a stable notion of identity across revisions for detecting semantically-relevant changes from semantically irrelevant changes. -- Nicolas. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Subject: RE: unalabelled association-owned memberEnd property names affect the name of an association Date: Wed, 13 Aug 2008 15:24:13 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: unalabelled association-owned memberEnd property names affect the name of an association Thread-Index: Acj9ecIZ/2/vCs9MQW2fONrF+MEQXgAGWTSA From: "Pete Rivett" To: "Juergen Boldt" , "Nicolas Rouquette" , , , "Conrad Bock" , "Bran Selic" , "Ed Seidewitz" , "Stephen Mellor" , "Kenn Hussey" Cc: "Andrew Watson" Just one titled: Regression in XMI from UML 2.1.2 to UML 2.2. Thanks Pete From: Juergen Boldt [mailto:juergen@omg.org] Sent: 13 August 2008 20:20 To: Pete Rivett; Nicolas Rouquette; uml2-rtf@omg.org; executableUMLFoundation@omg.org; Conrad Bock; Bran Selic; Ed Seidewitz; Stephen Mellor; Kenn Hussey Cc: Andrew Watson Subject: RE: unalabelled association-owned memberEnd property names affect the name of an association should I handle this one as one issue or should I assign two issue numbers? -Juergen At 03:12 PM 8/13/2008, Pete Rivett wrote: Well-spotted Nicolas: though from your example fragments you.re wrong to say that at 2.2 the ends are given a generic name . they are given a generic xmi:id and no name at all! Both the change of name and (to a lesser extent) xmi:id, without being mandated by an issue resolution are IMHO serious bugs. The xmi:id case is more controversial, since xmi:ids do not in general have to be stable. However, since they are frequently used for referencing the elements from outside the file (e.g. using XMI hrefs) then for standard metamodels I think we should keep them stable. In fact I.d say that we should probably treat this as an urgent issue and produce a new XMI file ASAP. >From the difference between the 2 fragments I spotted another discrepancy/bug in UML 2.2 . there is an incorrect owningAssociation attribute on the Property. This must not be serialized since it.s the opposite of the composite owner of the Property (Association.ownedEnd) and so redundant. Clearly we should do more to perform diffs between the different versions of XMI files in order to catch inadvertent changes such as this. Pete From: Nicolas Rouquette [ mailto:nicolas.rouquette@jpl.nasa.gov] Sent: 13 August 2008 19:15 To: uml2-rtf@omg.org; executableUMLFoundation@omg.org; Conrad Bock; Bran Selic; Ed Seidewitz; Stephen Mellor Subject: unalabelled association-owned memberEnd property names affect the name of an association I noticed strange differences between the XMI serialization of the UML superstructure in: UML 2.1.2, i.e: http://www.omg.org/spec/UML/20061001/Superstructure.cmof UML 2.2 beta1, i.e: http://www.omg.org/cgi-bin/doc?ptc/08-05-12 For example, in UML 2.1.2, we have: whereas in UML 2.2beta1, we have: In both cases, this association is described in Fig. 11.13 Object Actions (CompleteActions) in a way where the name of an association-owned memberEnd property isn't shown whereas the name of a class-owned memberEnd property is shown according to the conventions specified in clause 6.4.2 of the UML superstructure spec. http://www.omg.org/cgi-bin/doc?ptc/08-05-05 http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/ The problem here is that the unlabelled association-owned memberEnd properties have been given generic names such as ownedEnd.0 instead of the convention defined in clause 6.4.2 -- i.e., the name of the class with a lowercase initial. Is it OK for association names to change in this manner from one rev to another or is this a bug? Regardless of whether it is a bug or not w.r.t. current OMG specs, there is certainly a very undesirable consequence in name-level changes between revisions for a given concept when these revisions have not changed the semantics of that concept. Such incidental name-level changes create a lot of problems w.r.t. a stable notion of identity across revisions for detecting semantically-relevant changes from semantically irrelevant changes. -- Nicolas. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org X-IronPort-AV: E=Sophos;i="4.32,208,1217800800"; d="scan'208,217";a="29569605" Subject: Re: unalabelled association-owned memberEnd property names affect the name of an association Date: Thu, 14 Aug 2008 11:18:05 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: unalabelled association-owned memberEnd property names affect the name of an association Thread-Index: Acj9cJv1+x0Pl0UxTImX30CvUskh7gABZdEQAB4dcbo= From: "LONJON Antoine" To: , , , , , , , , Cc: the bpdm team has posted an issue and a resolution to address the stability of xmi:id and the management of references accross miltiple files. We should ask for a vote on these resolutions Antoine -----Original Message----- From: Pete Rivett To: Nicolas Rouquette; uml2-rtf@omg.org; executableUMLFoundation@omg.org; Conrad Bock; Bran Selic; Ed Seidewitz; Stephen Mellor; Kenn Hussey CC: Andrew Watson Sent: Wed Aug 13 21:12:59 2008 Subject: RE: unalabelled association-owned memberEnd property names affect the name of an association Well-spotted Nicolas: though from your example fragments you.re wrong to say that at 2.2 the ends are given a generic name . they are given a generic xmi:id and no name at all! Both the change of name and (to a lesser extent) xmi:id, without being mandated by an issue resolution are IMHO serious bugs. The xmi:id case is more controversial, since xmi:ids do not in general have to be stable. However, since they are frequently used for referencing the elements from outside the file (e.g. using XMI hrefs) then for standard metamodels I think we should keep them stable. In fact I.d say that we should probably treat this as an urgent issue and produce a new XMI file ASAP. From the difference between the 2 fragments I spotted another discrepancy/bug in UML 2.2 . there is an incorrect owningAssociation attriibute on the Property. This must not be serialized since it.s the opposite of the composite owner of the Property (Association.ownedEnd) and so redundant. Clearly we should do more to perform diffs between the different versions of XMI files in order to catch inadvertent changes such as this. Pete From: Nicolas Rouquette [mailto:nicolas.rouquette@jpl.nasa.gov] Sent: 13 August 2008 19:15 To: uml2-rtf@omg.org; executableUMLFoundation@omg.org; Conrad Bock; Bran Selic; Ed Seidewitz; Stephen Mellor Subject: unalabelled association-owned memberEnd property names affect the name of an association I noticed strange differences between the XMI serialization of the UML superstructure in: UML 2.1.2, i.e: http://www.omg.org/spec/UML/20061001/Superstructure.cmof UML 2.2 beta1, i.e: http://www.omg.org/cgi-bin/doc?ptc/08-05-12 For example, in UML 2.1.2, we have: whereas in UML 2.2beta1, we have: In both cases, this association is described in Fig. 11.13 Object Actions (CompleteActions) in a way where the name of an association-owned memberEnd property isn't shown whereas the name of a class-owned memberEnd property is shown according to the conventions specified in clause 6.4.2 of the UML superstructure spec. http://www.omg.org/cgi-bin/doc?ptc/08-05-05 http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/ The problem here is that the unlabelled association-owned memberEnd properties have been given generic names such as ownedEnd.0 instead of the convention defined in clause 6.4.2 -- i.e., the name of the class with a lowercase initial. Is it OK for association names to change in this manner from one rev to another or is this a bug? Regardless of whether it is a bug or not w.r.t. current OMG specs, there is certainly a very undesirable consequence in name-level changes between revisions for a given concept when these revisions have not changed the semantics of that concept. Such incidental name-level changes create a lot of problems w.r.t. a stable notion of identity across revisions for detecting semantically-relevant changes from semantically irrelevant changes. -- Nicolas. **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended or the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** Subject: Re: unalabelled association-owned memberEnd property names affect the name of an association Date: Thu, 14 Aug 2008 06:11:54 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: unalabelled association-owned memberEnd property names affect the name of an association Thread-Index: Acj9cJv1+x0Pl0UxTImX30CvUskh7gABZdEQAB/+W0Q= From: "Kenn Hussey" To: , , , , , , , Cc: X-OriginalArrivalTime: 14 Aug 2008 10:11:55.0499 (UTC) FILETIME=[2DF6CBB0:01C8FDF6] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-5.5.1027-15992.005 X-TM-AS-Result: No--18.055400-8.000000-31 Given that the files were produced under pressure at the last possible moment and received little to no review (as usual), it's not surprising that there were mistakes. I'd be happy to work with Pete to produce the corrected files. With any luck, it won't be long before we have tooling to automate the production of these files (and to reduce the possibility of errors like this)... Kenn -------------------------- Sent using BlackBerry ----- Original Message ----- From: Pete Rivett To: Nicolas Rouquette ; uml2-rtf@omg.org ; executableUMLFoundation@omg.org ; Conrad Bock ; Bran Selic ; Ed Seidewitz ; Stephen Mellor ; Kenn Hussey Cc: Andrew Watson Sent: Wed Aug 13 12:12:59 2008 Subject: RE: unalabelled association-owned memberEnd property names affect the name of an association Well-spotted Nicolas: though from your example fragments you.re wrong to say that at 2.2 the ends are given a generic name . they are given a generic xmi:id andd no name at all! Both the change of name and (to a lesser extent) xmi:id, without being mandated by an issue resolution are IMHO serious bugs. The xmi:id case is more controversial, since xmi:ids do not in general have to be stable. However, since they are frequently used for referencing the elements from outside the file (e.g. using XMI hrefs) then for standard metamodels I think we should keep them stable. In fact I.d say that we should probably treat this as an urgent issue and produce a new XMI file ASAP. From the difference between the 2 fragments I spotted another discrepancy/bug in UML 2.2 . there is an incorrect owningAssociation attribute on the Property. This must not be serialized since it.s the opposite of the composite owner of the Property (Association.ownedEnd) and so redundant. Clearly we should do more to perform diffs between the different versions of XMI files in order to catch inadvertent changes such as this. Pete From: Nicolas Rouquette [mailto:nicolas.rouquette@jpl.nasa.gov] Sent: 13 August 2008 19:15 To: uml2-rtf@omg.org; executableUMLFoundation@omg.org; Conrad Bock; Bran Selic; Ed Seidewitz; Stephen Mellor Subject: unalabelled association-owned memberEnd property names affect the name of an association I noticed strange differences between the XMI serialization of the UML superstructure in: UML 2.1.2, i.e: http://www.omg.org/spec/UML/20061001/Superstructure.cmof UML 2.2 beta1, i.e: http://www.omg.org/cgi-bin/doc?ptc/08-05-12 For example, in UML 2.1.2, we have: whereas in UML 2.2beta1, we have: In both cases, this association is described in Fig. 11.13 Object Actions (CompleteActions) in a way where the name of an association-owned memberEnd property isn't shown whereas the name of a class-owned memberEnd property is shown according to the conventions specified in clause 6.4.2 of the UML superstructure spec. http://www.omg.org/cgi-bin/doc?ptc/08-05-05 http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/ The problem here is that the unlabelled association-owned memberEnd properties have been given generic names such as ownedEnd.0 instead of the convention defined in clause 6.4.2 -- i.e., the name of the class with a lowercase initial. Is it OK for association names to change in this manner from one rev to another or is this a bug? Regardless of whether it is a bug or not w.r.t. current OMG specs, there is certainly a very undesirable consequence in name-level changes between revisions for a given concept when these revisions have not changed the semantics of that concept. Such incidental name-level changes create a lot of problems w.r.t. a stable notion of identity across revisions for detecting semantically-relevant changes from semantically irrelevant changes. -- Nicolas. CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Date: Thu, 14 Aug 2008 08:35:39 -0700 From: Nicolas Rouquette User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) To: Kenn Hussey Cc: pete.rivett@adaptive.com, uml2-rtf@omg.org, executableUMLFoundation@omg.org, conrad.bock@nist.gov, bran.selic@gmail.com, ed-s@modeldriven.com, StephenMellor@StephenMellor.com, andrew@omg.org Subject: Re: unalabelled association-owned memberEnd property names affect the name of an association X-Source-IP: rse6g.jpl.nasa.gov [137.78.29.64] X-Source-Sender: nicolas.rouquette@jpl.nasa.gov X-AUTH: Authorized X-AUTH: Authorized Kenn, Pete, To help reduce the possibility of errors about names & XMI IDs, I propose verifying that the elements of the metamodel whose metatype is particularly important w.r.t. serialization and package merging have a name. Based on constraint #4 in semantics of PackageMerge in 7.3.40 and the metatype-specific matching rules, I propose the following OCL constraint to verify that everything that should be named has a name. Note in particular that the current package merge semantics do not require elements whose metatype is a kind of Constraint to be named. context: Package self.allOwnedElements() ->select(oclIsKindOf(uml::Package) or oclIsKindOf(uml::Class) or oclIsKindOf(uml::DataType) or oclIsKindOf(uml::Property) or oclIsKindOf(uml::Association) or oclIsKindOf(uml::Operation)or oclIsKindOf(uml::Enumeration) or oclIsKindOf(uml::EnumerationLiteral)) ->forAll(name->notEmpty()) It would be great if the xmi:id attribute in the serialization would be canonically derived from the name and/or the qualified name of the element in the cases mentioned above. -- Nicolas. Kenn Hussey wrote: Given that the files were produced under pressure at the last possible moment and received little to no review (as usual), it's not surprising that there were mistakes. I'd be happy to work with Pete to produce the corrected files. With any luck, it won't be long before we have tooling to automate the production of these files (and to reduce the possibility of errors like this)... Kenn -------------------------- Sent using BlackBerry ----- Original Message ----- From: Pete Rivett To: Nicolas Rouquette ; uml2-rtf@omg.org ; executableUMLFoundation@omg.org ; Conrad Bock ; Bran Selic ; Ed Seidewitz ; Stephen Mellor ; Kenn Hussey Cc: Andrew Watson Sent: Wed Aug 13 12:12:59 2008 Subject: RE: unalabelled association-owned memberEnd property names affect the name of an association Well-spotted Nicolas: though from your example fragments youâ..re wrong to say that at 2.2 the ends are given a generic name â.. they are given a generic xmi:id and no name at all! Both the change of name and (to a lesser extent) xmi:id, without being mandated by an issue resolution are IMHO serious bugs. The xmi:id case is more controversial, since xmi:ids do not in general have to be stable. However, since they are frequently used for referencing the elements from outside the file (e.g. using XMI hrefs) then for standard metamodels I think we should keep them stable. In fact Iâ..d say that we should probably treat this as an urgent issue and produce a new XMI file ASAP. >From the difference between the 2 fragments I spotted another discrepancy/bug in UML 2.2 â.. there is an incorrect owningAssociation attribute on the Property. This must not be serialized since itâ..s the opposite of the composite owner of the Property (Association.ownedEnd) and so redundant. Clearly we should do more to perform diffs between the different versions of XMI files in order to catch inadvertent changes such as this. Pete From: Nicolas Rouquette [mailto:nicolas.rouquette@jpl.nasa.gov] Sent: 13 August 2008 19:15 To: uml2-rtf@omg.org; executableUMLFoundation@omg.org; Conrad Bock; Bran Selic; Ed Seidewitz; Stephen Mellor Subject: unalabelled association-owned memberEnd property names affect the name of an association I noticed strange differences between the XMI serialization of the UML superstructure in: UML 2.1.2, i.e: http://www.omg.org/spec/UML/20061001/Superstructure.cmof UML 2.2 beta1, i.e: http://www.omg.org/cgi-bin/doc?ptc/08-05-12 For example, in UML 2.1.2, we have: whereas in UML 2.2beta1, we have: In both cases, this association is described in Fig. 11.13 Object Actions (CompleteActions) in a way where the name of an association-owned memberEnd property isn't shown whereas the name of a class-owned memberEnd property is shown according to the conventions specified in clause 6.4.2 of the UML superstructure spec. http://www.omg.org/cgi-bin/doc?ptc/08-05-05 http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/ The problem here is that the unlabelled association-owned memberEnd properties have been given generic names such as ownedEnd.0 instead of the convention defined in clause 6.4.2 -- i.e., the name of the class with a lowercase initial. Is it OK for association names to change in this manner from one rev to another or is this a bug? Regardless of whether it is a bug or not w.r.t. current OMG specs, there is certainly a very undesirable consequence in name-level changes between revisions for a given concept when these revisions have not changed the semantics of that concept. Such incidental name-level changes create a lot of problems w.r.t. a stable notion of identity across revisions for detecting semantically-relevant changes from semantically irrelevant changes. -- Nicolas. CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Subject: RE: unalabelled association-owned memberEnd property names affect the name of an association Date: Tue, 19 Aug 2008 21:03:38 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: unalabelled association-owned memberEnd property names affect the name of an association Thread-Index: Acj+IzXhcUzTkRSeTsKvoNONuIWFEwEPDQgQ From: "Kenn Hussey" To: "Nicolas Rouquette" Cc: , , , , , , , X-OriginalArrivalTime: 20 Aug 2008 01:04:03.0919 (UTC) FILETIME=[A3743DF0:01C90260] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-5.5.1027-15992.005 X-TM-AS-Result: No--22.605200-8.000000-31 Nicolas, Attached is an updated set of XMI files which I hope will address your concerns. Others, please review them (if you have the chance) for completeness/correctness. Note that I.ve also included the (non-normative) XMI files for the merged compliance levels, except for L1. Unfortunately, it appears that the resolution for issue 11409 inadvertently introduced an inconsistency with that compliance level: TimeEvent::when is now typed by TimeExpression from the SimpleTime package, but SimpleTime is not merged into L1. We should probably address this problem (by adding a merge?) as part of our response to issue 12774. < Cheers, Kenn Hussey Program Manager, Modeling and Design Solutions Embarcadero Technologies, Inc. | www.embarcadero.com 110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4 Kenn.Hussey@embarcadero.com Mobile: 613-301-9105 From: Nicolas Rouquette [mailto:nicolas.rouquette@jpl.nasa.gov] Sent: Thursday, August 14, 2008 11:36 AM To: Kenn Hussey Cc: pete.rivett@adaptive.com; uml2-rtf@omg.org; executableUMLFoundation@omg.org; conrad.bock@nist.gov; bran.selic@gmail.com; ed-s@modeldriven.com; StephenMellor@StephenMellor.com; andrew@omg.org Subject: Re: unalabelled association-owned memberEnd property names affect the name of an association Kenn, Pete, To help reduce the possibility of errors about names & XMI IDs, I propose verifying that the elements of the metamodel whose metatype is particularly important w.r.t. serialization and package merging have a name. Based on constraint #4 in semantics of PackageMerge in 7.3.40 and the metatype-specific matching rules, I propose the following OCL constraint to verify that everything that should be named has a name. Note in particular that the current package merge semantics do not require elements whose metatype is a kind of Constraint to be named. context: Package self.allOwnedElements() ->select(oclIsKindOf(uml::Package) or oclIsKindOf(uml::Class) or oclIsKindOf(uml::DataType) or oclIsKindOf(uml::Property) or oclIsKindOf(uml::Association) or oclIsKindOf(uml::Operation)or oclIsKindOf(uml::Enumeration) or oclIsKindOf(uml::EnumerationLiteral)) ->forAll(name->notEmpty()) It would be great if the xmi:id attribute in the serialization would be canonically derived from the name and/or the qualified name of the element in the cases mentioned above. -- Nicolas. Kenn Hussey wrote: Given that the files were produced under pressure at the last possible moment and received little to no review (as usual), it's not surprising that there were mistakes. I'd be happy to work with Pete to produce the corrected files. With any luck, it won't be long before we have tooling to automate the production of these files (and to reduce the possibility of errors like this)... Kenn -------------------------- Sent using BlackBerry ----- Original Message ----- From: Pete Rivett To: Nicolas Rouquette ; uml2-rtf@omg.org ; executableUMLFoundation@omg.org ; Conrad Bock ; Bran Selic ; Ed Seidewitz ; Stephen Mellor ; Kenn Hussey Cc: Andrew Watson Sent: Wed Aug 13 12:12:59 2008 Subject: RE: unalabelled association-owned memberEnd property names affect the name of an association Well-spotted Nicolas: though from your example fragments youâ..re wrong to say that at 2.2 the he ends are given a generic name â.. they are given a ggeneric xmi:id and no name at all! Both the change of name and (to a lesser extent) xmi:id, without being mandated by an issue resolution are IMHO serious bugs. The xmi:id case is more controversial, since xmi:ids do not in general have to be stable. However, since they are frequently used for referencing the elements from outside the file (e.g. using XMI hrefs) then for standard metamodels I think we should keep them stable. In fact Iâ..d say that we shoshould probably treat this as an urgent issue and produce a new XMI file ASAP. From the difference between the 2 fragments I spotted another discrepancy/bug in UML 2.2 â.. there is an incorrect owningAAssociation attribute on the Property. This must not be serialized since itâ..s the opposite of the compositsite owner of the Property (Association.ownedEnd) and so redundant. Clearly we should do more to perform diffs between the different versions of XMI files in order to catch inadvertent changes such as this. Pete From: Nicolas Rouquette [mailto:nicolas.rouquette@jpl.nasa.gov] Sent: 13 August 2008 19:15 To: uml2-rtf@omg.org; executableUMLFoundation@omg.org; Conrad Bock; Bran Selic; Ed Seidewitz; Stephen Mellor Subject: unalabelled association-owned memberEnd property names affect the name of an association I noticed strange differences between the XMI serialization of the UML superstructure in: UML 2.1.2, i.e: http://www.omg.org/spec/UML/20061001/Superstructure.cmof UML 2.2 beta1, i.e: http://www.omg.org/cgi-bin/doc?ptc/08-05-12 For example, in UML 2.1.2, we have: whereas in UML 2.2beta1, we have: In both cases, this association is described in Fig. 11.13 Object Actions (CompleteActions) in a way where the name of an association-owned memberEnd property isn't shown whereas the name of a class-owned memberEnd property is shown according to the conventions specified in clause 6.4.2 of the UML superstructure spec. http://www.omg.org/cgi-bin/doc?ptc/08-05-05 http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/ The problem here is that the unlabelled association-owned memberEnd properties have been given generic names such as ownedEnd.0 instead of the convention defined in clause 6.4.2 -- i.e., the name of the class with a lowercase initial. Is it OK for association names to change in this manner from one rev to another or is this a bug? Regardless of whether it is a bug or not w.r.t. current OMG specs, there is certainly a very undesirable consequence in name-level changes between revisions for a given concept when these revisions have not changed the semantics of that concept. Such incidental name-level changes create a lot of problems w.r.t. a stable notion of identity across revisions for detecting semantically-relevant changes from semantically irrelevant changes. -- Nicolas. CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. UML2_2.zip Date: Tue, 19 Aug 2008 21:24:54 -0700 From: Nicolas Rouquette User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) To: Kenn Hussey Cc: pete.rivett@adaptive.com, uml2-rtf@omg.org, executableUMLFoundation@omg.org, conrad.bock@nist.gov, bran.selic@gmail.com, ed-s@modeldriven.com, StephenMellor@StephenMellor.com, andrew@omg.org Subject: Re: unalabelled association-owned memberEnd property names affect the name of an association X-Source-IP: vpn-149-244-066.jpl.nasa.gov [128.149.244.66] X-Source-Sender: nicolas.rouquette@jpl.nasa.gov X-AUTH: Authorized X-AUTH: Authorized Thanks Kenn! Do you know if there is anyone working on providing diagrams that are compliant with the notation guidelines specified in clause 6.4.2 of the UML superstructure spec? I understand this particular clause isn't normative but it would be nice to have diagrams that have been peer-reviewed w.r.t. compliance to these notation guidelines. That would help avoid a lot of unnecessary confusion and ambiguity. With Eclipse 3.4 + the UML2Tools stuff, I'd expect that we'd get a folder structure that mimicks the package structure of the UML superstructure where each diagram would be saved as a separate UML2tools diagram file. -- Nicolas. Kenn Hussey wrote: Nicolas, Attached is an updated set of XMI files which I hope will address your concerns. Others, please review them (if you have the chance) for completeness/correctness. Note that Iâ..ve also included the (non-normative) XMI files for the merged compliance levels, except for L1. Unfortunately, it appears that the resolution for issue 11409 inadvertently introduced an inconsistency with that compliance level: TimeEvent::when is now typed by TimeExpression from the SimpleTime package, but SimpleTime is not merged into L1. We should probably address this problem (by adding a merge?) as part of our response to issue 12774â.¦ Cheers, Kenn Hussey Program Manager, Modeling and Design Solutions Embarcadero Technologies, Inc. | www.embarcadero.com 110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4 Kenn.Hussey@embarcadero.com Mobile: 613-301-9105 From: Nicolas Rouquette [mailto:nicolas.rouquette@jpl.nasa.gov] Sent: Thursday, August 14, 2008 11:36 AM To: Kenn Hussey Cc: pete.rivett@adaptive.com; uml2-rtf@omg.org; executableUMLFoundation@omg.org; conrad.bock@nist.gov; bran.selic@gmail.com; ed-s@modeldriven.com; StephenMellor@StephenMellor.com; andrew@omg.org Subject: Re: unalabelled association-owned memberEnd property names affect the name of an association Kenn, Pete, To help reduce the possibility of errors about names & XMI IDs, I propose verifying that the elements of the metamodel whose metatype is particularly important w.r.t. serialization and package merging have a name. Based on constraint #4 in semantics of PackageMerge in 7.3.40 and the metatype-specific matching rules, I propose the following OCL constraint to verify that everything that should be named has a name. Note in particular that the current package merge semantics do not require elements whose metatype is a kind of Constraint to be named. context: Package self.allOwnedElements() ->select(oclIsKindOf(uml::Package) or oclIsKindOf(uml::Class) or oclIsKindOf(uml::DataType) or oclIsKindOf(uml::Property) or oclIsKindOf(uml::Association) or oclIsKindOf(uml::Operation)or oclIsKindOf(uml::Enumeration) or oclIsKindOf(uml::EnumerationLiteral)) ->forAll(name->notEmpty()) It would be great if the xmi:id attribute in the serialization would be canonically derived from the name and/or the qualified name of the element in the cases mentioned above. -- Nicolas. Kenn Hussey wrote: Given that the files were produced under pressure at the last possible moment and received little to no review (as usual), it's not surprising that there were mistakes. I'd be happy to work with Pete to produce the corrected files. With any luck, it won't be long before we have tooling to automate the production of these files (and to reduce the possibility of errors like this)... Kenn -------------------------- Sent using BlackBerry ----- Original Message ----- From: Pete Rivett To: Nicolas Rouquette ; uml2-rtf@omg.org ; executableUMLFoundation@omg.org ; Conrad Bock ; Bran Selic ; Ed Seidewitz ; Stephen Mellor ; Kenn Hussey Cc: Andrew Watson Sent: Wed Aug 13 12:12:59 2008 Subject: RE: unalabelled association-owned memberEnd property names affect the name of an association Well-spotted Nicolas: though from your example fragments youââ.¬â.¢re wrong to say that at 2.2 the ends are given a generic name ââ.¬â.. they are given a generic xmi:id and no name at all! Both the change of name and (to a lesser extent) xmi:id, without being mandated by an issue resolution are IMHO serious bugs. The xmi:id case is more controversial, since xmi:ids do not in general have to be stable. However, since they are frequently used for referencing the elements from outside the file (e.g. using XMI hrefs) then for standard metamodels I think we should keep them stable. In fact Iââ.¬â.¢d say that we should probably treat this as an urgent issue and produce a new XMI file ASAP. >From the difference between the 2 fragments I spotted another discrepancy/bug in UML 2.2 ââ.¬â.. there is an incorrect owningAssociation attribute on the Property. This must not be serialized since itââ.¬â.¢s the opposite of the composite owner of the Property (Association.ownedEnd) and so redundant. Clearly we should do more to perform diffs between the different versions of XMI files in order to catch inadvertent changes such as this. Pete From: Nicolas Rouquette [mailto:nicolas.rouquette@jpl.nasa.gov] Sent: 13 August 2008 19:15 To: uml2-rtf@omg.org; executableUMLFoundation@omg.org; Conrad Bock; Bran Selic; Ed Seidewitz; Stephen Mellor Subject: unalabelled association-owned memberEnd property names affect the name of an association I noticed strange differences between the XMI serialization of the UML superstructure in: UML 2.1.2, i.e: http://www.omg.org/spec/UML/20061001/Superstructure.cmof UML 2.2 beta1, i.e: http://www.omg.org/cgi-bin/doc?ptc/08-05-12 For example, in UML 2.1.2, we have: whereas in UML 2.2beta1, we have: In both cases, this association is described in Fig. 11.13 Object Actions (CompleteActions) in a way where the name of an association-owned memberEnd property isn't shown whereas the name of a class-owned memberEnd property is shown according to the conventions specified in clause 6.4.2 of the UML superstructure spec. http://www.omg.org/cgi-bin/doc?ptc/08-05-05 http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/ The problem here is that the unlabelled association-owned memberEnd properties have been given generic names such as ownedEnd.0 instead of the convention defined in clause 6.4.2 -- i.e., the name of the class with a lowercase initial. Is it OK for association names to change in this manner from one rev to another or is this a bug? Regardless of whether it is a bug or not w.r.t. current OMG specs, there is certainly a very undesirable consequence in name-level changes between revisions for a given concept when these revisions have not changed the semantics of that concept. Such incidental name-level changes create a lot of problems w.r.t. a stable notion of identity across revisions for detecting semantically-relevant changes from semantically irrelevant changes. -- Nicolas. CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.  CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=0J99kKQA2WpnUCLPhVkCb776KbCoHUtiGSSIKG80kp0=; b=TdzPATtsybHtWNeXEMKDXcJG4Y9T2VJeTJph8KX39lhQf8btk16EcaNs3VK/R5nXPI Ge++86JBh3d/cqbt4v0UV4dSuRiko0/U9r8CPypRkNfXM8F6vZxcr+aglGm/SNyE+Dwe iAm6Z5dWmCXnJEirDMbr79eUmhGFl05O5UKMY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=vM8dRDtQzbiszRYeW/rKoddSmROcv/Zzxg1n1NPtT07siTFW5H80bdlDKHiO0qVOUn TAjaDxDUShEWqDt51YYUceVcaioHQGXQxDt9zUm7LHK/snpDymocW/pHKWd5yKWDoLYq aQcFFc8SFm6IQ1TfFwXjPB09jSxFkeMl3Ax6U= Date: Wed, 20 Aug 2008 02:08:13 -0400 From: "Bran Selic" To: "Nicolas Rouquette" Subject: Re: unalabelled association-owned memberEnd property names affect the name of an association Cc: "Kenn Hussey" , pete.rivett@adaptive.com, uml2-rtf@omg.org, executableUMLFoundation@omg.org, conrad.bock@nist.gov, ed-s@modeldriven.com, StephenMellor@StephenMellor.com, andrew@omg.org FWIW, I did all the diagrams in the UML 2.2 spec -- using the guidelines I came up with in section 6.4.2. Is there a problem? Bran On Wed, Aug 20, 2008 at 12:24 AM, Nicolas Rouquette wrote: Thanks Kenn! Do you know if there is anyone working on providing diagrams that are compliant with the notation guidelines specified in clause 6.4.2 of the UML superstructure spec? I understand this particular clause isn't normative but it would be nice to have diagrams that have been peer-reviewed w.r.t. compliance to these notation guidelines. That would help avoid a lot of unnecessary confusion and ambiguity. With Eclipse 3.4 + the UML2Tools stuff, I'd expect that we'd get a folder structure that mimicks the package structure of the UML superstructure where each diagram would be saved as a separate UML2tools diagram file. -- Nicolas. Kenn Hussey wrote: Nicolas, Attached is an updated set of XMI files which I hope will address your concerns. Others, please review them (if you have the chance) for completeness/correctness. Note that Iâ..ve also included the (non-normative) XMI files for the merged compliance levels, except for L1. Unfortunately, it appears that the resolution for issue 11409 inadvertently introduced an inconsistency with that compliance level: TimeEvent::when is now typed by TimeExpression from the SimpleTime package, but SimpleTime is not merged into L1. We should probably address this problem (by adding a merge?) as part of our response to issue 12774â.¦ Cheers, Kenn Hussey Program Manager, Modeling and Design Solutions Embarcadero Technologies, Inc. | www.embarcadero.com 110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4 Kenn.Hussey@embarcadero.com Mobile: 613-301-9105 From: Nicolas Rouquette [mailto:nicolas.rouquette@jpl.nasa.gov] Sent: Thursday, August 14, 2008 11:36 AM To: Kenn Hussey Cc: pete.rivett@adaptive.com; uml2-rtf@omg.org; executableUMLFoundation@omg.org; conrad.bock@nist.gov; bran.selic@gmail.com; ed-s@modeldriven.com; StephenMellor@StephenMellor.com; andrew@omg.org Subject: Re: unalabelled association-owned memberEnd property names affect the name of an association Kenn, Pete, To help reduce the possibility of errors about names & XMI IDs, I propose verifying that the elements of the metamodel whose metatype is particularly important w.r.t. serialization and package merging have a name. Based on constraint #4 in semantics of PackageMerge in 7.3.40 and the metatype-specific matching rules, I propose the following OCL constraint to verify that everything that should be named has a name. Note in particular that the current package merge semantics do not require elements whose metatype is a kind of Constraint to be named. context: Package self.allOwnedElements() ->select(oclIsKindOf(uml::Package) or oclIsKindOf(uml::Class) or oclIsKindOf(uml::DataType) or oclIsKindOf(uml::Property) or oclIsKindOf(uml::Association) or oclIsKindOf(uml::Operation)or oclIsKindOf(uml::Enumeration) or oclIsKindOf(uml::EnumerationLiteral)) ->forAll(name->notEmpty()) It would be great if the xmi:id attribute in the serialization would be canonically derived from the name and/or the qualified name of the element in the cases mentioned above. -- Nicolas. Kenn Hussey wrote: Given that the files were produced under pressure at the last possible moment and received little to no review (as usual), it's not surprising that there were mistakes. I'd be happy to work with Pete to produce the corrected files. With any luck, it won't be long before we have tooling to automate the production of these files (and to reduce the possibility of errors like this)... Kenn -------------------------- Sent using BlackBerry ----- Original Message ----- From: Pete Rivett To: Nicolas Rouquette ; uml2-rtf@omg.org ; executableUMLFoundation@omg.org ; Conrad Bock ; Bran Selic ; Ed Seidewitz ; Stephen Mellor ; Kenn Hussey Cc: Andrew Watson Sent: Wed Aug 13 12:12:59 2008 Subject: RE: unalabelled association-owned memberEnd property names affect the name of an association Well-spotted Nicolas: though from your example fragments youââ.¬â.¢re wrong to say that at 2.2 the ends are given a generic name ââ.¬â.. they are given a generic xmi:id and no name at all! Both the change of name and (to a lesser extent) xmi:id, without being mandated by an issue resolution are IMHO serious bugs. The xmi:id case is more controversial, since xmi:ids do not in general have to be stable. However, since they are frequently used for referencing the elements from outside the file (e.g. using XMI hrefs) then for standard metamodels I think we should keep them stable. In fact Iââ.¬â.¢d say that we should probably treat this as an urgent issue and produce a new XMI file ASAP. >From the difference between the 2 fragments I spotted another discrepancy/bug in UML 2.2 ââ.¬â.. there is an incorrect owningAssociation attribute on the Property. This must not be serialized since itââ.¬â.¢s the opposite of the composite owner of the Property (Association.ownedEnd) and so redundant. Clearly we should do more to perform diffs between the different versions of XMI files in order to catch inadvertent changes such as this. Pete From: Nicolas Rouquette [mailto:nicolas.rouquette@jpl.nasa.gov] Sent: 13 August 2008 19:15 To: uml2-rtf@omg.org; executableUMLFoundation@omg.org; Conrad Bock; Bran Selic; Ed Seidewitz; Stephen Mellor Subject: unalabelled association-owned memberEnd property names affect the name of an association I noticed strange differences between the XMI serialization of the UML superstructure in: UML 2.1.2, i.e: http://www.omg.org/spec/UML/20061001/Superstructure.cmof UML 2.2 beta1, i.e: http://www.omg.org/cgi-bin/doc?ptc/08-05-12 For example, in UML 2.1.2, we have: whereas in UML 2.2beta1, we have: In both cases, this association is described in Fig. 11.13 Object Actions (CompleteActions) in a way where the name of an association-owned memberEnd property isn't shown whereas the name of a class-owned memberEnd property is shown according to the conventions specified in clause 6.4.2 of the UML superstructure spec. http://www.omg.org/cgi-bin/doc?ptc/08-05-05 http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/ The problem here is that the unlabelled association-owned memberEnd properties have been given generic names such as ownedEnd.0 instead of the convention defined in clause 6.4.2 -- i.e., the name of the class with a lowercase initial. Is it OK for association names to change in this manner from one rev to another or is this a bug? Regardless of whether it is a bug or not w.r.t. current OMG specs, there is certainly a very undesirable consequence in name-level changes between revisions for a given concept when these revisions have not changed the semantics of that concept. Such incidental name-level changes create a lot of problems w.r.t. a stable notion of identity across revisions for detecting semantically-relevant changes from semantically irrelevant changes. -- Nicolas. CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.  CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -- Bran Selic Malina Software Corp. Content-Type: image/jpeg Content-ID: X-Attachment-Id: 0.1.1 Date: Wed, 20 Aug 2008 00:42:31 -0700 From: Nicolas Rouquette User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) To: Bran Selic Cc: Kenn Hussey , pete.rivett@adaptive.com, uml2-rtf@omg.org, executableUMLFoundation@omg.org, conrad.bock@nist.gov, ed-s@modeldriven.com, StephenMellor@StephenMellor.com, andrew@omg.org Subject: Re: unalabelled association-owned memberEnd property names affect the name of an association X-Source-IP: vpn-149-244-040.jpl.nasa.gov [128.149.244.40] X-Source-Sender: nicolas.rouquette@jpl.nasa.gov X-AUTH: Authorized X-AUTH: Authorized Bran, This particular issue is about two bullets in clause 6.4.2: --------------------- If an association end is unlabeled, the default name for that end is the name of the class to which the end is attached, modified such that the first letter is a lowercase letter. (Note that, by convention, non-navigable association ends are often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal constraints - although they may be needed for other purposes, such as MOF language bindings that use the metamodel.) Associations that are not explicitly named, are given names that are constructed according to the following production rule: "A_" "_" where is the name of the first association end and is the name of the second association end. --------------------- Many diagrams in the UML specs (infra/super) have unlabeled association end properties which, according to the first bullet, should be named, by default, according to the class to which the end is attached. You used RSA to edit the UML2.2 diagrams but RSA doesn't behave according to these bullets. One can hardly blame IBM for that since these guidelines are very specific to UML-like metamodels and they may not be generalically applicable in other domains. -- Nicolas. Bran Selic wrote: FWIW, I did all the diagrams in the UML 2.2 spec -- using the guidelines I came up with in section 6.4.2. Is there a problem? Bran On Wed, Aug 20, 2008 at 12:24 AM, Nicolas Rouquette > wrote: Thanks Kenn! Do you know if there is anyone working on providing diagrams that are compliant with the notation guidelines specified in clause 6.4.2 of the UML superstructure spec? I understand this particular clause isn't normative but it would be nice to have diagrams that have been peer-reviewed w.r.t. compliance to these notation guidelines. That would help avoid a lot of unnecessary confusion and ambiguity. With Eclipse 3.4 + the UML2Tools stuff, I'd expect that we'd get a folder structure that mimicks the package structure of the UML superstructure where each diagram would be saved as a separate UML2tools diagram file. -- Nicolas. Kenn Hussey wrote: Nicolas, Attached is an updated set of XMI files which I hope will address your concerns. Others, please review them (if you have the chance) for completeness/correctness. Note that Iâ..ve also included the (non-normative) XMI files for the merged compliance levels, *except for L1*. Unfortunately, it appears that the resolution for issue 11409 inadvertently introduced an inconsistency with that compliance level: TimeEvent::when is now typed by TimeExpression from the SimpleTime package, but SimpleTime is not merged into L1. We should probably address this problem (by adding a merge?) as part of our response to issue 12774â.¦ Cheers, ** *Kenn Hussey** **Program Manager, Modeling and Design Solutions***** *[Embarcadero Technologies Logo]* *Embarcadero Technologies, Inc. | **www.embarcadero.com* * ** **110 Spadina Avenue, Suite 400** | **Toronto, ON M5V 2K4** **Kenn.Hussey@embarcadero.com* *Mobile**: 613-301-9105* *From:* Nicolas Rouquette [mailto:nicolas.rouquette@jpl.nasa.gov] *Sent:* Thursday, August 14, 2008 11:36 AM *To:* Kenn Hussey *Cc:* pete.rivett@adaptive.com ; uml2-rtf@omg.org ; executableUMLFoundation@omg.org ; conrad.bock@nist.gov ; bran.selic@gmail.com ; ed-s@modeldriven.com ; StephenMellor@StephenMellor.com ; andrew@omg.org *Subject:* Re: unalabelled association-owned memberEnd property names affect the name of an association Kenn, Pete, To help reduce the possibility of errors about names & XMI IDs, I propose verifying that the elements of the metamodel whose metatype is particularly important w.r.t. serialization and package merging have a name. Based on constraint #4 in semantics of PackageMerge in 7.3.40 and the metatype-specific matching rules, I propose the following OCL constraint to verify that everything that should be named has a name. Note in particular that the current package merge semantics do not require elements whose metatype is a kind of Constraint to be named. context: Package self.allOwnedElements() ->select(oclIsKindOf(uml::Package) or oclIsKindOf(uml::Class) or oclIsKindOf(uml::DataType) or oclIsKindOf(uml::Property) or oclIsKindOf(uml::Association) or oclIsKindOf(uml::Operation)or oclIsKindOf(uml::Enumeration) or oclIsKindOf(uml::EnumerationLiteral)) ->forAll(name->notEmpty()) It would be great if the xmi:id attribute in the serialization would be canonically derived from the name and/or the qualified name of the element in the cases mentioned above. -- Nicolas. Kenn Hussey wrote: Given that the files were produced under pressure at the last possible moment and received little to no review (as usual), it's not surprising that there were mistakes. I'd be happy to work with Pete to produce the corrected files. With any luck, it won't be long before we have tooling to automate the production of these files (and to reduce the possibility of errors like this)... Kenn -------------------------- Sent using BlackBerry ----- Original Message ----- From: Pete Rivett To: Nicolas Rouquette ; uml2-rtf@omg.org ; executableUMLFoundation@omg.org ; Conrad Bock ; Bran Selic ; Ed Seidewitz ; Stephen Mellor ; Kenn Hussey Cc: Andrew Watson Sent: Wed Aug 13 12:12:59 2008 Subject: RE: unalabelled association-owned memberEnd property names affect the name of an association Well-spotted Nicolas: though from your example fragments youââ.¬â.¢re wrong to say that at 2.2 the ends are given a generic name ââ.¬â.. they are given a generic xmi:id and no name at all! Both the change of name and (to a lesser extent) xmi:id, without being mandated by an issue resolution are IMHO serious bugs. The xmi:id case is more controversial, since xmi:ids do not in general have to be stable. However, since they are frequently used for referencing the elements from outside the file (e.g. using XMI hrefs) then for standard metamodels I think we should keep them stable. In fact Iââ.¬â.¢d say that we should probably treat this as an urgent issue and produce a new XMI file ASAP. From the difference between the 2 fragments I spotted another discrepancy/bug in UML 2.2 ââ.¬â.. there is an incorrect owningAssociation attribute on the Property. This must not be serialized since itââ.¬â.¢s the opposite of the composite owner of the Property (Association.ownedEnd) and so redundant. Clearly we should do more to perform diffs between the different versions of XMI files in order to catch inadvertent changes such as this. Pete From: Nicolas Rouquette [mailto:nicolas.rouquette@jpl.nasa.gov] Sent: 13 August 2008 19:15 To: uml2-rtf@omg.org ; executableUMLFoundation@omg.org ; Conrad Bock; Bran Selic; Ed Seidewitz; Stephen Mellor Subject: unalabelled association-owned memberEnd property names affect the name of an association I noticed strange differences between the XMI serialization of the UML superstructure in: UML 2.1.2, i.e: http://www.omg.org/spec/UML/20061001/Superstructure.cmof UML 2.2 beta1, i.e: http://www.omg.org/cgi-bin/doc?ptc/08-05-12 For example, in UML 2.1.2, we have: whereas in UML 2.2beta1, we have: In both cases, this association is described in Fig. 11.13 Object Actions (CompleteActions) in a way where the name of an association-owned memberEnd property isn't shown whereas the name of a class-owned memberEnd property is shown according to the conventions specified in clause 6.4.2 of the UML superstructure spec. http://www.omg.org/cgi-bin/doc?ptc/08-05-05 http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/ The problem here is that the unlabelled association-owned memberEnd properties have been given generic names such as ownedEnd.0 instead of the convention defined in clause 6.4.2 -- i.e., the name of the class with a lowercase initial. Is it OK for association names to change in this manner from one rev to another or is this a bug? Regardless of whether it is a bug or not w.r.t. current OMG specs, there is certainly a very undesirable consequence in name-level changes between revisions for a given concept when these revisions have not changed the semantics of that concept. Such incidental name-level changes create a lot of problems w.r.t. a stable notion of identity across revisions for detecting semantically-relevant changes from semantically irrelevant changes. -- Nicolas. CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.  CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -- Bran Selic Malina Software Corp. Subject: RE: unalabelled association-owned memberEnd property names affect the name of an association Date: Wed, 20 Aug 2008 10:03:10 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: unalabelled association-owned memberEnd property names affect the name of an association Thread-Index: AckCmByjscBmMyFMS5ydybk8mWcnhAANRbog From: "Kenn Hussey" To: "Nicolas Rouquette" , "Bran Selic" Cc: , , , , , , X-OriginalArrivalTime: 20 Aug 2008 14:03:19.0041 (UTC) FILETIME=[7FADAF10:01C902CD] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-5.5.1027-15992.005 X-TM-AS-Result: No--25.323100-8.000000-31 X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id m7KE5Kun028123 Nicolas, Actually, the first bullet notes that, by convention, non-navigable association ends are left unlabeled... so it would seem the diagrams in the specification do in fact follow this convention. The clause should perhaps also note, however, that association names are not shown in any of the diagrams in the specification... Cheers, Kenn Hussey Program Manager, Modeling and Design Solutions Embarcadero Technologies, Inc. | www.embarcadero.com 110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4 Kenn.Hussey@embarcadero.com Mobile: 613-301-9105 -----Original Message----- From: Nicolas Rouquette [mailto:nicolas.rouquette@jpl.nasa.gov] Sent: Wednesday, August 20, 2008 3:43 AM To: Bran Selic Cc: Kenn Hussey; pete.rivett@adaptive.com; uml2-rtf@omg.org; executableUMLFoundation@omg.org; conrad.bock@nist.gov; ed-s@modeldriven.com; StephenMellor@StephenMellor.com; andrew@omg.org Subject: Re: unalabelled association-owned memberEnd property names affect the name of an association Bran, This particular issue is about two bullets in clause 6.4.2: --------------------- If an association end is unlabeled, the default name for that end is the name of the class to which the end is attached, modified such that the first letter is a lowercase letter. (Note that, by convention, non-navigable association ends are often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal constraints - although they may be needed for other purposes, such as MOF language bindings that use the metamodel.) Associations that are not explicitly named, are given names that are constructed according to the following production rule: "A_" "_" where is the name of the first association end and is the name of the second association end. --------------------- Many diagrams in the UML specs (infra/super) have unlabeled association end properties which, according to the first bullet, should be named, by default, according to the class to which the end is attached. You used RSA to edit the UML2.2 diagrams but RSA doesn't behave according to these bullets. One can hardly blame IBM for that since these guidelines are very specific to UML-like metamodels and they may not be generalically applicable in other domains. -- Nicolas. Bran Selic wrote: > FWIW, I did all the diagrams in the UML 2.2 spec -- using the > guidelines I came up with in section 6.4.2. Is there a > problem? > > Bran > > On Wed, Aug 20, 2008 at 12:24 AM, Nicolas Rouquette > > wrote: > > Thanks Kenn! > > Do you know if there is anyone working on providing diagrams that > are compliant with the notation guidelines specified in clause > 6.4.2 of the UML superstructure spec? > I understand this particular clause isn't normative but it would > be nice to have diagrams that have been peer-reviewed w.r.t. > compliance to these notation guidelines. > That would help avoid a lot of unnecessary confusion and ambiguity. > > With Eclipse 3.4 + the UML2Tools stuff, I'd expect that we'd get a > folder structure that mimicks the package structure of the UML > superstructure where each diagram would be saved as a separate > UML2tools diagram file. > > > -- Nicolas. > > Kenn Hussey wrote: >> >> Nicolas, >> >> Attached is an updated set of XMI files which I hope will address >> your concerns. Others, please review them (if you have the >> chance) for completeness/correctness. Note that Iâ..ve also o >> included the (non-normative) XMI files for the merged compliance >> levels, *except for L1*. Unfortunately, it appears that the >> resolution for issue 11409 inadvertently introduced an >> inconsistency with that compliance level: TimeEvent::when is now >> typed by TimeExpression from the SimpleTime package, but >> SimpleTime is not merged into L1. We should probably address this >> problem (by adding a merge?) as part of our response to issue >> 12774â.¦ >> >> Cheers, >> >> ** >> >> *Kenn Hussey** >> **Program Manager, Modeling and Design Solutions***** >> >> *[Embarcadero Technologies Logo]* >> >> *Embarcadero Technologies, Inc. | **www.embarcadero.com* >> * ** >> **110 Spadina Avenue, Suite 400** | **Toronto, ON M5V 2K4** >> **Kenn.Hussey@embarcadero.com* >> *Mobile**: 613-301-9105* >> >> *From:* Nicolas Rouquette [mailto:nicolas.rouquette@jpl.nasa.gov] >> *Sent:* Thursday, August 14, 2008 11:36 AM >> *To:* Kenn Hussey >> *Cc:* pete.rivett@adaptive.com ; >> uml2-rtf@omg.org ; >> executableUMLFoundation@omg.org >> ; conrad.bock@nist.gov >> ; bran.selic@gmail.com >> ; ed-s@modeldriven.com >> ; StephenMellor@StephenMellor.com >> ; andrew@omg.org >> >> *Subject:* Re: unalabelled association-owned memberEnd property >> names affect the name of an association >> >> Kenn, Pete, >> >> To help reduce the possibility of errors about names & XMI IDs, I >> propose verifying that the elements of the metamodel whose >> metatype is particularly important w.r.t. serialization and >> package merging have a name. >> Based on constraint #4 in semantics of PackageMerge in 7.3.40 and >> the metatype-specific matching rules, I propose the following OCL >> constraint to verify that everything that should be named has a name. >> Note in particular that the current package merge semantics do >> not require elements whose metatype is a kind of Constraint to be >> named. >> >> context: Package >> self.allOwnedElements() >> ->select(oclIsKindOf(uml::Package) or oclIsKindOf(uml::Class) or >> oclIsKindOf(uml::DataType) >> or oclIsKindOf(uml::Property) or oclIsKindOf(uml::Association) >> or oclIsKindOf(uml::Operation)or oclIsKindOf(uml::Enumeration) >> or oclIsKindOf(uml::EnumerationLiteral)) >> ->forAll(name->notEmpty()) >> >> It would be great if the xmi:id attribute in the serialization >> would be canonically derived from the name and/or the qualified >> name of the element in the cases mentioned above. >> >> -- Nicolas. >> >> Kenn Hussey wrote: >> >> Given that the files were produced under pressure at the last >> possible moment and received little to no review (as usual), it's >> not surprising that there were mistakes. I'd be happy to work >> with Pete to produce the corrected files. >> >> With any luck, it won't be long before we have tooling to >> automate the production of these files (and to reduce the >> possibility of errors like this)... >> >> Kenn >> -------------------------- >> Sent using BlackBerry >> >> >> ----- Original Message ----- >> From: Pete Rivett >> >> To: Nicolas Rouquette >> ; uml2-rtf@omg.org >> >> ; executableUMLFoundation@omg.org >> >> >> ; Conrad Bock >> ; Bran Selic >> ; Ed >> Seidewitz ; >> Stephen Mellor >> ; Kenn Hussey >> Cc: Andrew Watson >> Sent: Wed Aug 13 12:12:59 2008 >> Subject: RE: unalabelled association-owned memberEnd property >> names affect the name of an association >> >> Well-spotted Nicolas: though from your example fragments >> youÃ.¢â.‰.¢re wrong to say that at 2.2 the ends are given a a >> generic name Ã.¢â.‰.. they are given a generic xmi:id and no name me >> at all! >> >> Both the change of name and (to a lesser extent) xmi:id, without >> being mandated by an issue resolution are IMHO serious bugs. >> >> The xmi:id case is more controversial, since xmi:ids do not in >> general have to be stable. However, since they are frequently >> used for referencing the elements from outside the file (e.g. >> using XMI hrefs) then for standard metamodels I think we should >> keep them stable. >> >> >> >> In fact IÃ.¢â.‰.¢d say that we should probably treat this as an n >> urgent issue and produce a new XMI file ASAP. >> >> >> >> From the difference between the 2 fragments I spotted another >> discrepancy/bug in UML 2.2 Ã.¢â.‰.. there is an incorrect ct >> owningAssociation attribute on the Property. This must not be >> serialized since itÃ.¢â.‰.¢s the opposite of the composite owner r >> of the Property (Association.ownedEnd) and so redundant. >> >> >> >> >> Clearly we should do more to perform diffs between the different >> versions of XMI files in order to catch inadvertent changes such >> as this. >> >> >> >> Pete >> >> >> >> >> >> >> >> From: Nicolas Rouquette [mailto:nicolas.rouquette@jpl.nasa.gov] >> Sent: 13 August 2008 19:15 >> To: uml2-rtf@omg.org ; >> executableUMLFoundation@omg.org >> ; Conrad Bock; Bran >> Selic; Ed Seidewitz; Stephen Mellor >> Subject: unalabelled association-owned memberEnd property names >> affect the name of an association >> >> >> >> I noticed strange differences between the XMI serialization of >> the UML superstructure in: >> >> UML 2.1.2, i.e: >> http://www.omg.org/spec/UML/20061001/Superstructure.cmof >> UML 2.2 beta1, i.e: http://www.omg.org/cgi-bin/doc?ptc/08-05-12 >> >> For example, in UML 2.1.2, we have: >> >> > xmi:id="Actions-CompleteActions-A_result_readExtentAction" >> name="A_result_readExtentAction" >> memberEnd="Actions-CompleteActions-ReadExtentAction-result >> Actions-CompleteActions-A_result_readExtentAction-readExtentAction"> >> > xmi:id="Actions-CompleteActions-A_result_readExtentAction-readExtentAction" >> name="readExtentAction" lower="0" >> type="Actions-CompleteActions-ReadExtentAction" >> association="Actions-CompleteActions-A_result_readExtentAction"/> >> >> >> whereas in UML 2.2beta1, we have: >> >> > xmi:id="Actions-CompleteActions-A_result_readExtentAction" >> name="A_result_readExtentAction" >> memberEnd="Actions-CompleteActions-ReadExtentAction-result >> Actions-CompleteActions-A_result_readExtentAction-_ownedEnd.0"> >> > xmi:id="Actions-CompleteActions-A_result_readExtentAction-_ownedEnd.0" >> type="Actions-CompleteActions-ReadExtentAction" lower="0" >> owningAssociation="Actions-CompleteActions-A_result_readExtentAction" >> association="Actions-CompleteActions-A_result_readExtentAction"/> >> >> >> In both cases, this association is described in Fig. 11.13 Object >> Actions (CompleteActions) in a way where the name of an >> association-owned memberEnd property isn't shown whereas the name >> of a class-owned memberEnd property is shown according to the >> conventions specified in clause 6.4.2 of the UML superstructure spec. >> >> http://www.omg.org/cgi-bin/doc?ptc/08-05-05 >> http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/ >> >> The problem here is that the unlabelled association-owned >> memberEnd properties have been given generic names such as >> ownedEnd.0 instead of the convention defined in clause 6.4.2 -- >> i.e., the name of the class with a lowercase initial. >> >> Is it OK for association names to change in this manner from one >> rev to another or is this a bug? >> >> Regardless of whether it is a bug or not w.r.t. current OMG >> specs, there is certainly a very undesirable consequence in >> name-level changes between revisions for a given concept when >> these revisions have not changed the semantics of that concept. >> Such incidental name-level changes create a lot of problems >> w.r.t. a stable notion of identity across revisions for detecting >> semantically-relevant changes from semantically irrelevant changes. >> >> -- Nicolas. >> >> CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) >> and may contain confidential and privileged information. Any unauthorized review, use, >> disclosure or distribution is prohibited. If you are not the intended recipient, please >> contact the sender by reply email and destroy all copies of the original message. >> Ã. >> >> CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) >> and may contain confidential and privileged information. Any unauthorized review, use, >> disclosure or distribution is prohibited. If you are not the intended recipient, please >> contact the sender by reply email and destroy all copies of the original message. >> > > > > > -- > Bran Selic > Malina Software Corp. CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please Date: Wed, 20 Aug 2008 07:19:39 -0700 From: Nicolas Rouquette User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) To: Kenn Hussey Cc: Bran Selic , pete.rivett@adaptive.com, uml2-rtf@omg.org, executableUMLFoundation@omg.org, conrad.bock@nist.gov, ed-s@modeldriven.com, StephenMellor@StephenMellor.com, andrew@omg.org Subject: Re: unalabelled association-owned memberEnd property names affect the name of an association X-Source-IP: rse6g.jpl.nasa.gov [137.78.29.64] X-Source-Sender: nicolas.rouquette@jpl.nasa.gov X-AUTH: Authorized X-AUTH: Authorized Kenn Hussey wrote: Nicolas, Actually, the first bullet notes that, by convention, non-navigable association ends are left unlabeled... so it would seem the diagrams in the specification do in fact follow this convention. Yes they do but the association end label isn't the same thing as the association end name as you pointed out below. The clause should perhaps also note, however, that association names are not shown in any of the diagrams in the specification... Indeed; however, we can easily check that the abstract syntax metamodel is well-formed even if some association ends are unlabeled in the diagrams. At least, I can confirm that the metamodel you sent is kosher in that regard. -- Nicolas. Cheers, Kenn Hussey Program Manager, Modeling and Design Solutions Embarcadero Technologies, Inc. | www.embarcadero.com 110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4 Kenn.Hussey@embarcadero.com Mobile: 613-301-9105 -----Original Message----- From: Nicolas Rouquette [mailto:nicolas.rouquette@jpl.nasa.gov] Sent: Wednesday, August 20, 2008 3:43 AM To: Bran Selic Cc: Kenn Hussey; pete.rivett@adaptive.com; uml2-rtf@omg.org; executableUMLFoundation@omg.org; conrad.bock@nist.gov; ed-s@modeldriven.com; StephenMellor@StephenMellor.com; andrew@omg.org Subject: Re: unalabelled association-owned memberEnd property names affect the name of an association Bran, This particular issue is about two bullets in clause 6.4.2: --------------------- If an association end is unlabeled, the default name for that end is the name of the class to which the end is attached, modified such that the first letter is a lowercase letter. (Note that, by convention, non-navigable association ends are often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal constraints - although they may be needed for other purposes, such as MOF language bindings that use the metamodel.) Associations that are not explicitly named, are given names that are constructed according to the following production rule: "A_" "_" where is the name of the first association end and is the name of the second association end. --------------------- Many diagrams in the UML specs (infra/super) have unlabeled association end properties which, according to the first bullet, should be named, by default, according to the class to which the end is attached. You used RSA to edit the UML2.2 diagrams but RSA doesn't behave according to these bullets. One can hardly blame IBM for that since these guidelines are very specific to UML-like metamodels and they may not be generalically applicable in other domains. -- Nicolas. Bran Selic wrote: FWIW, I did all the diagrams in the UML 2.2 spec -- using the guidelines I came up with in section 6.4.2. Is there a problem? Bran On Wed, Aug 20, 2008 at 12:24 AM, Nicolas Rouquette > wrote: Thanks Kenn! Do you know if there is anyone working on providing diagrams that are compliant with the notation guidelines specified in clause 6.4.2 of the UML superstructure spec? I understand this particular clause isn't normative but it would be nice to have diagrams that have been peer-reviewed w.r.t. compliance to these notation guidelines. That would help avoid a lot of unnecessary confusion and ambiguity. With Eclipse 3.4 + the UML2Tools stuff, I'd expect that we'd get a folder structure that mimicks the package structure of the UML superstructure where each diagram would be saved as a separate UML2tools diagram file. -- Nicolas. Kenn Hussey wrote: Nicolas, Attached is an updated set of XMI files which I hope will address your concerns. Others, please review them (if you have the chance) for completeness/correctness. Note that Iââ.¬â.¢ve also included the (non-normative) XMI files for the merged compliance levels, *except for L1*. Unfortunately, it appears that the resolution for issue 11409 inadvertently introduced an inconsistency with that compliance level: TimeEvent::when is now typed by TimeExpression from the SimpleTime package, but SimpleTime is not merged into L1. We should probably address this problem (by adding a merge?) as part of our response to issue 12774ââ.¬Â¦ Cheers, ** *Kenn Hussey** **Program Manager, Modeling and Design Solutions***** *[Embarcadero Technologies Logo]* *Embarcadero Technologies, Inc. | **www.embarcadero.com* * ** **110 Spadina Avenue, Suite 400** | **Toronto, ON M5V 2K4** **Kenn.Hussey@embarcadero.com* *Mobile**: 613-301-9105* *From:* Nicolas Rouquette [mailto:nicolas.rouquette@jpl.nasa.gov] *Sent:* Thursday, August 14, 2008 11:36 AM *To:* Kenn Hussey *Cc:* pete.rivett@adaptive.com ; uml2-rtf@omg.org ; executableUMLFoundation@omg.org ; conrad.bock@nist.gov ; bran.selic@gmail.com ; ed-s@modeldriven.com ; StephenMellor@StephenMellor.com ; andrew@omg.org *Subject:* Re: unalabelled association-owned memberEnd property names affect the name of an association Kenn, Pete, To help reduce the possibility of errors about names & XMI IDs, I propose verifying that the elements of the metamodel whose metatype is particularly important w.r.t. serialization and package merging have a name. Based on constraint #4 in semantics of PackageMerge in 7.3.40 and the metatype-specific matching rules, I propose the following OCL constraint to verify that everything that should be named has a name. Note in particular that the current package merge semantics do not require elements whose metatype is a kind of Constraint to be named. context: Package self.allOwnedElements() ->select(oclIsKindOf(uml::Package) or oclIsKindOf(uml::Class) or oclIsKindOf(uml::DataType) or oclIsKindOf(uml::Property) or oclIsKindOf(uml::Association) or oclIsKindOf(uml::Operation)or oclIsKindOf(uml::Enumeration) or oclIsKindOf(uml::EnumerationLiteral)) ->forAll(name->notEmpty()) It would be great if the xmi:id attribute in the serialization would be canonically derived from the name and/or the qualified name of the element in the cases mentioned above. -- Nicolas. Kenn Hussey wrote: Given that the files were produced under pressure at the last possible moment and received little to no review (as usual), it's not surprising that there were mistakes. I'd be happy to work with Pete to produce the corrected files. With any luck, it won't be long before we have tooling to automate the production of these files (and to reduce the possibility of errors like this)... Kenn -------------------------- Sent using BlackBerry ----- Original Message ----- From: Pete Rivett To: Nicolas Rouquette ; uml2-rtf@omg.org ; executableUMLFoundation@omg.org ; Conrad Bock ; Bran Selic ; Ed Seidewitz ; Stephen Mellor ; Kenn Hussey Cc: Andrew Watson Sent: Wed Aug 13 12:12:59 2008 Subject: RE: unalabelled association-owned memberEnd property names affect the name of an association Well-spotted Nicolas: though from your example fragments youÃ.¢ââ..‰â..¢re wrong to say that at 2.2 the ends are given a generic name Ã.¢ââ..‰â.¬Å. they are given a generic xmi:id and no name at all! Both the change of name and (to a lesser extent) xmi:id, without being mandated by an issue resolution are IMHO serious bugs. The xmi:id case is more controversial, since xmi:ids do not in general have to be stable. However, since they are frequently used for referencing the elements from outside the file (e.g. using XMI hrefs) then for standard metamodels I think we should keep them stable. In fact IÃ.¢ââ..‰â..¢d say that we should probably treat this as an urgent issue and produce a new XMI file ASAP. From the difference between the 2 fragments I spotted another discrepancy/bug in UML 2.2 Ã.¢ââ..‰â.¬Å. there is an incorrect owningAssociation attribute on the Property. This must not be serialized since itÃ.¢ââ..‰â..¢s the opposite of the composite owner of the Property (Association.ownedEnd) and so redundant. Clearly we should do more to perform diffs between the different versions of XMI files in order to catch inadvertent changes such as this. Pete From: Nicolas Rouquette [mailto:nicolas.rouquette@jpl.nasa.gov] Sent: 13 August 2008 19:15 To: uml2-rtf@omg.org ; executableUMLFoundation@omg.org ; Conrad Bock; Bran Selic; Ed Seidewitz; Stephen Mellor Subject: unalabelled association-owned memberEnd property names affect the name of an association I noticed strange differences between the XMI serialization of the UML superstructure in: UML 2.1.2, i.e: http://www.omg.org/spec/UML/20061001/Superstructure.cmof UML 2.2 beta1, i.e: http://www.omg.org/cgi-bin/doc?ptc/08-05-12 For example, in UML 2.1.2, we have: whereas in UML 2.2beta1, we have: In both cases, this association is described in Fig. 11.13 Object Actions (CompleteActions) in a way where the name of an association-owned memberEnd property isn't shown whereas the name of a class-owned memberEnd property is shown according to the conventions specified in clause 6.4.2 of the UML superstructure spec. http://www.omg.org/cgi-bin/doc?ptc/08-05-05 http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/ The problem here is that the unlabelled association-owned memberEnd properties have been given generic names such as ownedEnd.0 instead of the convention defined in clause 6.4.2 -- i.e., the name of the class with a lowercase initial. Is it OK for association names to change in this manner from one rev to another or is this a bug? Regardless of whether it is a bug or not w.r.t. current OMG specs, there is certainly a very undesirable consequence in name-level changes between revisions for a given concept when these revisions have not changed the semantics of that concept. Such incidental name-level changes create a lot of problems w.r.t. a stable notion of identity across revisions for detecting semantically-relevant changes from semantically irrelevant changes. -- Nicolas. CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Ã. CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -- Bran Selic Malina Software Corp. CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.