Issue 6191: UML 2 Super/Package Merge/redefinition rules and standard OO languages (uml2-superstructure-ftf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: There are cases where the same property goes from derived, to non-derived, and back to derived in different merged classes. Are there any constraints on subclasses redefining non-derived properties to be derived? If not, what would it mean for the subclass to inherit the non-derived property? Secton 5.3 says: "A derived property can redefine one which is not derived. An implementation must ensure that the constraints implied by the derivation are maintained if the property is updated." It doesn't mention the other way around. A redefinition hides the redefined model element. That is, if a subclass redefines a property, the inherited property is no longer visible. See section 5.3: "Note that a redefined attribute is not inherited into a namespace where it is redefined, so its name can be reused in the featuring classifier, either for the redefining attribute, or alternately for some other attribute." This does not conflict with the usual ability of OO languages which allow a subclass to specialize its superclasses and overrider methods, but still access the super class through keywords suchs as "super". Such keywords refer to the superclass namespace. However, Java does not allow a subclass to redefine a member variable unless it is private in the superclass. The same property in a superclass can't be private in contexts where it is redefined in some subclasses, and public in other subclasses where it is not redefined. Resolution: see above Revised Text: Actions taken: September 7, 2003: received issue March 8, 2005: closed issue Discussion: The appropriate constraints and transformation rules for this case are now spelled out in the resolution to issue 6279. The result of merging a derived and a non-derived feature is always a derived feature, which deals with the case above. Similarly, the result of merging two matching features with different visibilities is always public visibility. However, although this solves the immediate problem of providing a way of dealing with this situation, the more general issue of dealing with redefinition in the case of OO languages that do not support it will not change, since redefinition is here to stay in UML. However, it can be easily disallowed when working with such languages by defining appropriate profiles. End of Annotations:===== To: issues@omg.org Subject: UML 2 Super/Package Merge/redefinition rules and standard OO languages conflict X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Branislav Selic Date: Sun, 7 Sep 2003 09:01:42 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 09/07/2003 09:01:43, Serialize complete at 09/07/2003 09:01:43 There are cases where the same property goes from derived, to non-derived, and back to derived in different merged classes. Are there any constraints on subclasses redefining non-derived properties to be derived? If not, what would it mean for the subclass to inherit the non-derived property? Secton 5.3 says: "A derived property can redefine one which is not derived. An implementation must ensure that the constraints implied by the derivation are maintained if the property is updated." It doesn't mention the other way around. A redefinition hides the redefined model element. That is, if a subclass redefines a property, the inherited property is no longer visible. See section 5.3: "Note that a redefined attribute is not inherited into a namespace where it is redefined, so its name can be reused in the featuring classifier, either for the redefining attribute, or alternately for some other attribute." This does not conflict with the usual ability of OO languages which allow a subclass to specialize its superclasses and overrider methods, but still access the super class through keywords suchs as "super". Such keywords refer to the superclass namespace. However, Java does not allow a subclass to redefine a member variable unless it is private in the superclass. The same property in a superclass can't be private in contexts where it is redefined in some subclasses, and public in other subclasses where it is not redefined. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 Subject: a proposal for packageMerge Date: Sun, 12 Oct 2003 14:57:15 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-topic: UML 2 FTF Borland's answers to the Business Committee Questionaire Thread-index: AcONnOvJuphReZe7SoOhxzMbikkv3wDUhXrw From: "Karl Frank" To: "Juergen Boldt" , , "Branislav Selic" X-OriginalArrivalTime: 12 Oct 2003 18:57:16.0469 (UTC) FILETIME=[A7971E50:01C390F2] A refinement of Borland's proposal, in the light of the last TeleCon, is attached. As someone famous said, famously, it is too long because I did not have time to make it shorter. I tried to attend to Ed S's reasonable demand that we consider what the purpose of this thing is, and to allow the good work of the IBM team to provide the programmatic details for defining the expansion operation. Regards, Karl PackageMergeProposal_kf.doc X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Birger Møller-Pedersen (AS/ETO) To: "'Karl Frank'" , Juergen Boldt , uml2-superstructure-ftf@omg.org, Branislav Selic Subject: RE: a proposal for packageMerge Date: Mon, 13 Oct 2003 08:33:55 +0200 X-Mailer: Internet Mail Service (5.5.2653.19) The sentence from the text: PackageMerge is a macro expression defined in terms of packageImport, generalization, and redefinition. is kind of strange. None of packageImport, generalization and redefinition is macro expression, so either there is some kind of confusion here, or the sentence should really say that the semantics of PackageMerge is defined by some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. /birger -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 12. oktober 2003 20:57 To: Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: a proposal for packageMerge A refinement of Borland's proposal, in the light of the last TeleCon, is attached. As someone famous said, famously, it is too long because I did not have time to make it shorter. I tried to attend to Ed S's reasonable demand that we consider what the purpose of this thing is, and to allow the good work of the IBM team to provide the programmatic details for defining the expansion operation. Regards, Karl X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Birger Møller-Pedersen (AS/ETO) To: "'Karl Frank'" , Juergen Boldt , uml2-superstructure-ftf@omg.org, Branislav Selic Subject: RE: a proposal for packageMerge Date: Mon, 13 Oct 2003 08:55:31 +0200 X-Mailer: Internet Mail Service (5.5.2653.19) ... another thing: has anybody looked into the differences/similarities between the new understanding of package merge and the existing package template mechanism? If I understand correctly, the new package merge is supposed to be a macro cocnept - and that is also the case with some of the elements of package templates: a new package is defined in terms of a number of existing packages. Generalizations and redefinitions are also used there. /birger -----Original Message----- From: Birger Møller-Pedersen (AS/ETO) Sent: 13. oktober 2003 08:34 To: 'Karl Frank'; Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: RE: a proposal for packageMerge The sentence from the text: PackageMerge is a macro expression defined in terms of packageImport, generalization, and redefinition. is kind of strange. None of packageImport, generalization and redefinition is macro expression, so either there is some kind of confusion here, or the sentence should really say that the semantics of PackageMerge is defined by some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. /birger -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 12. oktober 2003 20:57 To: Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: a proposal for packageMerge A refinement of Borland's proposal, in the light of the last TeleCon, is attached. As someone famous said, famously, it is too long because I did not have time to make it shorter. I tried to attend to Ed S's reasonable demand that we consider what the purpose of this thing is, and to allow the good work of the IBM team to provide the programmatic details for defining the expansion operation. Regards, Karl Date: Mon, 13 Oct 2003 10:35:48 +0100 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: "Birger Møller-Pedersen (AS/ETO)" CC: "'Karl Frank'" , Juergen Boldt , uml2-superstructure-ftf@omg.org, Branislav Selic Subject: Re: a proposal for packageMerge Birger, I think the intention is that the semantics of PackageMerge is defined by some macro expression which is defined in terms of the semantics of packageImport, generalization and redefinition. perhaps rather than > some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. Thx - Guus Birger Møller-Pedersen (AS/ETO) wrote: The sentence from the text: PackageMerge is a macro expression defined in terms of packageImport, generalization, and redefinition. is kind of strange. None of packageImport, generalization and redefinition is macro expression, so either there is some kind of confusion here, or the sentence should really say that the semantics of PackageMerge is defined by some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. /birger -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 12. oktober 2003 20:57 To: Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: a proposal for packageMerge A refinement of Borland's proposal, in the light of the last TeleCon, is attached. As someone famous said, famously, it is too long because I did not have time to make it shorter. I tried to attend to Ed S's reasonable demand that we consider what the purpose of this thing is, and to allow the good work of the IBM team to provide the programmatic details for defining the expansion operation. Regards, Karl -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Subject: RE: a proposal for packageMerge Date: Mon, 13 Oct 2003 08:45:04 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: a proposal for packageMerge Thread-index: AcORVLTFL+VSTfupT6Cz9eTP6gRtnAAMtdxQ From: "Karl Frank" To: Birger Møller-Pedersen (AS/ETO) , "Juergen Boldt" , , "Branislav Selic" X-OriginalArrivalTime: 13 Oct 2003 12:45:05.0948 (UTC) FILETIME=[D3F9C5C0:01C39187] Guus' explanation/answer to this clarifies what was meant and I accept his restatement as a correction to my wording. - Karl -----Original Message----- From: Birger Møller-Pedersen (AS/ETO) [mailto:birger.moller-pedersen@ericsson.com] Sent: Monday, October 13, 2003 2:34 AM To: Karl Frank; Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: RE: a proposal for packageMerge The sentence from the text: PackageMerge is a macro expression defined in terms of packageImport, generalization, and redefinition. is kind of strange. None of packageImport, generalization and redefinition is macro expression, so either there is some kind of confusion here, or the sentence should really say that the semantics of PackageMerge is defined by some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. /birger -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 12. oktober 2003 20:57 To: Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: a proposal for packageMerge A refinement of Borland's proposal, in the light of the last TeleCon, is attached. As someone famous said, famously, it is too long because I did not have time to make it shorter. I tried to attend to Ed S's reasonable demand that we consider what the purpose of this thing is, and to allow the good work of the IBM team to provide the programmatic details for defining the expansion operation. Regards, Karl Subject: RE: PackageMerge Date: Mon, 13 Oct 2003 08:52:17 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: KF-Borland slides for FTF Telecon Thread-index: AcORYBB6t6FdabxiSNWt6hCZjuPBrAAKD3rQ From: "Karl Frank" To: "Juergen Boldt" , X-OriginalArrivalTime: 13 Oct 2003 12:52:20.0462 (UTC) FILETIME=[D6F758E0:01C39188] I am sending this email from Trygve into the list so we all have equal access to IS21C's handling of packageMerge. - Karl -----Original Message----- From: Trygve Reenskaug [mailto:trygver@ifi.uio.no] Sent: Monday, October 13, 2003 3:58 AM To: Karl Frank; Branislav Selic Cc: Jim Amsden; Kenneth Hussey; Barbara Price Subject: RE: KF-Borland slides for FTF Telecon Karl, I call my current project "IS21C - Information Systems for the 21st Century". I could have called it UML_3 because it is a merge of UML (defining the classes) and Smalltalk (where classes, packages and everything else is represented by objects). In IS21C, a Package is represented as an object. A message to this object could be "getClasses". It would return the set of Class objects contained in the package. A PackageMerge specification is recorded as state in the merging Package object. The "getClasses" method now dynamically computes the merged set of classes. A new method, "getOwnClasses", returns the original classes without merge. Both the merged and the merging Packages can now be edited at will. The "before" package exists as a normal package, the merged exists as the result of a computation. It is just your idea of a macro if this were a run-time function. IS21C is a research project because there are an unbelievable number of issues that cannot be resolved in a hurry. But it should not be harmful to define UML 2 such that it is possible to visualize the objects that realize it. Best regards --Trygve At 12.10.2003 22:18, Karl Frank wrote: Trygve, your comments, particularly #2) putting the method in the PostMergedConstructs object, helped me in thinking about this. So this is a thank you. I am copying Jim, Bran, Barbara and Ken, etc. because this note throws some light on the proposal I just made, a proposal weI want to be consolidated with the IBM proposal. Your comment number 1 was appreciated, as it was support for a position we apparently shared, but comment 2) was a new idea to me, and it changed the direction of my proposal. I had not thought about what object should be responsible for the expansion, and the more I thought about your suggestion the more I thought it was right.. The way I understood your suggestion 2), it is that the responsibility is given to the merging package, so that you accept the model including the packageMerge if and only if you have access to the packageMerge object and hence its expansion operation. So this is on the level of doing a good OO model of the problem, supporting the purpose of the packageMerge, namely to allow incremental expansion of a model, with an option to stop at a lower compliance point, by not accepting a merging package. The packageMerge object really is the merging package (the source of the arrow), and it can now tell about its contents in their postmerged form because it has that method. If you want to take the model as offered without the packageMerge, then you are left with a model that includes the merged package, but excludes the merging package, and since the expansion operation is implemented in a method of the merging package, not the merged, you don't have that method for macro expansion at your disposal. - Karl -----Original Message----- From: Trygve Reenskaug [mailto:trygver@ifi.uio.no] Sent: Sunday, October 05, 2003 3:13 PM To: Karl Frank; Branislav Selic; uml2-superstructure-ftf@omg.org; juergen@omg.org Cc: Jim Amsden; Kenneth Hussey; Barbara Price Subject: Re: KF-Borland slides for FTF Telecon I have two experiences and one observation supporting the definition of PackageMerge as an Operation: 1) I could not make sense of PackageMerge when drawing the complete class inheritance diagram for the static infrastructure. Making it an operation would resolve my troubles. 2) I could not make sense of PackageMerge as defined in the proposal when I implemented my first executing UML-VM. Defining PackageMerge as an operation would have solved the problem; PackageMerge could be a method in the PostMergedConstrucs object. 3) This is not the issue under consideration, but a similar operation would support the specialization of Collaborations (OOram synthesis). (Incidentally, this would solve the "Actors that are outside and inside the system" problem). Regards --Trygve At 05.10.2003 09:26, Karl Frank wrote: Attached is a revised slide set representing my views on the problem of PackageMerge. I apologize for having sent the first version in haste, and with certain defects, some of which may now be corrected (he hopes). The correct version is the one dated 051003 - Karl Frank Karl Frank Borland Software Corporation cell: 978 853 3592 landline: 978 283 4656 -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, October 03, 2003 6:49 PM To: uml2-superstructure-ftf@omg.org; juergen@omg.org Cc: Jim Amsden; Kenneth Hussey; Barbara Price Subject: Slides for Package Merge discussion during next FTF telecon Attached is a slide presentation that will be discussed during next week's UML 2 Super FTF telecon (along with Karl's paper on the same topic). As already stated, the current package merge mechanism has led to significant implementability and scalability issues. These are described in the attached presentation and a solution to these problems is also proposed. I have asked Jim Amsden and Kenn Hussey, who are leading development teams at IBM that are implementing some of this stuff, to participate in this discussion. As already noted, this is probably the most serious technical issue facing us, so please plan on participating in its resolution. I suggest that each of you carefully review the slides and come prepared on Wednesday with any questions and/or challenges. Jeurgen, I would appreciate if you could post this presentation (unzipped) on our FTF site -- thanks. Regards, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com -- Trygve Reenskaug mailto: trygver@ifi.uio.no Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver N-0378 Oslo Tel: (+47) 22 49 57 27 Norway -- Trygve Reenskaug mailto: trygver@ifi.uio.no Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver N-0378 Oslo Tel: (+47) 22 49 57 27 Norway Subject: RE: a proposal for packageMerge Date: Mon, 13 Oct 2003 09:29:35 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: a proposal for packageMerge Thread-index: AcORbYCanz/OCPWSRbKALmcRMDBNPQAH5iRg From: "Karl Frank" To: "Guus Ramackers" , "Birger Møller-Pedersen (AS/ETO)" Cc: "Juergen Boldt" , , "Branislav Selic" X-OriginalArrivalTime: 13 Oct 2003 13:29:36.0779 (UTC) FILETIME=[0BEA3DB0:01C3918E] In view of points implicit in Birger's and Guus' discussion, I propose removing the term "macro" from the definition. The RFP requires us to be using UML as the metalanguage to define UML, and UML does not have macros as modeling elements. What UML does have is behaviors and operations, so a rewording of the proposal using those terms would be welcome. I may not have the time to do so before the Wed telecon. - Karl -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: Monday, October 13, 2003 5:36 AM To: "Birger Møller-Pedersen (AS/ETO)" Cc: Karl Frank; Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: Re: a proposal for packageMerge Birger, I think the intention is that the semantics of PackageMerge is defined by some macro expression which is defined in terms of the semantics of packageImport, generalization and redefinition. perhaps rather than > some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. Thx - Guus Birger Møller-Pedersen (AS/ETO) wrote: The sentence from the text: PackageMerge is a macro expression defined in terms of packageImport, generalization, and redefinition. is kind of strange. None of packageImport, generalization and redefinition is macro expression, so either there is some kind of confusion here, or the sentence should really say that the semantics of PackageMerge is defined by some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. /birger -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 12. oktober 2003 20:57 To: Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: a proposal for packageMerge A refinement of Borland's proposal, in the light of the last TeleCon, is attached. As someone famous said, famously, it is too long because I did not have time to make it shorter. I tried to attend to Ed S's reasonable demand that we consider what the purpose of this thing is, and to allow the good work of the IBM team to provide the programmatic details for defining the expansion operation. Regards, Karl -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 To: Birger Møller-Pedersen (AS/ETO) Cc: "'Karl Frank'" , uml2-superstructure-ftf@omg.org Subject: RE: a proposal for packageMerge X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 13 Oct 2003 11:29:40 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 10/13/2003 11:29:44, Serialize complete at 10/13/2003 11:29:44 Yes, I did bring this up during the telecon briefly in reference to the 2U submission. However, we did not elaborate on this point, but I think that we should. If nothing else, we should be consistent in the way we deal with these obviously similar things. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com Birger Møller-Pedersen (AS/ETO) 10/13/2003 02:55 AM To: "'Karl Frank'" , Juergen Boldt , uml2-superstructure-ftf@omg.org, Branislav Selic/Ottawa/IBM@IBMCA cc: Subject: RE: a proposal for packageMerge ... another thing: has anybody looked into the differences/similarities between the new understanding of package merge and the existing package template mechanism? If I understand correctly, the new package merge is supposed to be a macro cocnept - and that is also the case with some of the elements of package templates: a new package is defined in terms of a number of existing packages. Generalizations and redefinitions are also used there. /birger -----Original Message----- From: Birger Møller-Pedersen (AS/ETO) Sent: 13. oktober 2003 08:34 To: 'Karl Frank'; Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: RE: a proposal for packageMerge The sentence from the text: PackageMerge is a macro expression defined in terms of packageImport, generalization, and redefinition. is kind of strange. None of packageImport, generalization and redefinition is macro expression, so either there is some kind of confusion here, or the sentence should really say that the semantics of PackageMerge is defined by some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. /birger -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 12. oktober 2003 20:57 To: Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: a proposal for packageMerge A refinement of Borland's proposal, in the light of the last TeleCon, is attached. As someone famous said, famously, it is too long because I did not have time to make it shorter. I tried to attend to Ed S's reasonable demand that we consider what the purpose of this thing is, and to allow the good work of the IBM team to provide the programmatic details for defining the expansion operation. Regards, Karl From: "Moore, Alan" To: "'Karl Frank'" , Guus Ramackers , "Birger Møller-Peders en (AS/ETO)" Cc: Juergen Boldt , uml2-superstructure-ftf@omg.org, Branislav Selic Subject: RE: a proposal for packageMerge Date: Tue, 14 Oct 2003 12:41:40 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Hi Karl, I'm a bit confused by your assertion that UML be the metalanguage to define UML - I thought that we were using CMOF to define UML, at least the XMI file seems to think that all of the UML metaelements are typed by CMOF elements. Have I got the wrong end of the stick here? Alan. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 13 October 2003 14:30 To: Guus Ramackers; "Birger Møller-Pedersen (AS/ETO)" Cc: Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: RE: a proposal for packageMerge In view of points implicit in Birger's and Guus' discussion, I propose removing the term "macro" from the definition. The RFP requires us to be using UML as the metalanguage to define UML, and UML does not have macros as modeling elements. What UML does have is behaviors and operations, so a rewording of the proposal using those terms would be welcome. I may not have the time to do so before the Wed telecon. - Karl -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: Monday, October 13, 2003 5:36 AM To: "Birger Møller-Pedersen (AS/ETO)" Cc: Karl Frank; Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: Re: a proposal for packageMerge Birger, I think the intention is that the semantics of PackageMerge is defined by some macro expression which is defined in terms of the semantics of packageImport, generalization and redefinition. perhaps rather than > some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. Thx - Guus Birger Møller-Pedersen (AS/ETO) wrote: The sentence from the text: PackageMerge is a macro expression defined in terms of packageImport, generalization, and redefinition. is kind of strange. None of packageImport, generalization and redefinition is macro expression, so either there is some kind of confusion here, or the sentence should really say that the semantics of PackageMerge is defined by some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. /birger -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 12. oktober 2003 20:57 To: Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: a proposal for packageMerge A refinement of Borland's proposal, in the light of the last TeleCon, is attached. As someone famous said, famously, it is too long because I did not have time to make it shorter. I tried to attend to Ed S's reasonable demand that we consider what the purpose of this thing is, and to allow the good work of the IBM team to provide the programmatic details for defining the expansion operation. Regards, Karl -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Subject: RE: PackageMerge Date: Mon, 13 Oct 2003 08:52:17 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: KF-Borland slides for FTF Telecon Thread-index: AcORYBB6t6FdabxiSNWt6hCZjuPBrAAKD3rQ From: "Karl Frank" To: "Juergen Boldt" , X-OriginalArrivalTime: 13 Oct 2003 12:52:20.0462 (UTC) FILETIME=[D6F758E0:01C39188] I am sending this email from Trygve into the list so we all have equal access to IS21C's handling of packageMerge. - Karl -----Original Message----- From: Trygve Reenskaug [mailto:trygver@ifi.uio.no] Sent: Monday, October 13, 2003 3:58 AM To: Karl Frank; Branislav Selic Cc: Jim Amsden; Kenneth Hussey; Barbara Price Subject: RE: KF-Borland slides for FTF Telecon Karl, I call my current project "IS21C - Information Systems for the 21st Century". I could have called it UML_3 because it is a merge of UML (defining the classes) and Smalltalk (where classes, packages and everything else is represented by objects). In IS21C, a Package is represented as an object. A message to this object could be "getClasses". It would return the set of Class objects contained in the package. A PackageMerge specification is recorded as state in the merging Package object. The "getClasses" method now dynamically computes the merged set of classes. A new method, "getOwnClasses", returns the original classes without merge. Both the merged and the merging Packages can now be edited at will. The "before" package exists as a normal package, the merged exists as the result of a computation. It is just your idea of a macro if this were a run-time function. IS21C is a research project because there are an unbelievable number of issues that cannot be resolved in a hurry. But it should not be harmful to define UML 2 such that it is possible to visualize the objects that realize it. Best regards --Trygve At 12.10.2003 22:18, Karl Frank wrote: Trygve, your comments, particularly #2) putting the method in the PostMergedConstructs object, helped me in thinking about this. So this is a thank you. I am copying Jim, Bran, Barbara and Ken, etc. because this note throws some light on the proposal I just made, a proposal weI want to be consolidated with the IBM proposal. Your comment number 1 was appreciated, as it was support for a position we apparently shared, but comment 2) was a new idea to me, and it changed the direction of my proposal. I had not thought about what object should be responsible for the expansion, and the more I thought about your suggestion the more I thought it was right.. The way I understood your suggestion 2), it is that the responsibility is given to the merging package, so that you accept the model including the packageMerge if and only if you have access to the packageMerge object and hence its expansion operation. So this is on the level of doing a good OO model of the problem, supporting the purpose of the packageMerge, namely to allow incremental expansion of a model, with an option to stop at a lower compliance point, by not accepting a merging package. The packageMerge object really is the merging package (the source of the arrow), and it can now tell about its contents in their postmerged form because it has that method. If you want to take the model as offered without the packageMerge, then you are left with a model that includes the merged package, but excludes the merging package, and since the expansion operation is implemented in a method of the merging package, not the merged, you don't have that method for macro expansion at your disposal. - Karl -----Original Message----- From: Trygve Reenskaug [mailto:trygver@ifi.uio.no] Sent: Sunday, October 05, 2003 3:13 PM To: Karl Frank; Branislav Selic; uml2-superstructure-ftf@omg.org; juergen@omg.org Cc: Jim Amsden; Kenneth Hussey; Barbara Price Subject: Re: KF-Borland slides for FTF Telecon I have two experiences and one observation supporting the definition of PackageMerge as an Operation: 1) I could not make sense of PackageMerge when drawing the complete class inheritance diagram for the static infrastructure. Making it an operation would resolve my troubles. 2) I could not make sense of PackageMerge as defined in the proposal when I implemented my first executing UML-VM. Defining PackageMerge as an operation would have solved the problem; PackageMerge could be a method in the PostMergedConstrucs object. 3) This is not the issue under consideration, but a similar operation would support the specialization of Collaborations (OOram synthesis). (Incidentally, this would solve the "Actors that are outside and inside the system" problem). Regards --Trygve At 05.10.2003 09:26, Karl Frank wrote: Attached is a revised slide set representing my views on the problem of PackageMerge. I apologize for having sent the first version in haste, and with certain defects, some of which may now be corrected (he hopes). The correct version is the one dated 051003 - Karl Frank Karl Frank Borland Software Corporation cell: 978 853 3592 landline: 978 283 4656 -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, October 03, 2003 6:49 PM To: uml2-superstructure-ftf@omg.org; juergen@omg.org Cc: Jim Amsden; Kenneth Hussey; Barbara Price Subject: Slides for Package Merge discussion during next FTF telecon Attached is a slide presentation that will be discussed during next week's UML 2 Super FTF telecon (along with Karl's paper on the same topic). As already stated, the current package merge mechanism has led to significant implementability and scalability issues. These are described in the attached presentation and a solution to these problems is also proposed. I have asked Jim Amsden and Kenn Hussey, who are leading development teams at IBM that are implementing some of this stuff, to participate in this discussion. As already noted, this is probably the most serious technical issue facing us, so please plan on participating in its resolution. I suggest that each of you carefully review the slides and come prepared on Wednesday with any questions and/or challenges. Jeurgen, I would appreciate if you could post this presentation (unzipped) on our FTF site -- thanks. Regards, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com -- Trygve Reenskaug mailto: trygver@ifi.uio.no Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver N-0378 Oslo Tel: (+47) 22 49 57 27 Norway -- Trygve Reenskaug mailto: trygver@ifi.uio.no Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver N-0378 Oslo Tel: (+47) 22 49 57 27 Norway Date: Wed, 15 Oct 2003 13:04:03 +0100 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: Karl Frank CC: uml2 ftf Subject: Re: a proposal for packageMerge Karl, Regarding defining the "operation" of package merge (previously discussed as "macro expansion") in terms of the semantics of packageImport, generalization and redefinition, I would like to propose a friendly amendment based on the telecon discussion last week. "Although defined as an operation, package merge can be visualized structurally by using Dependency arrows, labeled with the stereotype <>. This provides a notation for the modeler that provides an overview of which packages are merged (i.e. input to the package merge operation)." [I do not have a concrete formulation, but can help with formulating one based on the updated proposal when available.] NB There was some discussion on the direction of teh Dependency - I do not have strong views, but it needs to be confirmed and added to the text above. Thanks, Guus Karl Frank wrote: In view of points implicit in Birger's and Guus' discussion, I propose removing the term "macro" from the definition. The RFP requires us to be using UML as the metalanguage to define UML, and UML does not have macros as modeling elements. What UML does have is behaviors and operations, so a rewording of the proposal using those terms would be welcome. I may not have the time to do so before the Wed telecon. - Karl -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: Monday, October 13, 2003 5:36 AM To: "Birger Møller-Pedersen (AS/ETO)" Cc: Karl Frank; Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: Re: a proposal for packageMerge Birger, I think the intention is that the semantics of PackageMerge is defined by some macro expression which is defined in terms of the semantics of packageImport, generalization and redefinition. perhaps rather than > some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. Thx - Guus Birger Møller-Pedersen (AS/ETO) wrote: The sentence from the text: PackageMerge is a macro expression defined in terms of packageImport, generalization, and redefinition. is kind of strange. None of packageImport, generalization and redefinition is macro expression, so either there is some kind of confusion here, or the sentence should really say that the semantics of PackageMerge is defined by some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. /birger -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 12. oktober 2003 20:57 To: Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: a proposal for packageMerge A refinement of Borland's proposal, in the light of the last TeleCon, is attached. As someone famous said, famously, it is too long because I did not have time to make it shorter. I tried to attend to Ed S's reasonable demand that we consider what the purpose of this thing is, and to allow the good work of the IBM team to provide the programmatic details for defining the expansion operation. Regards, Karl -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Reply-To: Joaquin Miller X-Sender: miller@joaquin.net@secure.cnchost.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 Oct 2003 06:51:20 -0700 To: uml2-superstructure-ftf@omg.org, From: Joaquin Miller Subject: ,gi, issue no-number -- Package Merge--two naming problems The proposed change in package merge has two naming problems that should be cleanly solved before consideration of adoption: 1. The proposal to call the several (64 trillion or fewer) different resulting languages 'versions.' There is a serious clash with the conventional OMG usage of 'version.' That word should be reserved for versions of UML produced by RTFs or an RFP adoption process. Sadly, the standard term, 'profile,' was given a different meaning by UML 1. This problem can be fixed by using a different word. Inspiration or perspiration should do the job. 2. The proposal to always merge into a top package. This has the unintended result of removing the ability to use the standard naming mechanism to distinguish the different metamodel classes with unqualified names that are the same. I hope this problem can be fixed, but i don't see how. Reply-To: Joaquin Miller X-Sender: miller@joaquin.net@secure.cnchost.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 Oct 2003 06:56:18 -0700 To: uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org From: Joaquin Miller Subject: ,gi, issue no-number -- Re: a proposal for packageMerge Thanks, Guus. Let's call this 'transformation,' instead of 'operation.' A transformation is an operation, but 'transformation' is more specific, and it fits with MOF QVT and the MDA Guide. And does not clash with UML 'operation.' Cordially, Joaquin Guus wrote: Karl, Regarding defining the "operation" of package merge (previously discussed as "macro expansion") in terms of the semantics of packageImport, generalization and redefinition, I would like to propose a friendly amendment based on the telecon discussion last week. "Although defined as an operation, package merge can be visualized structurally by using Dependency arrows, labeled with the stereotype <>. This provides a notation for the modeler that provides an overview of which packages are merged (i.e. input to the package merge operation)." [I do not have a concrete formulation, but can help with formulating one based on the updated proposal when available.] NB There was some discussion on the direction of teh Dependency - I do not have strong views, but it needs to be confirmed and added to the text above. Thanks, Guus Karl Frank wrote: In view of points implicit in Birger's and Guus' discussion, I propose removing the term "macro" from the definition. The RFP requires us to be using UML as the metalanguage to define UML, and UML does not have macros as modeling elements. What UML does have is behaviors and operations, so a rewording of the proposal using those terms would be welcome. I may not have the time to do so before the Wed telecon. - Karl -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: Monday, October 13, 2003 5:36 AM To: "Birger Møller-Pedersen (AS/ETO)" Cc: Karl Frank; Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: Re: a proposal for packageMerge Birger, I think the intention is that the semantics of PackageMerge is defined by some macro expression which is defined in terms of the semantics of packageImport, generalization and redefinition. perhaps rather than > some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. Thx - Guus Birger Møller-Pedersen (AS/ETO) wrote: The sentence from the text: PackageMerge is a macro expression defined in terms of packageImport, generalization, and redefinition. is kind of strange. None of packageImport, generalization and redefinition is macro expression, so either there is some kind of confusion here, or the sentence should really say that the semantics of PackageMerge is defined by some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. /birger -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 12. oktober 2003 20:57 To: Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: a proposal for packageMerge A refinement of Borland's proposal, in the light of the last TeleCon, is attached. As someone famous said, famously, it is too long because I did not have time to make it shorter. I tried to attend to Ed S's reasonable demand that we consider what the purpose of this thing is, and to allow the good work of the IBM team to provide the programmatic details for defining the expansion operation. Regards, Karl -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Reply-To: Joaquin Miller X-Sender: miller@joaquin.net@secure.cnchost.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 Oct 2003 10:41:11 -0700 To: UML FTF , MOF-UML FTF From: Joaquin Miller Subject: ,gi, issues 6191 et al.--Package Merge--two naming problems Ed, i don't think this helps IBM nor, from what they say, any Java programmers. Their goal is to have all languages use the same names for the equivalent meta-model classes. Other than that, i agree with everything you write. (Though i am as wary as the next person of major restructuring at this time.) There is no fundamental problem here. This dilemma is the result of conflating the concept, packaging mechanism, with the concept, name space. If name space were independent of Package, instead of conflated into it, then we would have available different name spaces in different naming contexts and the problem would disappear. http://www.joaquin.net/ODP/Part2/12.html [3C UML had the same problem; we did not recognize the trouble IBM has pointed out. "6.1 Package: UML 2 uses the MOF 2 packaging specification. That is, a UML 2 package is a MOF package."] > 2. The proposal to always merge into a top package. This has the > unintended result of removing the ability to use the standard > naming mechanism to distinguish the different metamodel classes > with unqualified names that are the same. > > I hope this problem can be fixed, but i don't see how. One way to fix this would be to explicitly name the result of the "merge" transformation. That is, rather than identifying a merge transformation by a dependency between fragment A and base B with the "merged" package also being called B (or is it A?), we should have an explicit package C which merges the fragment A into the base B, so we get a new namespace. Karl's first presentation had a diagram that as much as showed this (though I don't think Karl was necessarily proposing this as an actual notation, and neither am I). In some ways, this is closer to how package merge is used in the current spec, with a number of packages merged together into a new namespace. However, the semantics of the result C, as I am suggesting it, would be in terms of the transformational conception of merge that Karl describes, not the specialization-based approach in the current spec. Also, in the current spec, the package being "merged into" includes a model fragment that provides the skeleton for the merge, while I would suggest that the result C should be entirely the result of the transformation. This approach is basically a structured "mix in" approach. We would have a hierarchy of base packages that are related by normal dependencies. Then we would have a separate set of "mix in" packages (which should have minimal or no dependencies on each other) that could be combined with base packages using package merge. I would, lastly, suggest that the packages resulting from the merges could be the basis for a reasonable number of explicit compliance points. -- Ed Date: Wed, 15 Oct 2003 18:56:18 +0100 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: Joaquin Miller CC: uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org Subject: Re: ,gi, issue no-number -- Re: a proposal for packageMerge Joaquin, Agreed. Guus Joaquin Miller wrote: Thanks, Guus. Let's call this 'transformation,' instead of 'operation.' A transformation is an operation, but 'transformation' is more specific, and it fits with MOF QVT and the MDA Guide. And does not clash with UML 'operation.' Cordially, Joaquin Guus wrote: Karl, Regarding defining the "operation" of package merge (previously discussed as "macro expansion") in terms of the semantics of packageImport, generalization and redefinition, I would like to propose a friendly amendment based on the telecon discussion last week. "Although defined as an operation, package merge can be visualized structurally by using Dependency arrows, labeled with the stereotype <>. This provides a notation for the modeler that provides an overview of which packages are merged (i.e. input to the package merge operation)." [I do not have a concrete formulation, but can help with formulating one based on the updated proposal when available.] NB There was some discussion on the direction of teh Dependency - I do not have strong views, but it needs to be confirmed and added to the text above. Thanks, Guus Karl Frank wrote: In view of points implicit in Birger's and Guus' discussion, I propose removing the term "macro" from the definition. The RFP requires us to be using UML as the metalanguage to define UML, and UML does not have macros as modeling elements. What UML does have is behaviors and operations, so a rewording of the proposal using those terms would be welcome. I may not have the time to do so before the Wed telecon. - Karl -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: Monday, October 13, 2003 5:36 AM To: "Birger Møller-Pedersen (AS/ETO)" Cc: Karl Frank; Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: Re: a proposal for packageMerge Birger, I think the intention is that the semantics of PackageMerge is defined by some macro expression which is defined in terms of the semantics of packageImport, generalization and redefinition. perhaps rather than > some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. Thx - Guus Birger Møller-Pedersen (AS/ETO) wrote: The sentence from the text: PackageMerge is a macro expression defined in terms of packageImport, generalization, and redefinition. is kind of strange. None of packageImport, generalization and redefinition is macro expression, so either there is some kind of confusion here, or the sentence should really say that the semantics of PackageMerge is defined by some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. /birger -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 12. oktober 2003 20:57 To: Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: a proposal for packageMerge A refinement of Borland's proposal, in the light of the last TeleCon, is attached. As someone famous said, famously, it is too long because I did not have time to make it shorter. I tried to attend to Ed S's reasonable demand that we consider what the purpose of this thing is, and to allow the good work of the IBM team to provide the programmatic details for defining the expansion operation. Regards, Karl -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 From: Edwin Seidewitz To: UML FTF , MOF-UML FTF Subject: RE: ,gi, issues 6191 et al.--Package Merge--two naming problems Date: Wed, 15 Oct 2003 14:23:27 -0400 X-Mailer: Internet Mail Service (5.5.2655.55) Joaquin -- Ed, i don't think this helps IBM nor, from what they say, any Java programmers. Their goal is to have all languages use the same names for the equivalent meta-model classes. I agree that the IBM proposal called for corresponding metaclasses in different "varieties" of UML to have the same names, including the same namespace. This was a part of their proposal to which I objected. Indeed, I am still not sure how it would work, since there were a number of issues in my original e-mail commenting on the proposal that have not been answered yet. For example, if you have a "basic" client that reads in an "extended" language XMI file, what does it do with the extra XML elements that it does not understand? Simply ignore them? And what happens when the "basic" client writes out XML encoding only the "basic" language features? It would seem that this could not be read by an extended client, since it would be missing expected elements, but it seems strange that a "basic" client should be able to read a file from an "extended" client, but not vice versa -- to my mind, one would expect that the extended client that is compliant with the "larger" language should be able to read a model in the "subset" language understood by the basic client, but one would be much less surprised to find that the basic client could not understand the "larger" language of the extended client. I would also like to note that this whole programming discussion seems awfully XML-oriented. I would think that the way to program UML tools would be to treat XMI as an internal representation that is parsed and then loaded into an internal object representation in the tool along the lines of the abstract syntax. I wouldn't think that the tool should be doing a lot of traversing of the XML parse tree once this is done. So, it again seems to me, the question should really be how well one can load the XMI file for an "extended" variety of UML into the abstract syntax representation for a more "basic" variety as would be used internally in a tool. This sort of mapping between varieties should be clearly given in the spec and, indeed, might be simply naturally understood as a consequence of the way merging is done. -- Ed Reply-To: Joaquin Miller X-Sender: joaquin%joaquin.net@secure.cnchost.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 Oct 2003 12:19:23 -0700 To: Juergen Boldt From: Joaquin Miller Subject: Re: ,gi, issue no-number -- Package Merge--two naming problems X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h9FJFfQR028170 Sorry. Part of the discussion. I just did not find the number in time. This is 6191. At 08:01 AM 10/15/2003, you wrote: Joaquin, should I log this one as an issue...or is this part of the 6191 discussion? -Juergen At 06:51 AM 10/15/03 -0700, you wrote: The proposed change in package merge has two naming problems that should be cleanly solved before consideration of adoption: 1. The proposal to call the several (64 trillion or fewer) different resulting languages 'versions.' There is a serious clash with the conventional OMG usage of 'version.' That word should be reserved for versions of UML produced by RTFs or an RFP adoption process. Sadly, the standard term, 'profile,' was given a different meaning by UML 1. This problem can be fixed by using a different word. Inspiration or perspiration should do the job. 2. The proposal to always merge into a top package. This has the unintended result of removing the ability to use the standard naming mechanism to distinguish the different metamodel classes with unqualified names that are the same. I hope this problem can be fixed, but i don't see how. ================================= Jürgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org ================================ PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Reply-To: Joaquin Miller X-Sender: miller@joaquin.net@secure.cnchost.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 Oct 2003 13:13:39 -0700 To: UML FTF , MOF-UML FTF From: Joaquin Miller Subject: RE: ,gi, issues 6191 et al.--Package Merge--two naming problems Thanks, Ed. This furthers the discussion. Perhaps IBM will provide some examples of what, with something along the lines of their initial proposal, models look like before and after interchange. (b>e, e>b, e>b>e, b>e>b (b=smaller language, e=larger language)) Edwin Seidewitz wrote: Joaquin -- Ed, i don't think this helps IBM nor, from what they say, any Java programmers. Their goal is to have all languages use the same names for the equivalent meta-model classes. I agree that the IBM proposal called for corresponding metaclasses in different "varieties" of UML to have the same names, including the same namespace. This was a part of their proposal to which I objected. Indeed, I am still not sure how it would work, since there were a number of issues in my original e-mail commenting on the proposal that have not been answered yet. For example, if you have a "basic" client that reads in an "extended" language XMI file, what does it do with the extra XML elements that it does not understand? Simply ignore them? And what happens when the "basic" client writes out XML encoding only the "basic" language features? It would seem that this could not be read by an extended client, since it would be missing expected elements, but it seems strange that a "basic" client should be able to read a file from an "extended" client, but not vice versa -- to my mind, one would expect that the extended client that is compliant with the "larger" language should be able to read a model in the "subset" language understood by the basic client, but one would be much less surprised to find that the basic client could not understand the "larger" language of the extended client. I would also like to note that this whole programming discussion seems awfully XML-oriented. I would think that the way to program UML tools would be to treat XMI as an internal representation that is parsed and then loaded into an internal object representation in the tool along the lines of the abstract syntax. I wouldn't think that the tool should be doing a lot of traversing of the XML parse tree once this is done. So, it again seems to me, the question should really be how well one can load the XMI file for an "extended" variety of UML into the abstract syntax representation for a more "basic" variety as would be used internally in a tool. This sort of mapping between varieties should be clearly given in the spec and, indeed, might be simply naturally understood as a consequence of the way merging is done. -- Ed Reply-To: Joaquin Miller X-Sender: miller@joaquin.net@secure.cnchost.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 Oct 2003 13:13:54 -0700 To: UML FTF , MOF-UML FTF From: Joaquin Miller Subject: RE: ,gi, issues 6191 et al.--Package Merge--two naming problems Ed, i may be missing something. But i don't see any way to fix the problem that IBM has encountered, except (at least in a Java program using the IBM run-time mini-mof) to use the same fully qualified name for all those classes in the many UML metamodels having the same base name. If there is no other way out of the problem encountered, i support doing that. It does not necessarily mean that this name must be the same fully qualified name used for one of those classes, as found in a particular one of those metamodels. (Nor the same fully qualified name used for that class in an XMI file.) There might be a way out in that direction. But, no one has yet proposed a solution using different names. Instead the proposal on the table is to change the fully qualified name of classes in the UML metamodel. (Giving several different classes the same fully qualified name.) I'm glad you raise objections, because it helps to lead toward a satisfactory solution. Joaquin -- Ed, i don't think this helps IBM nor, from what they say, any Java programmers. Their goal is to have all languages use the same names for the equivalent meta-model classes. I agree that the IBM proposal called for corresponding metaclasses in different "varieties" of UML to have the same names, including the same namespace. This was a part of their proposal to which I objected. Indeed, I am still not sure how it would work, since there were a number of issues in my original e-mail commenting on the proposal that have not been answered yet. For example, if you have a "basic" client that reads in an "extended" language XMI file, what does it do with the extra XML elements that it does not understand? Simply ignore them? And what happens when the "basic" client writes out XML encoding only the "basic" language features? It would seem that this could not be read by an extended client, since it would be missing expected elements, but it seems strange that a "basic" client should be able to read a file from an "extended" client, but not vice versa -- to my mind, one would expect that the extended client that is compliant with the "larger" language should be able to read a model in the "subset" language understood by the basic client, but one would be much less surprised to find that the basic client could not understand the "larger" language of the extended client. I would also like to note that this whole programming discussion seems awfully XML-oriented. I would think that the way to program UML tools would be to treat XMI as an internal representation that is parsed and then loaded into an internal object representation in the tool along the lines of the abstract syntax. I wouldn't think that the tool should be doing a lot of traversing of the XML parse tree once this is done. So, it again seems to me, the question should really be how well one can load the XMI file for an "extended" variety of UML into the abstract syntax representation for a more "basic" variety as would be used internally in a tool. This sort of mapping between varieties should be clearly given in the spec and, indeed, might be simply naturally understood as a consequence of the way merging is done. -- Ed From: Edwin Seidewitz To: Edwin Seidewitz , UML FTF , MOF-UML FTF Subject: RE: ,gi, issues 6191 et al.--Package Merge--two naming problems Date: Wed, 15 Oct 2003 17:07:11 -0400 X-Mailer: Internet Mail Service (5.5.2655.55) By the way, I noticed an error in my message, as noted below. -----Original Message----- From: Edwin Seidewitz [mailto:eseidewitz@intelidata.com] Sent: Wednesday, October 15, 2003 2:23 PM To: UML FTF; MOF-UML FTF Subject: RE: ,gi, issues 6191 et al.--Package Merge--two naming problems Joaquin -- Ed, i don't think this helps IBM nor, from what they say, any Java programmers. Their goal is to have all languages use the same names for the equivalent meta-model classes. ... I would also like to note that this whole programming discussion seems awfully XML-oriented. I would think that the way to program UML tools would be to treat XMI as an internal representation that is parsed and then loaded into an internal That should be "...treat XMI as an external representation...". object representation in the tool along the lines of the abstract syntax. I wouldn't think that the tool should be doing a lot of traversing of the XML parse tree once this is done. So, it again seems to me, the question should really be how well one can load the XMI file for an "extended" variety of UML into the abstract syntax representation for a more "basic" variety as would be used internally in a tool. This sort of mapping between varieties should be clearly given in the spec and, indeed, might be simply naturally understood as a consequence of the way merging is done. -- Ed From: "Moore, Alan" To: "'Karl Frank'" , Birger Møll er-Pedersen (AS/ETO) , uml2-superstructure-ftf@omg.org, Branislav Selic Subject: RE: a proposal for packageMerge Date: Thu, 16 Oct 2003 13:32:56 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) In this scheme, what happens to those elements that cannot either be generalized or redefined, for example constraints? -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 13 October 2003 13:45 To: Birger Møller-Pedersen (AS/ETO); Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: RE: a proposal for packageMerge Guus' explanation/answer to this clarifies what was meant and I accept his restatement as a correction to my wording. - Karl -----Original Message----- From: Birger Møller-Pedersen (AS/ETO) [mailto:birger.moller-pedersen@ericsson.com] Sent: Monday, October 13, 2003 2:34 AM To: Karl Frank; Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: RE: a proposal for packageMerge The sentence from the text: PackageMerge is a macro expression defined in terms of packageImport, generalization, and redefinition. is kind of strange. None of packageImport, generalization and redefinition is macro expression, so either there is some kind of confusion here, or the sentence should really say that the semantics of PackageMerge is defined by some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. /birger -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 12. oktober 2003 20:57 To: Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: a proposal for packageMerge A refinement of Borland's proposal, in the light of the last TeleCon, is attached. As someone famous said, famously, it is too long because I did not have time to make it shorter. I tried to attend to Ed S's reasonable demand that we consider what the purpose of this thing is, and to allow the good work of the IBM team to provide the programmatic details for defining the expansion operation. Regards, Karl Date: Thu, 16 Oct 2003 14:51:31 +0100 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: "Moore, Alan" CC: "'Karl Frank'" , "Birger Mø ller-Pedersen (AS/ETO)" , uml2-superstructure-ftf@omg.org, Branislav Selic Subject: Re: a proposal for packageMerge Alan, I believe that is a different meta level. End users can't generalize constraints, but we can use generalization to explain how the different occurrences of constraint in the meta model are 'merged' to combine the definition of the metaclass Class, Interface, Constraint, Transition, etc. (i.e. "the semantics of package merge for these two occurrences x and y of the same meta class is equivalent to x being the subclass of y") For those classes in the spec where there is only a single definition, obviously no merge takes place. Thanks, Guus Moore, Alan wrote: In this scheme, what happens to those elements that cannot either be generalized or redefined, for example constraints? -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 13 October 2003 13:45 To: Birger Møller-Pedersen (AS/ETO); Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: RE: a proposal for packageMerge Guus' explanation/answer to this clarifies what was meant and I accept his restatement as a correction to my wording. - Karl -----Original Message----- From: Birger Møller-Pedersen (AS/ETO) [mailto:birger.moller-pedersen@ericsson.com] Sent: Monday, October 13, 2003 2:34 AM To: Karl Frank; Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: RE: a proposal for packageMerge The sentence from the text: PackageMerge is a macro expression defined in terms of packageImport, generalization, and redefinition. is kind of strange. None of packageImport, generalization and redefinition is macro expression, so either there is some kind of confusion here, or the sentence should really say that the semantics of PackageMerge is defined by some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. /birger -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 12. oktober 2003 20:57 To: Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: a proposal for packageMerge A refinement of Borland's proposal, in the light of the last TeleCon, is attached. As someone famous said, famously, it is too long because I did not have time to make it shorter. I tried to attend to Ed S's reasonable demand that we consider what the purpose of this thing is, and to allow the good work of the IBM team to provide the programmatic details for defining the expansion operation. Regards, Karl -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Date: Thu, 16 Oct 2003 16:13:27 +0100 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: Guus Ramackers CC: "Moore, Alan" , "'Karl Frank'" , "Birger Møller-Pedersen (AS/ETO)" , uml2-superstructure-ftf@omg.org, Branislav Selic Subject: Re: a proposal for packageMerge Alan, Thinking about this again, package merge is defined at the core level and applies to all elements in teh infrastructure (i.e. we're not talking about merging state machines which might be associated with classes). We don't have our OCL constraints in teh meta model at themoment, but formally they are there and hence subject to merge rules. The infrastructure spec says about non-generalizable elements: A non-generalizable packageable element owned by the target package is copied down to the source package. Any classifiers referenced as part of the packageable element are redirected at transformed classifiers, if any. Thanks, Guus Guus Ramackers wrote: Alan, I believe that is a different meta level. End users can't generalize constraints, but we can use generalization to explain how the different occurrences of constraint in the meta model are 'merged' to combine the definition of the metaclass Class, Interface, Constraint, Transition, etc. (i.e. "the semantics of package merge for these two occurrences x and y of the same meta class is equivalent to x being the subclass of y") For those classes in the spec where there is only a single definition, obviously no merge takes place. Thanks, Guus Moore, Alan wrote: In this scheme, what happens to those elements that cannot either be generalized or redefined, for example constraints? -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 13 October 2003 13:45 To: Birger Møller-Pedersen (AS/ETO); Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: RE: a proposal for packageMerge Guus' explanation/answer to this clarifies what was meant and I accept his restatement as a correction to my wording. - Karl -----Original Message----- From: Birger Møller-Pedersen (AS/ETO) [mailto:birger.moller-pedersen@ericsson.com] Sent: Monday, October 13, 2003 2:34 AM To: Karl Frank; Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: RE: a proposal for packageMerge The sentence from the text: PackageMerge is a macro expression defined in terms of packageImport, generalization, and redefinition. is kind of strange. None of packageImport, generalization and redefinition is macro expression, so either there is some kind of confusion here, or the sentence should really say that the semantics of PackageMerge is defined by some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. /birger -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 12. oktober 2003 20:57 To: Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: a proposal for packageMerge A refinement of Borland's proposal, in the light of the last TeleCon, is attached. As someone famous said, famously, it is too long because I did not have time to make it shorter. I tried to attend to Ed S's reasonable demand that we consider what the purpose of this thing is, and to allow the good work of the IBM team to provide the programmatic details for defining the expansion operation. Regards, Karl -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 From: "Moore, Alan" To: "'Guus Ramackers'" Cc: "'Karl Frank'" , "Birger Mø ller-Pedersen (AS/ETO)" , uml2-superstructure-ftf@omg.org, Branislav Selic Subject: RE: a proposal for packageMerge Date: Fri, 17 Oct 2003 11:58:13 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Guus, Perhaps I'm being pedantic here, but two issues: firstly, constraints can reference elements other than classifier, for example Properties , so I assume that the redirection applies to all transformed elements; secondly, if there is already a constraint with the same name in the merge destination, does it just overwrite what is there? Alan. -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: 16 October 2003 16:13 To: Guus Ramackers Cc: Moore, Alan; 'Karl Frank'; "Birger Møller-Pedersen (AS/ETO)"; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: Re: a proposal for packageMerge Alan, Thinking about this again, package merge is defined at the core level and applies to all elements in teh infrastructure (i.e. we're not talking about merging state machines which might be associated with classes). We don't have our OCL constraints in teh meta model at themoment, but formally they are there and hence subject to merge rules. The infrastructure spec says about non-generalizable elements: A non-generalizable packageable element owned by the target package is copied down to the source package. Any classifiers referenced as part of the packageable element are redirected at transformed classifiers, if any. Thanks, Guus Guus Ramackers wrote: Alan, I believe that is a different meta level. End users can't generalize constraints, but we can use generalization to explain how the different occurrences of constraint in the meta model are 'merged' to combine the definition of the metaclass Class, Interface, Constraint, Transition, etc. (i.e. "the semantics of package merge for these two occurrences x and y of the same meta class is equivalent to x being the subclass of y") For those classes in the spec where there is only a single definition, obviously no merge takes place. Thanks, Guus Moore, Alan wrote: In this scheme, what happens to those elements that cannot either be generalized or redefined, for example constraints? -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 13 October 2003 13:45 To: Birger Møller-Pedersen (AS/ETO); Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: RE: a proposal for packageMerge Guus' explanation/answer to this clarifies what was meant and I accept his restatement as a correction to my wording. - Karl -----Original Message----- From: Birger Møller-Pedersen (AS/ETO) [mailto:birger.moller-pedersen@ericsson.com] Sent: Monday, October 13, 2003 2:34 AM To: Karl Frank; Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: RE: a proposal for packageMerge The sentence from the text: PackageMerge is a macro expression defined in terms of packageImport, generalization, and redefinition. is kind of strange. None of packageImport, generalization and redefinition is macro expression, so either there is some kind of confusion here, or the sentence should really say that the semantics of PackageMerge is defined by some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. /birger -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 12. oktober 2003 20:57 To: Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: a proposal for packageMerge A refinement of Borland's proposal, in the light of the last TeleCon, is attached. As someone famous said, famously, it is too long because I did not have time to make it shorter. I tried to attend to Ed S's reasonable demand that we consider what the purpose of this thing is, and to allow the good work of the IBM team to provide the programmatic details for defining the expansion operation. Regards, Karl -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 To: Joaquin Miller Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: ,gi, issue no-number -- Package Merge--two naming problems X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 17 Oct 2003 09:51:26 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 10/17/2003 09:51:28, Serialize complete at 10/17/2003 09:51:28 Joaquin, I'm a bit behind in following this discussion which seems to be moving forecfully ahead, so please forgive me for this possible regression. I do not understand what you mean by your second point. Specifically, I do not understand what you mean when you refer to "the standard naming mechanism to distinguish the different metamodel classes with unqualified names that are the same". Which "standard naming mechanism"? How can you distinguish two different things if their names that are the same AND the names are unqualified? If you mean that you can do so by the fact that they are in different packages, nothing in our proposal changes that. I'm confused. Can you please clarify, perhaps using an example? Sorry for being slow on the uptake. Thanks, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com Joaquin Miller 10/15/2003 09:51 AM Please respond to Joaquin Miller To: uml2-superstructure-ftf@omg.org, cc: Subject: ,gi, issue no-number -- Package Merge--two naming problems The proposed change in package merge has two naming problems that should be cleanly solved before consideration of adoption: 1. The proposal to call the several (64 trillion or fewer) different resulting languages 'versions.' There is a serious clash with the conventional OMG usage of 'version.' That word should be reserved for versions of UML produced by RTFs or an RFP adoption process. Sadly, the standard term, 'profile,' was given a different meaning by UML 1. This problem can be fixed by using a different word. Inspiration or perspiration should do the job. 2. The proposal to always merge into a top package. This has the unintended result of removing the ability to use the standard naming mechanism to distinguish the different metamodel classes with unqualified names that are the same. I hope this problem can be fixed, but i don't see how. Date: Thu, 16 Oct 2003 16:13:27 +0100 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: Guus Ramackers CC: "Moore, Alan" , "'Karl Frank'" , "Birger Møller-Pedersen (AS/ETO)" , uml2-superstructure-ftf@omg.org, Branislav Selic Subject: Re: a proposal for packageMerge Alan, Thinking about this again, package merge is defined at the core level and applies to all elements in teh infrastructure (i.e. we're not talking about merging state machines which might be associated with classes). We don't have our OCL constraints in teh meta model at themoment, but formally they are there and hence subject to merge rules. The infrastructure spec says about non-generalizable elements: A non-generalizable packageable element owned by the target package is copied down to the source package. Any classifiers referenced as part of the packageable element are redirected at transformed classifiers, if any. Thanks, Guus Guus Ramackers wrote: Alan, I believe that is a different meta level. End users can't generalize constraints, but we can use generalization to explain how the different occurrences of constraint in the meta model are 'merged' to combine the definition of the metaclass Class, Interface, Constraint, Transition, etc. (i.e. "the semantics of package merge for these two occurrences x and y of the same meta class is equivalent to x being the subclass of y") For those classes in the spec where there is only a single definition, obviously no merge takes place. Thanks, Guus Moore, Alan wrote: In this scheme, what happens to those elements that cannot either be generalized or redefined, for example constraints? -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 13 October 2003 13:45 To: Birger Møller-Pedersen (AS/ETO); Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: RE: a proposal for packageMerge Guus' explanation/answer to this clarifies what was meant and I accept his restatement as a correction to my wording. - Karl -----Original Message----- From: Birger Møller-Pedersen (AS/ETO) [mailto:birger.moller-pedersen@ericsson.com] Sent: Monday, October 13, 2003 2:34 AM To: Karl Frank; Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: RE: a proposal for packageMerge The sentence from the text: PackageMerge is a macro expression defined in terms of packageImport, generalization, and redefinition. is kind of strange. None of packageImport, generalization and redefinition is macro expression, so either there is some kind of confusion here, or the sentence should really say that the semantics of PackageMerge is defined by some macro expression _in addition_ to (but still using) packageImport, generalization and redefinition. /birger -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: 12. oktober 2003 20:57 To: Juergen Boldt; uml2-superstructure-ftf@omg.org; Branislav Selic Subject: a proposal for packageMerge A refinement of Borland's proposal, in the light of the last TeleCon, is attached. As someone famous said, famously, it is too long because I did not have time to make it shorter. I tried to attend to Ed S's reasonable demand that we consider what the purpose of this thing is, and to allow the good work of the IBM team to provide the programmatic details for defining the expansion operation. Regards, Karl -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 e-mail: bselic@ca.ibm.com Reply-To: Joaquin Miller X-Sender: joaquin%joaquin.net@secure.cnchost.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 17 Oct 2003 10:07:30 -0700 To: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org From: Joaquin Miller Subject: ,gi, issues 6191 et al.--Package Merge At 06:51 AM 10/17/2003, Branislav Selic wrote: I do not understand what you mean by your second point. Specifically, I do not understand what you mean when you refer to "the standard naming mechanism to distinguish the different metamodel classes with unqualified names that are the same". Which "standard naming mechanism"? Sorry for being too succinct. I should have written: "the standard qualification-by-catenated-package-names naming mechanism used in MOF to distinguish the different metamodel classes with unqualified names that are the same" How can you distinguish two different things if their names are the same AND the names are unqualified? That's easy. For humans, anyway. Very easy if the two can be seen at the same time. But what was i getting at? If you mean that you can do so by the fact that they are in different packages, For example. That's the case now, as long as those packages have different names. I can identify for you which of the several classes named, 'Class,' I mean, by giving the fully qualified name, for example, 'Kernal::Classes::Class.' Or, i can distinguish two different things if they bring with them specifications that make it clear they are different. I can distinguish two different things if they are different, or (even if they compare in every other way) if they have different names in a naming context in which every name is the name of only one thing. The following will not be a well-formed UML model, but illustrates my point: In the package, ForThisExample, i put a class with name, 'Class', a copy of Kernel::Classes::Class and another class with name, 'Class', a copy of (i'll probably get this name wrong) CommonBehaviors::BasicBehaviors::Class, i can distinguish the two classes, because the latter, "larger" class has an attribute, isActive, which the former, "smaller" class lacks. Even though they both have the same name, viz: 'ForThisExample::Class'. Of course, if i was a (say, Java) programmer, i would like to be able to distinguish them with less effort, for example by comparing names. nothing in our proposal changes that. I'm confused. No. The problem seems to be that i don't understand the proposal. I understood the proposal (slide 27 of packageMerge.031003.bvs.ppt (sorry, folks, i have not looked up the document number) to be: always have the result of the model merge transformation be in a package named 'org.omg.uml2'. If that is the proposal, and i understand it (probably not), then I, as the programmer mentioned earlier, would, when working with the smaller class would find it to have the name, 'org.omg.uml2::Class', and, when working with the larger class would find it to have the same name, 'org.omg.uml2::Class'. This is a great convenience for general purpose code to manipulate classes for which org.omg.uml2::Class is the metaclass. That is: I understood (an element of) the proposal to be providing a single namespace to be used by programmers developing tools to manipulate models, so that the same code would work with both the smaller Class and the larger Class, because both would be of the same reference type. I understood that everything would wind up -- in packages with the same name, org.omg.uml2, ( "Pick one root package that will be the leaf merging package޶Say org.omg.uml2") -- but in different packages with that name (when the slides were presented, these were called "versions (of the package)"). Now i feel that i don't understand the proposal. [can be ignored: It is too bad our craft is yet so primitive that we don't have a shared vocabulary, even for the most basic concepts. I can't use 'identifier' in this discussion, because some will take that to mean a name by which something can be identified (OED, Merriam-Webster, http://www.joaquin.net/ODP/Part2/12.html#12.2 ), while others will take it to mean the identifier of The Java Language Specification (3.8), which can not reliably be used to identify something.] The proposed change in package merge has two naming problems that should be cleanly solved before consideration of adoption: ... 2. The proposal to always merge into a top package. This has the unintended result of removing the ability to use the standard naming mechanism to distinguish the different metamodel classes with unqualified Subject: RE: Difference in Package Merge descriptions Date: Wed, 22 Oct 2003 15:50:03 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Difference in Package Merge descriptions Thread-index: AcOY0mQMkXHow3j7RTeqzpOTSS97/wAAgFew From: "Karl Frank" To: "Branislav Selic" , X-OriginalArrivalTime: 22 Oct 2003 19:50:04.0688 (UTC) FILETIME=[B0207900:01C398D5] Bran is right. I was wrong when I said on the call that the texts of super and infra differed in their wording wrt packageMerge - Karl Superstructure, printed page 101: 7.13.2 PackageMerge (from Kernel) A package merge defines how one package extends another package by merging their contents. Infrastructure, printed page 105 11.8.3 PackageMerge A package merge defines how one package extends another package by merging their contents. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, October 22, 2003 3:25 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Difference in Package Merge descriptions I set out to raise the issue about the difference in the definition of PackageMerge in the Super and Infra specs. However, when I checked the text, I could not detect any differences other than figure numbers. Specifically, I checked the Superstructure FAS (starting on pg. 101) and the Infrastructure FAS (pg. 156). Am I looking in the wrong place? Thanks, Bran Date: Fri, 24 Oct 2003 10:52:48 -0400 From: "Manfred R. Koethe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: ,gi, issues 6191 et al.: More thoughts on Package Merge What we are discussing as "PackageMerge" is actually a "NamespaceMerge". (the IBM slides and comments from Joaquin, Ed, and others touched on this already). One difficulty of the current approach, as pointed out by Joaquin, is how to distinguish classifiers in a given package if they are "pre-merge" or "post-merge". (meaning if we dealing with the "pre-merge" or "post-merge" variant of a package. Both packages share the same name, resulting in the same namespace and qualified names for the enclosed classifiers. A solution would be the separation of packaging and namespace. That means a package could contain a namespace different from the package name. To preserve backward compatibility, the default would be the status quo, package name = namespace name. PackageMerge would transform into a NamespaceMerge, giving the opportunity to select a distinguishing name for the target package. The current qualified names would reflect the namespace situation. If the package name is equal the namespace name, no additional notion is necessary. If the package name is different, I propose the following notation: [package_name]name_component1::name_component1::classifier_name and for unqualified names: [package_name]classifier_name Since the default (package name = namespace name) uses the existing naming scheme, immediate impact on tools could be minimized and tools can take a smooth transition into the extended scheme. What do you think? Manfred -- ************************************************ * PLEASE NOTE OUR NEW PHONE & FAX NUMBER BELOW * ************************************************ ___________________ / Manfred R. Koethe \_____________________________________ 88solutions Corp. E-Mail: koethe@88solutions.com 37 Mague Avenue Tel: +1 (617) 848 0525 Newton, MA 02465-1553 FAX: +1 (617) 848 8819 U.S.A. _____________________________"We make your business flow"_ Reply-To: Joaquin Miller X-Sender: joaquin%joaquin.net@secure.cnchost.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 24 Oct 2003 10:11:23 -0700 To: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org From: Joaquin Miller Subject: Re: ,gi, issues 6191 et al.: More thoughts on Package Merge Manfred makes a concrete proposal for removing the conflation* of namespace into package, and asks: What do you think? I think we must make the separation -- to give Java programmers the uniform names (and so, types) they need, -- while also giving distinct items distinct names. I'm optimistic that the concrete proposal (or some adjustment) will do the job. (I reserve comment on the proposed syntax.) I'll dare to venture that promoting MOF/UML::Namespace (ODP::NamingContext) to independent status will serve us well elsewhere. We will still be conflating ODP::Namespace with ODP::NamingContext, but: one thing at a time. Cordially, Joaquin ....... [ * I'd continue to insist they are conflated, by the use of subtyping, instead of combination. ] Date: Fri, 24 Oct 2003 13:25:36 -0400 From: Tom Rutt Reply-To: tom@coastin.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en To: Joaquin Miller CC: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: ,gi, issues 6191 et al.: More thoughts on Package Merge Joaquin Miller wrote: Manfred makes a concrete proposal for removing the conflation* of namespace into package, and asks: What do you think? I think we must make the separation I think that a package was a namespace until this package merge "naming" ambiguity arose. The simple case needs to ramain "package" is a "namespace" for its contents. If we need to perhaps a package can contain additional namespaces to accomodate the merge stuff. Tom Rutt Fujitsu -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Date: Fri, 24 Oct 2003 13:52:54 -0400 From: "Manfred R. Koethe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: tom@coastin.com CC: Joaquin Miller , mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: ,gi, issues 6191 et al.: More thoughts on Package Merge Tom, I think my separation proposal is accomodating your requirements. You can continue to work with namespaces the same way you work with packages today. Since PackageMerge potentialy creates variants of a single package (= single namespace) with content of potentially equally named elements in each variant, just distinguished by the details of their features, the current package = namespace concept leaves you in the dark selecting an explicit variant. Applying the separation as proposed, you could name every variant package differently (while they may all contain the same namespace). From a logical point of view your model "sees" a virtual package (= namespace), while you can use a discriminatory mechnism to unambiguously select exactly the variant you want to make visible at that given point. And as I said in my proposal, the default is package = namespace. That means, unless you explicitly start to name the package different, you will not experience any difference to the current situation. [to Joaquin:] The extended name syntax was just a proposal with hopefully least tool impact. And thanks for the support. Kind regards, Manfred Tom Rutt wrote: Joaquin Miller wrote: Manfred makes a concrete proposal for removing the conflation* of namespace into package, and asks: What do you think? I think we must make the separation I think that a package was a namespace until this package merge "naming" ambiguity arose. The simple case needs to ramain "package" is a "namespace" for its contents. If we need to perhaps a package can contain additional namespaces to accomodate the merge stuff. Tom Rutt Fujitsu -- ************************************************ * PLEASE NOTE OUR NEW PHONE & FAX NUMBER BELOW * ************************************************ ___________________ / Manfred R. Koethe \_____________________________________ 88solutions Corp. E-Mail: koethe@88solutions.com 37 Mague Avenue Tel: +1 (617) 848 0525 Newton, MA 02465-1553 FAX: +1 (617) 848 8819 U.S.A. _____________________________"We make your business flow"_ Date: Fri, 24 Oct 2003 13:59:03 -0400 From: Tom Rutt Reply-To: tom@coastin.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en To: "Manfred R. Koethe" CC: Joaquin Miller , mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: ,gi, issues 6191 et al.: More thoughts on Package Merge Manfred R. Koethe wrote: Tom, I think my separation proposal is accomodating your requirements. You can continue to work with namespaces the same way you work with packages today. Since PackageMerge potentialy creates variants of a single package (= single namespace) with content of potentially equally named elements in each variant, just distinguished by the details of their features, the current package = namespace concept leaves you in the dark selecting an explicit variant. If the user eliminates the "subnamespace" parameter in a reference, what is referred to? This is assuming that a merge was done to reach the final package. Applying the separation as proposed, you could name every variant package differently (while they may all contain the same namespace). From a logical point of view your model "sees" a virtual package (= namespace), while you can use a discriminatory mechnism to unambiguously select exactly the variant you want to make visible at that given point. And as I said in my proposal, the default is package = namespace. That means, unless you explicitly start to name the package different, you will not experience any difference to the current situation. [to Joaquin:] The extended name syntax was just a proposal with hopefully least tool impact. And thanks for the support. Kind regards, Manfred Tom Rutt wrote: Joaquin Miller wrote: Manfred makes a concrete proposal for removing the conflation* of namespace into package, and asks: What do you think? I think we must make the separation I think that a package was a namespace until this package merge "naming" ambiguity arose. The simple case needs to ramain "package" is a "namespace" for its contents. If we need to perhaps a package can contain additional namespaces to accomodate the merge stuff. Tom Rutt Fujitsu -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Reply-To: Joaquin Miller X-Sender: joaquin%joaquin.net@secure.cnchost.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 24 Oct 2003 12:15:59 -0700 To: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org From: Joaquin Miller Subject: Re: ,gi, issues 6191 et al.: More thoughts on Package Merge Tom Rutt wrote: Joaquin wrote: Manfred makes a concrete proposal for removing the conflation* of namespace into package, ... I think we must make the separation ... I think that a package was a namespace until this package merge "naming" ambiguity arose. I agree, Tom. A Package is a Namespace: the famous IsA. That's at the root of the problem. The simple case needs to remain "package" is a "namespace" for its contents. Maybe so. Or something very similar, and with the same benefit, but not exactly the same: A package comes with a namespace. That's the distinction that would solve the problem. (I can't say if this is a change that practice or politics allows us to make.) If we need to, perhaps a package can contain additional namespaces to accomodate the merge stuff. It seems to me that we need to, Tom. Here is one way to put it: A package comes with a namespace. That namespace has the same name as the package. (Maybe, i'd say very likely, that namespace is owned by that package.) The elements in a package can also have names in other MOF/UML::namespaces (ODP::naming contexts). For example, each of the many UML::Classes will each have a name in the namespace that comes with the package in which that particular (version of) Class is declared (the fully qualified form of this name is the name, 'Class', with the fully qualified name of that package tacked on in front). Each of these UML::Classes will also have a name in the namespace org.omg.uml2 (or whatever). Those names will not be ODP::identifiers, as all the UML::Classes will have the same name, 'org.omg.mof2::Class'. This gets us to the place where we have the same name for all Classes, to accommodate general purpose tools that want to avoid lots of very tricky typecasts, while at the same time, we have a different name for each UML::Class, for those folks who want to have a name for each class, which name is an identifier, so they can have a name for what they are talking about. Does that make sense? PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Reply-To: Joaquin Miller X-Sender: joaquin%joaquin.net@secure.cnchost.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 24 Oct 2003 12:25:47 -0700 To: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org From: Joaquin Miller Subject: Re: ,gi, issues 6191 et al.: More thoughts on Package Merge If the user eliminates the "subnamespace" parameter in a reference, what is referred to? This is assuming that a merge was done to reach the final package. If the question is what does a name refer to, if it is a simple name, and not a fully qualified name, then the general answer is: you can't tell. But you can have rules in place so you can tell. For example, if the tool or the person you are talking to, or what you are writing in your text or entering in your model, is already in the context of a particular package, then the unqualified name refers to the element of that name in that package. (The fully qualified name is taken to be the unqualified name with the fully qualified name of that package stuck on the front. The context tells us to use the namespace that comes with the package, and has the same name as the package.) If there is no such element, then either there are more rules, or again, you can't tell. [Just as you can't tell which Class i am talking about if i now make some comment about the class named, 'Class', in the UML 2 metamodel, final adopted spec version.] Meanwhile, the same element may have fully qualified names in other namespaces. Reply-To: Joaquin Miller X-Sender: joaquin%joaquin.net@secure.cnchost.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 24 Oct 2003 12:44:54 -0700 To: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org From: Joaquin Miller Subject: Re: ,gi, issues 6191 et al.: More thoughts on Package Merge Manfred wrote: And as I said in my proposal, the default is package = namespace. Or, following on my earlier messages today: The default namespace is the namespace that comes with the package. That namespace has the same name as that package. PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Reply-To: Joaquin Miller X-Sender: joaquin%joaquin.net@secure.cnchost.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 24 Oct 2003 12:54:54 -0700 To: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org From: Joaquin Miller Subject: Re: ,gi, issues 6191 et al. -- Namespace wants to be first class In a conversation at the UML conference Wednesday, I said that Namespace has been conflated with Package (and Classifier, ...). My interlocutor objected that there are still namespaces. But then thought about it for a moment and said: "Oh! Right, Namespace is abstract." That's correct: There are no namespaces. Only packages, classifiers and so on. I do not expect we will solve our problem until we admit first class namespaces (ODP::naming context). (There is a solid reason for each of these at-first-glance-not-necessary-or-useful distinctions in RM-ODP.) Cordially, Joaquin [In any event, we ought to be responsive to RFP requirement 5.1.12. There is a solid reason for that at-first-glance-fit-to-be-ignored mandatory requirement.] PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Subject: round 2 of packageMerge proposals Date: Fri, 24 Oct 2003 18:35:09 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-topic: Joint telecon on Wednesday, Oct. 29. Thread-index: AcOZs31VmQh2f5vtRRee/N4T4fQ0CgAyr4AA From: "Karl Frank" To: "Branislav Selic" , , , , "Michael Figurin" Cc: "Richard Gronback" , "Randy Miller" X-OriginalArrivalTime: 24 Oct 2003 22:35:11.0873 (UTC) FILETIME=[16186F10:01C39A7F] Attached is a proposal for making the one-liner and "Description" sections on packageMerge comprehensible. It is intended to be consistent with and be combined with a proposal for re-writing the "Semantics" section, perhaps to be provided by IBM's Jim Amstell. It is intended to be consistent with any proposal that may be forthcoming to make namespace and context concepts consistent with RM-ODP. Regards, Karl Frank Borland Software PackageMergeProposal_KF_v2.doc The proposal V2 is in green, below. The relevant part of the text of the final adopted spec now reads: 7.13.2 PackageMerge (from Kernel) A package merge defines how one package extends another package by merging their contents. Description A package merge is a relationship between two packages, where the contents of the target package (the one pointed at) is merged with the contents of the source package through specialization and redefinition, where applicable. This is a mechanism that should be used when elements of the same name are intended to represent the same concept, regardless of the package in which they are defined. A merging package will take elements of the same kind with the same name from one or more packages and merge them together into a single element using generalization and redefinitions. It should be noted that a package merge can be viewed as a short-hand way of explicitly defining those generalizations and redefinitions. The merged packages are still available, and the elements in those packages can be separately qualified. From an XMI point of view, it is either possible to exchange a model with all PackageMerges retained or a model where all PackageMerges have been transformed away (in which case package imports, generalizations, and redefinitions are used instead). The text proposed as the replacement for the above is: 7.13.2 PackageMerge (from Kernel) Package merge is an operation for adding the classifiers owned by a merged package to a merging package. Application of this operation results in a post-merge variant of the merging package. The post-merge variant of the merging package contains additional classifiers, based on the classifiers owned by the merged package, and have the same name as the merging package. The result of merging some package X with a package Y will differ from the result of merging Y with X, unless A and B are identical with respect to the elements they contained. Description PackageMerge is presented syntactically as a directed relationship from a merging (the source) package to a merged package (the target). Because the post-merge variant of the merging package will differ unless the merged and merging packages contain the same classifiers, it is necessary to distinguish which package plays which role. The notation of a directed relationship is convenient for this purpose. From all points of view, including XMI, it is necessary to differentiate the post-merge variant of a merging package, from the pre-merge variant of the same name. Thus, if X is a merging package that merges Y, and Y is a merging package that merges Z, it is necessary to distinguish whether X is merging the variant of Y which results from a prior merge of Z. Failure to make this distinction results in ambiguity. To cite another example, it is ambiguous to show X as a package that merges Y and Z, unless one shows whether it is the post-merge variant of X which merges Z after merging Y, or whether it is the pre-merge variant of X which merges Z before merging Y. PackageMerge provides a concise notation for showing the pre- and post- merge contents of a package. In the UML 2 specifications, application of the packageMerge operation results in variants which constitute distinct compliance points. Subject: more round 2 packageMerge Date: Fri, 24 Oct 2003 20:07:48 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-topic: Joint telecon on Wednesday, Oct. 29. Thread-index: AcOZs31VmQh2f5vtRRee/N4T4fQ0CgAyr4AA From: "Karl Frank" To: "Branislav Selic" , , , , "Michael Figurin" Cc: "Richard Gronback" , "Randy Miller" X-OriginalArrivalTime: 25 Oct 2003 00:07:50.0955 (UTC) FILETIME=[079107B0:01C39A8C] Haste makes waste. The file called v2 just sent out named PackageMergeProposal_KF_v2 was the wrong one. Intended one now attached called PackageMergeDescription_v3 Attached only addresses the one-liner and "Description" sections on packageMerge. It is intended to be consistent with and be combined with a proposal for re-writing the "Semantics" section, perhaps to be provided by IBM's Jim Amstell. It is intended to be consistent with any proposal that may be forthcoming to make namespace and context concepts consistent with RM-ODP. Regards, Karl Frank Borland Software PackageMergeDescription_v3.doc The proposal V2 is in green, below. The relevant part of the text of the final adopted spec now reads: 7.13.2 PackageMerge (from Kernel) A package merge defines how one package extends another package by merging their contents. Description A package merge is a relationship between two packages, where the contents of the target package (the one pointed at) is merged with the contents of the source package through specialization and redefinition, where applicable. This is a mechanism that should be used when elements of the same name are intended to represent the same concept, regardless of the package in which they are defined. A merging package will take elements of the same kind with the same name from one or more packages and merge them together into a single element using generalization and redefinitions. It should be noted that a package merge can be viewed as a short-hand way of explicitly defining those generalizations and redefinitions. The merged packages are still available, and the elements in those packages can be separately qualified. From an XMI point of view, it is either possible to exchange a model with all PackageMerges retained or a model where all PackageMerges have been transformed away (in which case package imports, generalizations, and redefinitions are used instead). The text proposed as the replacement for the above is: 7.13.2 PackageMerge (from Kernel) Package merge is an operation for adding the classifiers owned by a merged package to a merging package. Application of this operation results in a post-merge variant of the merging package. The post-merge variant of the merging package contains additional classifiers, based on the classifiers owned by the merged package. The result of merging some package X with a package Y will differ from the result of merging Y with X, unless X and Y are identical with respect to the elements they contained. Description PackageMerge is presented as if it were a directed relationship from a merging package (the source) to a merged package (the target). Because the post-merge variant of the merging package will in most cases differ from the premerge variant, with respect to its owned classifiers, whereas the merged package remains unchanged by the merge, it is necessary to distinguish which package plays the merging role. The notation of a directed relationship is convenient for this purpose. From all points of view, including XMI, it is necessary to differentiate the post-merge variant of a merging package, from the pre-merge variant. Thus, if X is a merging package that merges Y, and Y is a merging package that merges Z, it is necessary to distinguish whether X is merging the variant of Y which results from a prior merge of Z. Failure to make this distinction results in ambiguity. To cite another example, it is ambiguous to show X as a package that merges Y and Z, unless one shows whether it is the post-merge variant of X which merges Z after merging Y, or whether it is the pre-merge variant of X which merges Z before merging Y. PackageMerge provides a concise notation for showing the pre- and post- merge contents of a package. In the UML 2 specifications, application of the packageMerge operation results in variants which constitute distinct compliance points. To: "Manfred R. Koethe" Cc: Joaquin Miller , mu2i-ftf@omg.org, tom@coastin.com, uml2-superstructure-ftf@omg.org Subject: Re: ,gi, issues 6191 et al.: More thoughts on Package Merge X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 27 Oct 2003 11:06:38 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 10/27/2003 11:06:41, Serialize complete at 10/27/2003 11:06:41 This sounds like another item to discuss over the next several weeks. I am still not convinced that the separation is necessary (despite the fact that I agreed with Joaquin last week in our head-to-head discussion). I am currently of the opinion that the answer to the problem that started this whole thing is in versioning not in having different namespaces. You could argue that a new version of a given namespace is the same thing as a different namespace, but I think there are subtle differences that matter here. However, I have to think about this some more before I take a definitive view. Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Manfred R. Koethe" 10/24/2003 01:52 PM To: tom@coastin.com cc: Joaquin Miller , mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: ,gi, issues 6191 et al.: More thoughts on Package Merge Tom, I think my separation proposal is accomodating your requirements. You can continue to work with namespaces the same way you work with packages today. Since PackageMerge potentialy creates variants of a single package (= single namespace) with content of potentially equally named elements in each variant, just distinguished by the details of their features, the current package = namespace concept leaves you in the dark selecting an explicit variant. Applying the separation as proposed, you could name every variant package differently (while they may all contain the same namespace). From a logical point of view your model "sees" a virtual package (= namespace), while you can use a discriminatory mechnism to unambiguously select exactly the variant you want to make visible at that given point. And as I said in my proposal, the default is package = namespace. That means, unless you explicitly start to name the package different, you will not experience any difference to the current situation. [to Joaquin:] The extended name syntax was just a proposal with hopefully least tool impact. And thanks for the support. Kind regards, Manfred Tom Rutt wrote: > Joaquin Miller wrote: > >> Manfred makes a concrete proposal for removing the conflation* of >> namespace into package, and asks: >> >>> What do you think? >> >> >> >> I think we must make the separation > > > I think that a package was a namespace until this package merge "naming" > ambiguity arose. > > The simple case needs to ramain "package" is a "namespace" for its > contents. If we need to > perhaps a package can contain additional namespaces to accomodate the > merge stuff. > > Tom Rutt > Fujitsu > -- ************************************************ * PLEASE NOTE OUR NEW PHONE & FAX NUMBER BELOW * ************************************************ ___________________ / Manfred R. Koethe \_____________________________________ 88solutions Corp. E-Mail: koethe@88solutions.com 37 Mague Avenue Tel: +1 (617) 848 0525 Newton, MA 02465-1553 FAX: +1 (617) 848 8819 U.S.A. _____________________________"We make your business flow"_ Reply-To: Joaquin Miller X-Sender: joaquin%joaquin.net@secure.cnchost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 28 Oct 2003 00:10:34 -0800 To: MOF UML Infrastructure FTF , UML Superstructure FTF From: Joaquin Miller Subject: ,gi, issues 6191 et al.: Naming proposal for package merge proposal Cc: William F Frank PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Naming proposal--jm-1.ppt Subject: RE: Proposed rules for package merge replacement Date: Tue, 28 Oct 2003 09:42:26 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed rules for package merge replacement Thread-Index: AcOdG3qaW+4ZBEroQw6hUBHhGLmnIwAXrFuA From: "Michael Latta" To: "Branislav Selic" , , Cc: "Jim Amsden" , "Kenneth Hussey" X-OriginalArrivalTime: 28 Oct 2003 17:43:22.0140 (UTC) FILETIME=[FB2235C0:01C39D7A] The scope of this change, along with the ripple effect, seems to be WAY outside the scope of an FTF. This argues for a quick cycle 2.1 more than an FTF activity to me. Michael -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, October 27, 2003 10:19 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Cc: Jim Amsden; Kenneth Hussey Subject: Proposed rules for package merge replacement Dear FTFers, The list below represents IBM's current proposal for removing package merge by replacing it with something that is equivalent (at least from the point of view of the UML user), but which does not have the main implementability problems of the current proposal. Please note that we are in the process of evaluating this and assessing the impact both on the metamodel and on the spec itself. Hence, there may be changes to this proposal as we learn more about it. Still, given the significance of the issue we felt it useful to publish this so that we could get feedback as soon as possible (you will forgive the occasional lack of clarity below as well as any oversights, but it's getting late, and I am getting tired). 1. For each (meta) class, ensure that it redefines every property inherited from superclasses. (This may not be true for all cases in Constructs which was created by doing a package merge by hand.) 2. For each class at a given level in the class hiearchy, remove all of its superclasses that have the same name as that class and add a generalization to each of its direct superclasses that have a different name. This process is repeated recursively until the top level of the class is reached. 3. Remove all the property redefinitions to properties of removed superclasses. 4. Add the property redefinitions of the removed superclass to the subclass (these will be potentially removed when recursing up the rest of the hierarchy). 5. If a property redefines a property with a new name, (where the redefined property is in a collapsed type), make the redefined property derived. 6. If a redefining property is derived, and its redefined property is non-derived in the removed superclass, make the property non-derived (so it will have a slot). If a redefining property is non-derived, and its redefined property is derived in the removed superclass, keep the redefined property as non-derived as well as the non-derived redefining property. 7. Remove all properties that redefine a property with the same name in any remaining (non-matching) supertype. For example, remove the property raisedException from Operation, it redefines raisedException from BehavioralFeature. The inherited property is used instead, and a downcast is required for type tightening. 8. Make all properties that redefine and rename a property of any remaining (non-matching) supertype derived. They can be implemented by accessing the redefined property. For example, for Operation::formalParameter which redefines Basic::Operation::ownedParameter. 9. Fix package imports so only packages actually referenced are imported. 10. Create the enumeration VisibilityKind in Constructs (this will be merged in from Abstractions::Visibilities) 11. Operation: add inheritance from TypedElement and MultiplicityElement, to compensate for removal of inheritance from Basic::Operation (gets handled by adding superclasses of removed superclass to its subclasses) 12. Convert any unreferenced packages: packages that are not merged or imported either directly or indirectly by the target package being merged, to new capability packages. For example, packages Profiles and parts of Abstractions can be treated as separate capabilities since they are not directly referenced from Constructs after the merge and collapse. 13. Eliminate any situation where the same property was inherited from two superclasses, but didn't have a common superclass that defined the property. 14. For class Package, make the property ownedType non-derived. Package, Type, Constraint, ParameterableElement, GeneralizationSet, and InstanceSpecification are all PackageableElements. Package::ownedMember redefines Namespace::OwnedMember to refer to PackageableElements. Package::/ownedType subsets ownedMember to provide a convenient method for accessing the types in a package. This should be just treated as a derived property so that all the types in a package are owned members too. 15. Abstractions and Basic will have no references to them from Constructs since they have been collapsed away. These are candidates for removal. As I noted, more work needs to be done with this, but let's get the discussion going. Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com From: Edwin Seidewitz To: "'Michael Latta'" , Branislav Selic , uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org Cc: Jim Amsden , Kenneth Hussey Subject: RE: Proposed rules for package merge replacement Date: Tue, 28 Oct 2003 14:06:08 -0500 X-Mailer: Internet Mail Service (5.5.2655.55) "urn:schemas-microsoft-com:office:office" xmlns:w = "urn:schemas-microsoft-com:office:word"> Michael -- Technically, the scope of an RTF (that would produce a version 2.1) is supposed to be, if anything, MORE limited than an FTF, not less. The UML RTFs were, in OMG policy and procedure terms, anomolies due to the poor quality of the UML 1.1 specification as adopted. Of course, you are probably technically correct that what is being proposed is outside the proper scope of an FTF, too. However, it was known by the AB that the UML 2.0 FTFs would need to have a good deal of latitude in order to deal with the issues raised before the UML 2.0 specs were adopted (I can retrieve the e-mails on this, if you like...). (I does seem like history is repeating itself, doesn't it...) Since the problems that are being addressed are, I think, critical for making the UML 2.0 spec reasonably usable for a number of vendors, it is important that they are addressed as soon as possible. Any delay will only make it harder to get UML 2.0 established. In essence, the current FTF is really serving a similar function to the first UML RTF (since there was no FTF process at the time), which took UML 1.1 to 1.3 (if you remember, 1.2 was never actually released). I would urge the current FTF to also do whatever is necessary to get the UML 2.0 spec ready for prime time. If the FTF votes to approve a course of action, whatever its scope, then the AB will go along -- because they have to, because it is a situation they helped create. -- Ed -----Original Message----- From: Michael Latta [mailto:mlatta@ceira.com] Sent: Tuesday, October 28, 2003 12:42 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Cc: Jim Amsden; Kenneth Hussey Subject: RE: Proposed rules for package merge replacement The scope of this change, along with the ripple effect, seems to be WAY outside the scope of an FTF. This argues for a quick cycle 2.1 more than an FTF activity to me. Michael -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, October 27, 2003 10:19 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Cc: Jim Amsden; Kenneth Hussey Subject: Proposed rules for package merge replacement Dear FTFers, The list below represents IBM's current proposal for removing package merge by replacing it with something that is equivalent (at least from the point of view of the UML user), but which does not have the main implementability problems of the current proposal. Please note that we are in the process of evaluating this and assessing the impact both on the metamodel and on the spec itself. Hence, there may be changes to this proposal as we learn more about it. Still, given the significance of the issue we felt it useful to publish this so that we could get feedback as soon as possible (you will forgive the occasional lack of clarity below as well as any oversights, but it's getting late, and I am getting tired). 1. For each (meta) class, ensure that it redefines every property inherited from superclasses. (This may not be true for all cases in Constructs which was created by doing a package merge by hand.) 2. For each class at a given level in the class hiearchy, remove all of its superclasses that have the same name as that class and add a generalization to each of its direct superclasses that have a different name. This process is repeated recursively until the top level of the class is reached. 3. Remove all the property redefinitions to properties of removed superclasses. 4. Add the property redefinitions of the removed superclass to the subclass (these will be potentially removed when recursing up the rest of the hierarchy). 5. If a property redefines a property with a new name, (where the redefined property is in a collapsed type), make the redefined property derived. 6. If a redefining property is derived, and its redefined property is non-derived in the removed superclass, make the property non-derived (so it will have a slot). If a redefining property is non-derived, and its redefined property is derived in the removed superclass, keep the redefined property as non-derived as well as the non-derived redefining property. 7. Remove all properties that redefine a property with the same name in any remaining (non-matching) supertype. For example, remove the property raisedException from Operation, it redefines raisedException from BehavioralFeature. The inherited property is used instead, and a downcast is required for type tightening. 8. Make all properties that redefine and rename a property of any remaining (non-matching) supertype derived. They can be implemented by accessing the redefined property. For example, for Operation::formalParameter which redefines Basic::Operation::ownedParameter. 9. Fix package imports so only packages actually referenced are imported. 10. Create the enumeration VisibilityKind in Constructs (this will be merged in from Abstractions::Visibilities) 11. Operation: add inheritance from TypedElement and MultiplicityElement, to compensate for removal of inheritance from Basic::Operation (gets handled by adding superclasses of removed superclass to its subclasses) 12. Convert any unreferenced packages: packages that are not merged or imported either directly or indirectly by the target package being merged, to new capability packages. For example, packages Profiles and parts of Abstractions can be treated as separate capabilities since they are not directly referenced from Constructs after the merge and collapse. 13. Eliminate any situation where the same property was inherited from two superclasses, but didn't have a common superclass that defined the property. 14. For class Package, make the property ownedType non-derived. Package, Type, Constraint, ParameterableElement, GeneralizationSet, and InstanceSpecification are all PackageableElements. Package::ownedMember redefines Namespace::OwnedMember to refer to PackageableElements. Package::/ownedType subsets ownedMember to provide a convenient method for accessing the types in a package. This should be just treated as a derived property so that all the types in a package are owned members too. 15. Abstractions and Basic will have no references to them from Constructs since they have been collapsed away. These are candidates for removal. As I noted, more work needs to be done with this, but let's get the discussion going. Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com To: erang@ilogix.co.il Cc: Branislav Selic , Kenneth Hussey , , Subject: X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Jim Amsden Date: Tue, 28 Oct 2003 07:44:04 -0700 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/28/2003 07:44:06, Serialize complete at 10/28/2003 07:44:06 Eran, By "replacing package merge", we mean to replace package merge as currently defined with a new definition that produces the same semantic result, but without introducing specialization and redefinition, or change in the package namespace. The purpose of this new definition is to address some interoperability, complexity, usability, and implementability issues that result from the current approach. InfrastructureLibrary was effectively created by doing a "hand merge" using the current package merge definition, thereby resulting in the problems noted above. We propose that InfrastructureLibrary be re-hand merged using the new algorithm to address these problems. The rules below describe a way of transforming InfrastructureLibrary from its current form to a result that is consistent with the new definition of package merge. Sorry for the confusion. "Eran Gery" 10/28/2003 07:19 AM To: "'Branislav Selic'" cc: Jim Amsden/Raleigh/IBM@IBMUS, "'Kenneth Hussey'" , , Subject: RE: Proposed rules for package merge replacement Bran By "replacing package merge" do you mean - Only for the sake of getting L1 independent of package merge - Completely replace it within the entire metamodel of infra and super - Eliminate it alltogether including as a modeling construct for end-users I believe you mean #1 but please clarify before we dive into this replacement algorithm... Thanks, Eran -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tue, October 28, 2003 8:19 AM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Cc: Jim Amsden; Kenneth Hussey Subject: Proposed rules for package merge replacement Dear FTFers, The list below represents IBM's current proposal for removing package merge by replacing it with something that is equivalent (at least from the point of view of the UML user), but which does not have the main implementability problems of the current proposal. Please note that we are in the process of evaluating this and assessing the impact both on the metamodel and on the spec itself. Hence, there may be changes to this proposal as we learn more about it. Still, given the significance of the issue we felt it useful to publish this so that we could get feedback as soon as possible (you will forgive the occasional lack of clarity below as well as any oversights, but it's getting late, and I am getting tired). 1. For each (meta) class, ensure that it redefines every property inherited from superclasses. (This may not be true for all cases in Constructs which was created by doing a package merge by hand.) 2. For each class at a given level in the class hiearchy, remove all of its superclasses that have the same name as that class and add a generalization to each of its direct superclasses that have a different name. This process is repeated recursively until the top level of the class is reached. 3. Remove all the property redefinitions to properties of removed superclasses. 4. Add the property redefinitions of the removed superclass to the subclass (these will be potentially removed when recursing up the rest of the hierarchy). 5. If a property redefines a property with a new name, (where the redefined property is in a collapsed type), make the redefined property derived. 6. If a redefining property is derived, and its redefined property is non-derived in the removed superclass, make the property non-derived (so it will have a slot). If a redefining property is non-derived, and its redefined property is derived in the removed superclass, keep the redefined property as non-derived as well as the non-derived redefining property. 7. Remove all properties that redefine a property with the same name in any remaining (non-matching) supertype. For example, remove the property raisedException from Operation, it redefines raisedException from BehavioralFeature. The inherited property is used instead, and a downcast is required for type tightening. 8. Make all properties that redefine and rename a property of any remaining (non-matching) supertype derived. They can be implemented by accessing the redefined property. For example, for Operation::formalParameter which redefines Basic::Operation::ownedParameter. 9. Fix package imports so only packages actually referenced are imported. 10. Create the enumeration VisibilityKind in Constructs (this will be merged in from Abstractions::Visibilities) 11. Operation: add inheritance from TypedElement and MultiplicityElement, to compensate for removal of inheritance from Basic::Operation (gets handled by adding superclasses of removed superclass to its subclasses) 12. Convert any unreferenced packages: packages that are not merged or imported either directly or indirectly by the target package being merged, to new capability packages. For example, packages Profiles and parts of Abstractions can be treated as separate capabilities since they are not directly referenced from Constructs after the merge and collapse. 13. Eliminate any situation where the same property was inherited from two superclasses, but didn't have a common superclass that defined the property. 14. For class Package, make the property ownedType non-derived. Package, Type, Constraint, ParameterableElement, GeneralizationSet, and InstanceSpecification are all PackageableElements. Package::ownedMember redefines Namespace::OwnedMember to refer to PackageableElements. Package::/ownedType subsets ownedMember to provide a convenient method for accessing the types in a package. This should be just treated as a derived property so that all the types in a package are owned members too. 15. Abstractions and Basic will have no references to them from Constructs since they have been collapsed away. These are candidates for removal. As I noted, more work needs to be done with this, but let's get the discussion going. Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com From: Edwin Seidewitz To: uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org Subject: RE: Date: Tue, 28 Oct 2003 14:33:21 -0500 X-Mailer: Internet Mail Service (5.5.2655.55) Of course, once you have done the proposed "hand merge", assuming that the proposed approach produces a better overall structure than in the current Infrastructure Library metamodel (and, on first look, it seems that it probably does), I would have to question whether retaining package merge is really very useful at all. We seem to be going to a lot of effort to restructure and redefine things in order to retain the concept of package merge. However, I, personally, have not heard a convincing argument why we would want to retain package merge at all. I know that the intent of package merge was to produce a more factored metamodel that is more reusable. But the evidence, so far, seems to be that the package merge construct (however it is defined) is only causing confusion and is resulting in an end metamodel structure that is harder, not easier, to understand, use and reuse. Why not just apply the a new and improved "hand merge" along the lines of what is being proposed, change all <> dependencies to <> and be done with it? -- Ed > -----Original Message----- > From: Jim Amsden [mailto:jamsden@us.ibm.com] > Sent: Tuesday, October 28, 2003 9:44 AM > To: erang@ilogix.co.il > Cc: Branislav Selic; Kenneth Hussey; uml2-superstructure-ftf@omg.org; > mu2i-ftf@omg.org > Subject: > > > Eran, > By "replacing package merge", we mean to replace package merge as > currently defined with a new definition that produces the > same semantic > result, but without introducing specialization and > redefinition, or change > in the package namespace. The purpose of this new definition > is to address > some interoperability, complexity, usability, and > implementability issues > that result from the current approach. > > InfrastructureLibrary was effectively created by doing a "hand merge" > using the current package merge definition, thereby resulting in the > problems noted above. We propose that InfrastructureLibrary > be re-hand > merged using the new algorithm to address these problems. The > rules below > describe a way of transforming InfrastructureLibrary from its > current form > to a result that is consistent with the new definition of > package merge. > > Sorry for the confusion. > > > > > > "Eran Gery" > 10/28/2003 07:19 AM > > To: "'Branislav Selic'" > cc: Jim Amsden/Raleigh/IBM@IBMUS, "'Kenneth Hussey'" > , , > > Subject: RE: Proposed rules for package merge > replacement > > > Bran > > By "replacing package merge" do you mean > > - Only for the sake of getting L1 independent of package merge > - Completely replace it within the entire metamodel of infra and super > - Eliminate it alltogether including as a modeling construct > for end-users > > I believe you mean #1 but please clarify before we dive into this > replacement algorithm... > > Thanks, > Eran Subject: RE: Proposed rules for package merge replacement Date: Tue, 28 Oct 2003 12:17:47 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed rules for package merge replacement Thread-Index: AcOdjThJzjVpFjutQy2gQ3H+kAyM/wAAeRQA From: "Michael Latta" To: "Branislav Selic" Cc: "Jim Amsden" , "Kenneth Hussey" , , X-OriginalArrivalTime: 28 Oct 2003 20:18:43.0953 (UTC) FILETIME=[AF5DFE10:01C39D90] While this may be in scope for the FTF, my main concern is the final result. To implement the proposed scope of changes it seems to me a huge portion of the spec will need to be rewritten. Most diagrams will need revising, and large parts of the text will need to be revised. While the metamodel changes can be described mechanically, the editing tasks resulting from this will be a huge task. Since the changes are being described as mechanical in nature why is the resulting model more implementable? Any mechanical transformation can be accommodated in code far better than when applied to textual specs. I would assert that it is NOT a mechanical transform to correct the root issue. As such the resulting work is going to need a much larger level of effort than I think the FTF is prepared for. This is the core of my concern. Not an issue of authority, but of manageability. Do we have manpower and process in place to perform and review a virtual rewrite of a 600 page spec? Will the resulting spec reflect the views of a limited number of companies because those companies can devote multiple man-years of effort to the spec, while smaller companies need to produce products? Michael -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, October 28, 2003 11:54 AM To: Michael Latta Cc: Jim Amsden; Kenneth Hussey; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Proposed rules for package merge replacement Michael, The FTF has the mandate to fix any implementability/feasibility issues that might exist with a spec -- that is precisely what an FTF is for. If a spec cannot be realistically implemented it has to be fixed. The proposal provided here is intended to fix specific well-documented implementability issues. Hence, both the issue and its resolution are certainly within the mandate of the FTF. However, if there are any other solutions to the same problems, they should be put forward for discussion. We will have a discussion on this point tomorrow and in the weeks leading up to the London meeting as well as during that meeting itself. Please join us for the telecon tomorrow to express your concerns. Regards, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Michael Latta" 10/28/2003 12:42 PM To: Branislav Selic/Ottawa/IBM@IBMCA, , cc: "Jim Amsden" , Kenneth Hussey/Ottawa/IBM@IBMCA Subject: RE: Proposed rules for package merge replacement The scope of this change, along with the ripple effect, seems to be WAY outside the scope of an FTF. This argues for a quick cycle 2.1 more than an FTF activity to me. Michael -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, October 27, 2003 10:19 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Cc: Jim Amsden; Kenneth Hussey Subject: Proposed rules for package merge replacement Dear FTFers, The list below represents IBM's current proposal for removing package merge by replacing it with something that is equivalent (at least from the point of view of the UML user), but which does not have the main implementability problems of the current proposal. Please note that we are in the process of evaluating this and assessing the impact both on the metamodel and on the spec itself. Hence, there may be changes to this proposal as we learn more about it. Still, given the significance of the issue we felt it useful to publish this so that we could get feedback as soon as possible (you will forgive the occasional lack of clarity below as well as any oversights, but it's getting late, and I am getting tired). 1. For each (meta) class, ensure that it redefines every property inherited from superclasses. (This may not be true for all cases in Constructs which was created by doing a package merge by hand.) 2. For each class at a given level in the class hiearchy, remove all of its superclasses that have the same name as that class and add a generalization to each of its direct superclasses that have a different name. This process is repeated recursively until the top level of the class is reached. 3. Remove all the property redefinitions to properties of removed superclasses. 4. Add the property redefinitions of the removed superclass to the subclass (these will be potentially removed when recursing up the rest of the hierarchy). 5. If a property redefines a property with a new name, (where the redefined property is in a collapsed type), make the redefined property derived. 6. If a redefining property is derived, and its redefined property is non-derived in the removed superclass, make the property non-derived (so it will have a slot). If a redefining property is non-derived, and its redefined property is derived in the removed superclass, keep the redefined property as non-derived as well as the non-derived redefining property. 7. Remove all properties that redefine a property with the same name in any remaining (non-matching) supertype. For example, remove the property raisedException from Operation, it redefines raisedException from BehavioralFeature. The inherited property is used instead, and a downcast is required for type tightening. 8. Make all properties that redefine and rename a property of any remaining (non-matching) supertype derived. They can be implemented by accessing the redefined property. For example, for Operation::formalParameter which redefines Basic::Operation::ownedParameter. 9. Fix package imports so only packages actually referenced are imported. 10. Create the enumeration VisibilityKind in Constructs (this will be merged in from Abstractions::Visibilities) 11. Operation: add inheritance from TypedElement and MultiplicityElement, to compensate for removal of inheritance from Basic::Operation (gets handled by adding superclasses of removed superclass to its subclasses) 12. Convert any unreferenced packages: packages that are not merged or imported either directly or indirectly by the target package being merged, to new capability packages. For example, packages Profiles and parts of Abstractions can be treated as separate capabilities since they are not directly referenced from Constructs after the merge and collapse. 13. Eliminate any situation where the same property was inherited from two superclasses, but didn't have a common superclass that defined the property. 14. For class Package, make the property ownedType non-derived. Package, Type, Constraint, ParameterableElement, GeneralizationSet, and InstanceSpecification are all PackageableElements. Package::ownedMember redefines Namespace::OwnedMember to refer to PackageableElements. Package::/ownedType subsets ownedMember to provide a convenient method for accessing the types in a package. This should be just treated as a derived property so that all the types in a package are owned members too. 15. Abstractions and Basic will have no references to them from Constructs since they have been collapsed away. These are candidates for removal. As I noted, more work needs to be done with this, but let's get the discussion going. Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com Date: Tue, 28 Oct 2003 15:28:50 -0500 From: Tom Rutt Reply-To: tom@coastin.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en To: Branislav Selic CC: Michael Latta , Jim Amsden , Kenneth Hussey , mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: Proposed rules for package merge replacement Branislav Selic wrote: Michael, The FTF has the mandate to fix any implementability/feasibility issues that might exist with a spec -- that is precisely what an FTF is for. If a spec cannot be realistically implemented it has to be fixed. The proposal provided here is intended to fix specific well-documented implementability issues. Hence, both the issue and its resolution are certainly within the mandate of the FTF. However, if there are any other solutions to the same problems, they should be put forward for discussion. We will have a discussion on this point tomorrow and in the weeks leading up to the London meeting as well as during that meeting itself. I agree with Bran, that we have a big problem with the namespace stuff of the existing package merge. It is broken, and thus we need to fix it. However, I also agree that the more minimal the fix is the better (as long as it really fixes the problem) I also have not yet fully read or understood the IBM proposal, So I am not yet explcitly approving it. Tom Rutt Fujitsu. Tom Rutt Please join us for the telecon tomorrow to express your concerns. Regards, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com *"Michael Latta" * 10/28/2003 12:42 PM To: Branislav Selic/Ottawa/IBM@IBMCA, , cc: "Jim Amsden" , Kenneth Hussey/Ottawa/IBM@IBMCA Subject: RE: Proposed rules for package merge replacement The scope of this change, along with the ripple effect, seems to be WAY outside the scope of an FTF. This argues for a quick cycle 2.1 more than an FTF activity to me. Michael -----Original Message-----* From:* Branislav Selic [mailto:bselic@ca.ibm.com] * Sent:* Monday, October 27, 2003 10:19 PM* To:* uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org* Cc:* Jim Amsden; Kenneth Hussey* Subject:* Proposed rules for package merge replacement -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Reply-To: From: "Conrad Bock" To: "uml2ftf" Cc: "Jim Amsden" , "Kenneth Hussey" , Subject: RE: Proposed rules for package merge replacement Date: Tue, 28 Oct 2003 15:30:48 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal > To implement the proposed scope of changes it seems to me a huge portion of the > spec will need to be rewritten. Proposers should indicate the scope of the change to the spec, for those of us who are not tracking this issue closely. I personally am not prepared to make alot of changes. Conrad From: "Thomas Weigert" To: "Branislav Selic" , , Cc: "Jim Amsden" , "Kenneth Hussey" Subject: RE: Proposed rules for package merge replacement Date: Tue, 28 Oct 2003 14:42:26 -0600 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal Bran, I think it would be great if you could prepare an example of this change (a before/after diagram) for some representative diagram, so that we can easier appreciate what you propose. Thanks, Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, October 28, 2003 12:19 AM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Cc: Jim Amsden; Kenneth Hussey Subject: Proposed rules for package merge replacement Dear FTFers, The list below represents IBM's current proposal for removing package merge by replacing it with something that is equivalent (at least from the point of view of the UML user), but which does not have the main implementability problems of the current proposal. Please note that we are in the process of evaluating this and assessing the impact both on the metamodel and on the spec itself. Hence, there may be changes to this proposal as we learn more about it. Still, given the significance of the issue we felt it useful to publish this so that we could get feedback as soon as possible (you will forgive the occasional lack of clarity below as well as any oversights, but it's getting late, and I am getting tired). For each (meta) class, ensure that it redefines every property inherited from superclasses. (This may not be true for all cases in Constructs which was created by doing a package merge by hand.) For each class at a given level in the class hiearchy, remove all of its superclasses that have the same name as that class and add a generalization to each of its direct superclasses that have a different name. This process is repeated recursively until the top level of the class is reached. Remove all the property redefinitions to properties of removed superclasses. Add the property redefinitions of the removed superclass to the subclass (these will be potentially removed when recursing up the rest of the hierarchy). If a property redefines a property with a new name, (where the redefined property is in a collapsed type), make the redefined property derived. If a redefining property is derived, and its redefined property is non-derived in the removed superclass, make the property non-derived (so it will have a slot). If a redefining property is non-derived, and its redefined property is derived in the removed superclass, keep the redefined property as non-derived as well as the non-derived redefining property. Remove all properties that redefine a property with the same name in any remaining (non-matching) supertype. For example, remove the property raisedException from Operation, it redefines raisedException from BehavioralFeature. The inherited property is used instead, and a downcast is required for type tightening. Make all properties that redefine and rename a property of any remaining (non-matching) supertype derived. They can be implemented by accessing the redefined property. For example, for Operation::formalParameter which redefines Basic::Operation::ownedParameter. Fix package imports so only packages actually referenced are imported. Create the enumeration VisibilityKind in Constructs (this will be merged in from Abstractions::Visibilities) Operation: add inheritance from TypedElement and MultiplicityElement, to compensate for removal of inheritance from Basic::Operation (gets handled by adding superclasses of removed superclass to its subclasses) Convert any unreferenced packages: packages that are not merged or imported either directly or indirectly by the target package being merged, to new capability packages. For example, packages Profiles and parts of Abstractions can be treated as separate capabilities since they are not directly referenced from Constructs after the merge and collapse. Eliminate any situation where the same property was inherited from two superclasses, but didn't have a common superclass that defined the property. For class Package, make the property ownedType non-derived. Package, Type, Constraint, ParameterableElement, GeneralizationSet, and InstanceSpecification are all PackageableElements. Package::ownedMember redefines Namespace::OwnedMember to refer to PackageableElements. Package::/ownedType subsets ownedMember to provide a convenient method for accessing the types in a package. This should be just treated as a derived property so that all the types in a package are owned members too. Abstractions and Basic will have no references to them from Constructs since they have been collapsed away. These are candidates for removal. As I noted, more work needs to be done with this, but let's get the discussion going. Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com To: "Michael Latta" Cc: "Jim Amsden" , "Kenneth Hussey" , mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Proposed rules for package merge replacement X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Wed, 29 Oct 2003 01:16:26 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 10/29/2003 01:16:27, Serialize complete at 10/29/2003 01:16:27 Michael, The very same points that you raise were already noted by Cris Kobryn. However, you (and he) may have missed some points in the proposal. Most important is that the proposal recommends that many of the intermediate levels in the current model be collapsed. It does not specifically say which ones, since that depends on what we do with the compliance points (which is why the two are not easily separable). In addition, the proposal prescribes a number of items that will remove additional implementability problems (e.g., duplicate feature names). Note also that most of the changes will not require rewriting but merely rearranging of text. The result will also reduce the size of the spec, due to the collapsing of metaclasses. An analysis of the potential impact still needs to be provided (again, this depends on the compliance points solution), so, until that is available, there is no point in speculating or raising vague fears about "rewriting a 600 page spec". I agree fully that it would not be appropriate to make a final decision on this point unless we have a sufficient understanding of the potential impact. Of course, all companies, big or small, need to produce products and remain competitive, so, I feel that the implication that big companies are fiddling while UML 2 is burning is NOT appropriate (in addition to being somewhat unfair to FTF members who are working hard to complete the job that an FTF is supposed to be doing). Regards, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Michael Latta" 10/28/2003 03:17 PM To: Branislav Selic/Ottawa/IBM@IBMCA cc: "Jim Amsden" , Kenneth Hussey/Ottawa/IBM@IBMCA, , Subject: RE: Proposed rules for package merge replacement While this may be in scope for the FTF, my main concern is the final result. To implement the proposed scope of changes it seems to me a huge portion of the spec will need to be rewritten. Most diagrams will need revising, and large parts of the text will need to be revised. While the metamodel changes can be described mechanically, the editing tasks resulting from this will be a huge task. Since the changes are being described as mechanical in nature why is the resulting model more implementable? Any mechanical transformation can be accommodated in code far better than when applied to textual specs. I would assert that it is NOT a mechanical transform to correct the root issue. As such the resulting work is going to need a much larger level of effort than I think the FTF is prepared for. This is the core of my concern. Not an issue of authority, but of manageability. Do we have manpower and process in place to perform and review a virtual rewrite of a 600 page spec? Will the resulting spec reflect the views of a limited number of companies because those companies can devote multiple man-years of effort to the spec, while smaller companies need to produce products? Michael -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, October 28, 2003 11:54 AM To: Michael Latta Cc: Jim Amsden; Kenneth Hussey; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Proposed rules for package merge replacement Michael, The FTF has the mandate to fix any implementability/feasibility issues that might exist with a spec -- that is precisely what an FTF is for. If a spec cannot be realistically implemented it has to be fixed. The proposal provided here is intended to fix specific well-documented implementability issues. Hence, both the issue and its resolution are certainly within the mandate of the FTF. However, if there are any other solutions to the same problems, they should be put forward for discussion. We will have a discussion on this point tomorrow and in the weeks leading up to the London meeting as well as during that meeting itself. Please join us for the telecon tomorrow to express your concerns. Regards, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Michael Latta" 10/28/2003 12:42 PM To: Branislav Selic/Ottawa/IBM@IBMCA, , cc: "Jim Amsden" , Kenneth Hussey/Ottawa/IBM@IBMCA Subject: RE: Proposed rules for package merge replacement The scope of this change, along with the ripple effect, seems to be WAY outside the scope of an FTF. This argues for a quick cycle 2.1 more than an FTF activity to me. Michael -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, October 27, 2003 10:19 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Cc: Jim Amsden; Kenneth Hussey Subject: Proposed rules for package merge replacement Dear FTFers, The list below represents IBM's current proposal for removing package merge by replacing it with something that is equivalent (at least from the point of view of the UML user), but which does not have the main implementability problems of the current proposal. Please note that we are in the process of evaluating this and assessing the impact both on the metamodel and on the spec itself. Hence, there may be changes to this proposal as we learn more about it. Still, given the significance of the issue we felt it useful to publish this so that we could get feedback as soon as possible (you will forgive the occasional lack of clarity below as well as any oversights, but it's getting late, and I am getting tired). 1. For each (meta) class, ensure that it redefines every property inherited from superclasses. (This may not be true for all cases in Constructs which was created by doing a package merge by hand.) 2. For each class at a given level in the class hiearchy, remove all of its superclasses that have the same name as that class and add a generalization to each of its direct superclasses that have a different name. This process is repeated recursively until the top level of the class is reached. 3. Remove all the property redefinitions to properties of removed superclasses. 4. Add the property redefinitions of the removed superclass to the subclass (these will be potentially removed when recursing up the rest of the hierarchy). 5. If a property redefines a property with a new name, (where the redefined property is in a collapsed type), make the redefined property derived. 6. If a redefining property is derived, and its redefined property is non-derived in the removed superclass, make the property non-derived (so it will have a slot). If a redefining property is non-derived, and its redefined property is derived in the removed superclass, keep the redefined property as non-derived as well as the non-derived redefining property. 7. Remove all properties that redefine a property with the same name in any remaining (non-matching) supertype. For example, remove the property raisedException from Operation, it redefines raisedException from BehavioralFeature. The inherited property is used instead, and a downcast is required for type tightening. 8. Make all properties that redefine and rename a property of any remaining (non-matching) supertype derived. They can be implemented by accessing the redefined property. For example, for Operation::formalParameter which redefines Basic::Operation::ownedParameter. 9. Fix package imports so only packages actually referenced are imported. 10. Create the enumeration VisibilityKind in Constructs (this will be merged in from Abstractions::Visibilities) 11. Operation: add inheritance from TypedElement and MultiplicityElement, to compensate for removal of inheritance from Basic::Operation (gets handled by adding superclasses of removed superclass to its subclasses) 12. Convert any unreferenced packages: packages that are not merged or imported either directly or indirectly by the target package being merged, to new capability packages. For example, packages Profiles and parts of Abstractions can be treated as separate capabilities since they are not directly referenced from Constructs after the merge and collapse. 13. Eliminate any situation where the same property was inherited from two superclasses, but didn't have a common superclass that defined the property. 14. For class Package, make the property ownedType non-derived. Package, Type, Constraint, ParameterableElement, GeneralizationSet, and InstanceSpecification are all PackageableElements. Package::ownedMember redefines Namespace::OwnedMember to refer to PackageableElements. Package::/ownedType subsets ownedMember to provide a convenient method for accessing the types in a package. This should be just treated as a derived property so that all the types in a package are owned members too. 15. Abstractions and Basic will have no references to them from Constructs since they have been collapsed away. These are candidates for removal. As I noted, more work needs to be done with this, but let's get the discussion going. Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com To: "Thomas Weigert" Cc: "Jim Amsden" , "Kenneth Hussey" , mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Proposed rules for package merge replacement X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Wed, 29 Oct 2003 01:37:59 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 10/29/2003 01:38:01, Serialize complete at 10/29/2003 01:38:01 I agree with Thomas that this would be very useful. We will not be able to produce this for tomorrow's meeting, but hope to have one for the meeting after. Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 10/28/2003 03:42 PM To: Branislav Selic/Ottawa/IBM@IBMCA, , cc: "Jim Amsden" , Kenneth Hussey/Ottawa/IBM@IBMCA Subject: RE: Proposed rules for package merge replacement Bran, I think it would be great if you could prepare an example of this change (a before/after diagram) for some representative diagram, so that we can easier appreciate what you propose. Thanks, Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, October 28, 2003 12:19 AM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Cc: Jim Amsden; Kenneth Hussey Subject: Proposed rules for package merge replacement Dear FTFers, The list below represents IBM's current proposal for removing package merge by replacing it with something that is equivalent (at least from the point of view of the UML user), but which does not have the main implementability problems of the current proposal. Please note that we are in the process of evaluating this and assessing the impact both on the metamodel and on the spec itself. Hence, there may be changes to this proposal as we learn more about it. Still, given the significance of the issue we felt it useful to publish this so that we could get feedback as soon as possible (you will forgive the occasional lack of clarity below as well as any oversights, but it's getting late, and I am getting tired). 1. For each (meta) class, ensure that it redefines every property inherited from superclasses. (This may not be true for all cases in Constructs which was created by doing a package merge by hand.) 2. For each class at a given level in the class hiearchy, remove all of its superclasses that have the same name as that class and add a generalization to each of its direct superclasses that have a different name. This process is repeated recursively until the top level of the class is reached. 3. Remove all the property redefinitions to properties of removed superclasses. 4. Add the property redefinitions of the removed superclass to the subclass (these will be potentially removed when recursing up the rest of the hierarchy). 5. If a property redefines a property with a new name, (where the redefined property is in a collapsed type), make the redefined property derived. 6. If a redefining property is derived, and its redefined property is non-derived in the removed superclass, make the property non-derived (so it will have a slot). If a redefining property is non-derived, and its redefined property is derived in the removed superclass, keep the redefined property as non-derived as well as the non-derived redefining property. 7. Remove all properties that redefine a property with the same name in any remaining (non-matching) supertype. For example, remove the property raisedException from Operation, it redefines raisedException from BehavioralFeature. The inherited property is used instead, and a downcast is required for type tightening. 8. Make all properties that redefine and rename a property of any remaining (non-matching) supertype derived. They can be implemented by accessing the redefined property. For example, for Operation::formalParameter which redefines Basic::Operation::ownedParameter. 9. Fix package imports so only packages actually referenced are imported. 10. Create the enumeration VisibilityKind in Constructs (this will be merged in from Abstractions::Visibilities) 11. Operation: add inheritance from TypedElement and MultiplicityElement, to compensate for removal of inheritance from Basic::Operation (gets handled by adding superclasses of removed superclass to its subclasses) 12. Convert any unreferenced packages: packages that are not merged or imported either directly or indirectly by the target package being merged, to new capability packages. For example, packages Profiles and parts of Abstractions can be treated as separate capabilities since they are not directly referenced from Constructs after the merge and collapse. 13. Eliminate any situation where the same property was inherited from two superclasses, but didn't have a common superclass that defined the property. 14. For class Package, make the property ownedType non-derived. Package, Type, Constraint, ParameterableElement, GeneralizationSet, and InstanceSpecification are all PackageableElements. Package::ownedMember redefines Namespace::OwnedMember to refer to PackageableElements. Package::/ownedType subsets ownedMember to provide a convenient method for accessing the types in a package. This should be just treated as a derived property so that all the types in a package are owned members too. 15. Abstractions and Basic will have no references to them from Constructs since they have been collapsed away. These are candidates for removal. As I noted, more work needs to be done with this, but let's get the discussion going. Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com names that are the same.