Issue 7956: InfrastructureLibrary defines, but should not use package merge (uml2-rtf) Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: The resolution to 7623 said to replace all «import» by «merge» in Infrastructure Figure 70. These changes should be reversed because they result in InfrastructureLibrary both defining and being defined by package merge making it very difficult to implement UML2. Any implementation would have to do these merges by hand in order to have an implementation of Constructs that could be used to implement package merge, EMOF CMOF, or any other UML2 compliance level. Resolution: closed no change Revised Text: Add the following to the end of the first paragraph in section 10, just before Figure 64: Figure 64 illustrates the relationships between the Core packages and how they contribute to the origin and evolution of package Basic. Package Basic imports model elements from package PrimitiveTypes. Basic also contains metaclasses derived from shared metaclasses defined in packages contained in Abstractions. These shared metaclasses are included in Basic by copy. Add the following to the end of the paragraph just before figure 70. Figure 70 illustrates the relationships between the Core packages and how they contribute to the origin and evolution of package Constructs. Package Constructs imports model elements from package PrimitiveTypes. Constructs also contains metaclasses from Basic and shared metaclasses defined in packages contained in Abstractions. These shared metaclasses are included in Constructs by copy. Figure 70 uses PackageMerge to illustrate the packages that contribute to the definition of Constructs and how. The InfrastructureLibrary metamodel does not actually include these packages merges as Constructs is a complete metamodel that already includes all the metaclasses in the referenced packages. This allows Constructs to be understood and used without requiring the use of PackageMerge. Disposition: Resolved Actions taken: December 1, 2004: received issue August 23, 2006: closed issue Discussion: Before 7623, InfrastructureLibrary defined, but did not use package merge. Packages in Abstractions were only imported into Basic and Constructs. And because neither Basic nor Constructs actually referred to anything in Abstractions, these imports had no consequence one way or the other. They had no effect on the merge, and no effect on XMI and/or XSD generation for either MOF2 or UML2. However, changing them to merges, and modifying Constructs so a merge is required to make it complete changes things. In order to actually do the package merges resulting from 7623, and to generate the XMI and XSD for EMOF, CMOF, and all of the UML2 compliance levels, Abstractions must be cleaned up. That is, all of the extraneous superclasses have to be removed, the proper superclasses from dependent packages have to be added in order for all references to be resolved before the merge, and any other errors that may be in Abstractions will need to be corrected. The full extent of the required changes cannot be known until the merges are actually attempted. Both the Superstructure and MOF/Infra FTFs have agreed to defer Abstractions issues. Therefore, the resolution to issue 7623 should be amended so that Abstractions is not merged into Constructs, and therefore any issues resulting from these merges can be deferred. As a result, Abstractions will remain more decoupled from the rest of MOF2 and UML2 making it easier to address the deferred issues in an RTF. The "import"s that were in Figure 70 are not actually necessary. These are left over from the old definition of package merge which required the imports in order to make the imported metaclasses visible for subclassing by their corresponding merging classes. The new definition of package merge eliminates this subclassing and therefore the need to retain imports to merged packages. As a result, there are actually no dependencies between the Abstractions packages, Basic, and/or Constructs. However, it is still useful to indicate how Basic and Constructs were derived, and how they relate to Abstractions packages that contributed to their definition. This issue was resolved on a previous ballot. Changes are already in the Infra spec. Disposition: Closed, no change End of Annotations:===== ubject: InfrastructureLibrary defines, but should not use package merge X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Wed, 1 Dec 2004 15:06:50 -0500 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF678 | November 11, 2004) at 12/01/2004 13:06:51, Serialize complete at 12/01/2004 13:06:51 The resolution to 7623 said to replace all «import» by «merge» in Infrastructure Figure 70. These changes should be reversed because they result in InfrastructureLibrary both defining and being defined by package merge making it very difficult to implement UML2. Any implementation would have to do these merges by hand in order to have an implementation of Constructs that could be used to implement package merge, EMOF CMOF, or any other UML2 compliance level. Please post to the MOF/Infra FTF. Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Jan 2005 08:44:51 -0800 To: MOF UML Infrastructure FTF From: Joaquin Miller Subject: Re: [mu2i] Official Ballot 6 - VOTE NOW I apologize; i overlooked this until just now: "Constructs also contains metaclasses from Basic and shared metaclasses defined in packages contained in Abstractions. These shared metaclasses are included in Constructs by copy." [Proposed resolution to 7956] That is not crystal clear. How do the classes from Basic get into Constructs? The only classes called "shared" are the ones in Abstractions. Does the following change fix this, or do classes from Basic get over some other way? "Constructs also contains shared metaclasses from Basic and shared metaclasses defined in packages contained in Abstractions. These shared metaclasses are included in Constructs by copy." Should i post an issue on this? At 06:22 AM 1/7/2005, Pete Rivett wrote: Jim has updated this following comments on the draft and I'm sending it out for vote in his behalf. Note that votes are due by end Monday in order to try and get this all complete for the forthcoming meeting. Regards Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Jan 2005 08:55:31 -0800 To: MOF UML Infrastructure FTF From: Joaquin Miller Subject: a question for clarification I'm asking this for my own information, and so the answer will be in the archives. So i send it in a message separate from the previous. "As a result, there are actually no dependencies between the Abstractions packages, Basic, and/or Constructs." ... "Constructs also contains metaclasses from Basic and shared metaclasses defined in packages contained in Abstractions. These shared metaclasses are included in Constructs by copy." [Proposed resolution to 7956] Is it the case that the only connection between Basic and Constructs is that some class specifications from Basic were copied into Constructs by the authors of the specification? I'm sure we intend more than that; my question is whether it is the case that there is no formal connection between the two models, the only connection being that the two contain classes that happen to have the same name and structure. I don't know if the answer to this question has any practical consequences. We certainly need to nail down the models and finish the finalization process. I'm wondering, though, if this exposes some limitation in our specification, that makes it difficult or impossible to identify a certain class in Constructs with the class of the same name in Basic. Subject: RE: a question for clarification Date: Fri, 7 Jan 2005 12:31:20 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a question for clarification Thread-Index: AcT03B4Oa3xATJWlR4e8J2DuOy+SzAAAHh7A From: "Pete Rivett" To: "Joaquin Miller" , "MOF UML Infrastructure FTF" X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j07HLW1A024689 My answer to your previous question applies here also: from a specification point of view the packages are connected through package merge, and the semantics of package merge determines the copying that has taken place by hand: however if you look at the technical realization of the metamodels you will not see a package merge relationship there since the hand-copying is required for bootstrapping reasons - which Jim can explain better but in essence you cannot use an automated implementation of Package Merge to create the Constructs package which is where Package Merge is defined! So you should be able to look at Constructs and verify that it does indeed implement the package merge rules in copying the classes from Basic: it's not just a random set of copies or naming coincidences. This also means that should Basic change at a future revision, then we know exactly the resultant changes to Constructs - by again applying the semantics of the package merge rules. Hope that helps Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > Sent: Friday, January 07, 2005 4:56 PM > To: MOF UML Infrastructure FTF > Subject: a question for clarification > > I'm asking this for my own information, and so the answer > will be in the > archives. So i send it in a message separate from the previous. > > "As a result, there are actually no dependencies between the > Abstractions > packages, Basic, and/or Constructs." ... "Constructs also contains > metaclasses from Basic and shared metaclasses defined in > packages contained > in Abstractions. These shared metaclasses are included in > Constructs by > copy." [Proposed resolution to 7956] > > Is it the case that the only connection between Basic and > Constructs is > that some class specifications from Basic were copied into > Constructs by > the authors of the specification? > > I'm sure we intend more than that; my question is whether it > is the case > that there is no formal connection between the two models, the only > connection being that the two contain classes that happen to > have the same > name and structure. > > I don't know if the answer to this question has any practical > consequences. We certainly need to nail down the models and > finish the > finalization process. I'm wondering, though, if this exposes some > limitation in our specification, that makes it difficult or > impossible to > identify a certain class in Constructs with the class of the > same name in > Basic. > > > Subject: RE: a question for clarification Date: Fri, 7 Jan 2005 10:00:19 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a question for clarification Thread-Index: AcT03B4Oa3xATJWlR4e8J2DuOy+SzAAAHh7AAAEP8iA= From: "Karl Frank" To: "Pete Rivett" , "Joaquin Miller" , "MOF UML Infrastructure FTF" X-OriginalArrivalTime: 07 Jan 2005 18:00:02.0756 (UTC) FILETIME=[B610D840:01C4F4E2] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j07I8C1A029097 shouldn't the resolution of 7956 specify what the actual contents of the various infrastructure packages are as a consequence of the hand-execution of packageMerge, and use the enumeration of their actual resulting contents as the normative def of what is to be there? weakness is that (on my reading of 7956 aided by Pete's answers to Joaquin) the appearance of packageMerge in the syntax of Infrastructure is not removed, but the copying is to be done. As a result, it seems we will have two independent and normative specifications of the same part of the model, and it is therefore possible that the representation for bootstrapping, with the results of the hand copying operation, will differ from the result of an automated merge, coded on the basis of the rules of packageMerge, without regard to what the handexecuted result says it "ought" to be. the only way to exclude the possibility of future trouble is to explicitly specify the contents normatively in terms of one approach, not two, and of the two, an enumeration of the contents seems the safest. Karl Frank Principal Architect, Product Strategy & Architecture -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, January 07, 2005 12:31 PM To: Joaquin Miller; MOF UML Infrastructure FTF Subject: RE: a question for clarification My answer to your previous question applies here also: from a specification point of view the packages are connected through package merge, and the semantics of package merge determines the copying that has taken place by hand: however if you look at the technical realization of the metamodels you will not see a package merge relationship there since the hand-copying is required for bootstrapping reasons - which Jim can explain better but in essence you cannot use an automated implementation of Package Merge to create the Constructs package which is where Package Merge is defined! So you should be able to look at Constructs and verify that it does indeed implement the package merge rules in copying the classes from Basic: it's not just a random set of copies or naming coincidences. This also means that should Basic change at a future revision, then we know exactly the resultant changes to Constructs - by again applying the semantics of the package merge rules. Hope that helps Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > Sent: Friday, January 07, 2005 4:56 PM > To: MOF UML Infrastructure FTF > Subject: a question for clarification > > I'm asking this for my own information, and so the answer will be in > the archives. So i send it in a message separate from the previous. > > "As a result, there are actually no dependencies between the > Abstractions packages, Basic, and/or Constructs." ... "Constructs also > contains metaclasses from Basic and shared metaclasses defined in > packages contained in Abstractions. These shared metaclasses are > included in Constructs by copy." [Proposed resolution to 7956] > > Is it the case that the only connection between Basic and Constructs > is that some class specifications from Basic were copied into > Constructs by the authors of the specification? > > I'm sure we intend more than that; my question is whether it is the > case that there is no formal connection between the two models, the > only connection being that the two contain classes that happen to have > the same name and structure. > > I don't know if the answer to this question has any practical > consequences. We certainly need to nail down the models and finish > the finalization process. I'm wondering, though, if this exposes some > limitation in our specification, that makes it difficult or impossible > to identify a certain class in Constructs with the class of the same > name in Basic. > > > To: Joaquin Miller Cc: MOF UML Infrastructure FTF Subject: RE: a question for clarification X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Sat, 8 Jan 2005 09:15:37 -0500 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF678 | November 11, 2004) at 01/08/2005 07:15:38, Serialize complete at 01/08/2005 07:15:38 Joaquin, Here's and example of how Basic and Constructs differ in such a way that Basic could not be merged into Constructs. Basic defines Operation as a TypedElement (representing the return type of the operation) and a MultiplicityElement (indicating the return type might be multi-valued). This is a simple definition of Operation that is consistent with most programming languages. Constructs on the other hand defines Operation as as subclass of BehavioralFeature. Constructs::Opertation is neither a TypedElement or a MultiplicityElement. Instead its return type is provided in a parameter with ParameterDirectionKind return. Now in order to make Constructs consistent with Basic for XMI and interoperability purposes, Operation has derived properties /isOrdered, /isUnique, etc. corresponding to the properties it would have inheirted from MultiplicityElement. It also has an OCL <> operation called type (which should have been a derived property too) to determine the type of the operation from its return parameter. Basic could not be merged into Constructs without breaking Operation. There was an intentional redesign of how operations, parameters, and return types would be handled in Constructs that is different but compatible with Basic. Package merge cannot handle these differences. There are other examples, e.g., how packages handle their owned members. Joaquin Miller wrote on 01/07/2005 06:32:56 PM: > That does help, Pete; thanks. > > I do understand the bootstrap problem. > > And i begin to see that this does expose a limitation in our > technology. The only way we can identify two classes (declare that this is > only one class) is by import or merge. We can't, any other way, say that a > particular class in Basic is the same class as a particular class in > Constructs. That's because, in the absence of an import or merge, the fact > that they have different names means they are different classes. > > (I claim to understand the bootstrap problem. But maybe not. As i > understand it the problem arises because we want to use a tool to implement > the merge. It's unhappy to have to remove essential information from the > model to enable a tool. In the case of Smalltalk, for example, the tail > was eaten by hand, and then the original image passed around so that had to > be done only once. I guess the same might have happened in our case, if we > had made the starting model by hand and passed it around as XMI. But we > have chosen to make the starting model automatically, which requires > removing the information ("use an automated implementation of Package Merge > to create the Constructs"). > > X-Change Technologies has just voted yes. This is good enough for now. I > can't help but wonder if this failure to identify Basic classes with > Constructs classes might be avoided in MOF 3. > > (I'm taking the hard line: if they are not identified in the XMI, they are > not identical.) > > At 09:31 AM 1/7/2005, you wrote: > >My answer to your previous question applies here also: from a > >specification point of view the packages are connected through package > >merge, and the semantics of package merge determines the copying that > >has taken place by hand: however if you look at the technical > >realization of the metamodels you will not see a package merge > >relationship there since the hand-copying is required for bootstrapping > >reasons - which Jim can explain better but in essence you cannot use an > >automated implementation of Package Merge to create the Constructs > >package which is where Package Merge is defined! > > > >So you should be able to look at Constructs and verify that it does > >indeed implement the package merge rules in copying the classes from > >Basic: it's not just a random set of copies or naming coincidences. > >This also means that should Basic change at a future revision, then we > >know exactly the resultant changes to Constructs - by again applying the > >semantics of the package merge rules. > > > >Hope that helps > >Pete > > > > > >Pete Rivett (mailto:pete.rivett@adaptive.com) > >CTO, Adaptive Inc. > >Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > >Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > >http://www.adaptive.com > > > > > > > > > > > -----Original Message----- > > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > > Sent: Friday, January 07, 2005 4:56 PM > > > To: MOF UML Infrastructure FTF > > > Subject: a question for clarification > > > > > > I'm asking this for my own information, and so the answer > > > will be in the > > > archives. So i send it in a message separate from the previous. > > > > > > "As a result, there are actually no dependencies between the > > > Abstractions > > > packages, Basic, and/or Constructs." ... "Constructs also contains > > > metaclasses from Basic and shared metaclasses defined in > > > packages contained > > > in Abstractions. These shared metaclasses are included in > > > Constructs by > > > copy." [Proposed resolution to 7956] > > > > > > Is it the case that the only connection between Basic and > > > Constructs is > > > that some class specifications from Basic were copied into > > > Constructs by > > > the authors of the specification? > > > > > > I'm sure we intend more than that; my question is whether it > > > is the case > > > that there is no formal connection between the two models, the only > > > connection being that the two contain classes that happen to > > > have the same > > > name and structure. > > > > > > I don't know if the answer to this question has any practical > > > consequences. We certainly need to nail down the models and > > > finish the > > > finalization process. I'm wondering, though, if this exposes some > > > limitation in our specification, that makes it difficult or > > > impossible to > > > identify a certain class in Constructs with the class of the > > > same name in > > > Basic. > > > > > > > > > > > RE a question for clarificatio.gif Subject: RE: a question for clarification Date: Sat, 8 Jan 2005 10:33:04 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: a question for clarification Thread-Index: AcT1jxzmhUunVHchR6u2YLOklzKraQAA2EpQ From: "Pete Rivett" To: "Jim Amsden" , "Joaquin Miller" Cc: "MOF UML Infrastructure FTF" , "Branislav Selic" X-Virus-Scanned: by amavisd-new at sentraliant.com These inconsistencies sound like specific issues we should raise and address in the UML RTF. The 'intentional redesign' Jim refers to was to reconcile parameter/return type treatment between Kernel and Constructs and missed (to my awareness) the implications on relationship between Basic and Constructs. As others have noted in this thread, the connection between Constructs and Basic is significant. It was a feature (IMHO important) of the original Adopted specification and has never explicitly been abandoned. I'm concerned if people are able to interpret this newest resolution as implying that. In general, as far as I'm concerned, any inconsistency that means Constructs cannot be created by merging Basic (and adding other elements) is an Issue: what are the other examples you mention Jim? Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, January 08, 2005 2:16 PM To: Joaquin Miller Cc: MOF UML Infrastructure FTF Subject: RE: a question for clarification Joaquin, Here's and example of how Basic and Constructs differ in such a way that Basic could not be merged into Constructs. Basic defines Operation as a TypedElement (representing the return type of the operation) and a MultiplicityElement (indicating the return type might be multi-valued). This is a simple definition of Operation that is consistent with most programming languages. Constructs on the other hand defines Operation as as subclass of BehavioralFeature. Constructs::Opertation is neither a TypedElement or a MultiplicityElement. Instead its return type is provided in a parameter with ParameterDirectionKind return. Now in order to make Constructs consistent with Basic for XMI and interoperability purposes, Operation has derived properties /isOrdered, /isUnique, etc. corresponding to the properties it would have inheirted from MultiplicityElement. It also has an OCL <> operation called type (which should have been a derived property too) to determine the type of the operation from its return parameter. Basic could not be merged into Constructs without breaking Operation. There was an intentional redesign of how operations, parameters, and return types would be handled in Constructs that is different but compatible with Basic. Package merge cannot handle these differences. There are other examples, e.g., how packages handle their owned members. Joaquin Miller wrote on 01/07/2005 06:32:56 PM: > That does help, Pete; thanks. > > I do understand the bootstrap problem. > > And i begin to see that this does expose a limitation in our > technology. The only way we can identify two classes (declare that this is > only one class) is by import or merge. We can't, any other way, say that a > particular class in Basic is the same class as a particular class in > Constructs. That's because, in the absence of an import or merge, the fact > that they have different names means they are different classes. > > (I claim to understand the bootstrap problem. But maybe not. As i > understand it the problem arises because we want to use a tool to implement > the merge. It's unhappy to have to remove essential information from the > model to enable a tool. In the case of Smalltalk, for example, the tail > was eaten by hand, and then the original image passed around so that had to > be done only once. I guess the same might have happened in our case, if we > had made the starting model by hand and passed it around as XMI. But we > have chosen to make the starting model automatically, which requires > removing the information ("use an automated implementation of Package Merge > to create the Constructs"). > > X-Change Technologies has just voted yes. This is good enough for now. I > can't help but wonder if this failure to identify Basic classes with > Constructs classes might be avoided in MOF 3. > > (I'm taking the hard line: if they are not identified in the XMI, they are > not identical.) > > At 09:31 AM 1/7/2005, you wrote: > >My answer to your previous question applies here also: from a > >specification point of view the packages are connected through package > >merge, and the semantics of package merge determines the copying that > >has taken place by hand: however if you look at the technical > >realization of the metamodels you will not see a package merge > >relationship there since the hand-copying is required for bootstrapping > >reasons - which Jim can explain better but in essence you cannot use an > >automated implementation of Package Merge to create the Constructs > >package which is where Package Merge is defined! > > > >So you should be able to look at Constructs and verify that it does > >indeed implement the package merge rules in copying the classes from > >Basic: it's not just a random set of copies or naming coincidences. > >This also means that should Basic change at a future revision, then we > >know exactly the resultant changes to Constructs - by again applying the > >semantics of the package merge rules. > > > >Hope that helps > >Pete > > > > > >Pete Rivett (mailto:pete.rivett@adaptive.com) > >CTO, Adaptive Inc. > >Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > >Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > >http://www.adaptive.com > > > > > > > > > > > -----Original Message----- > > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > > Sent: Friday, January 07, 2005 4:56 PM > > > To: MOF UML Infrastructure FTF > > > Subject: a question for clarification > > > > > > I'm asking this for my own information, and so the answer > > > will be in the > > > archives. So i send it in a message separate from the previous. > > > > > > "As a result, there are actually no dependencies between the > > > Abstractions > > > packages, Basic, and/or Constructs." ... "Constructs also contains > > > metaclasses from Basic and shared metaclasses defined in > > > packages contained > > > in Abstractions. These shared metaclasses are included in > > > Constructs by > > > copy." [Proposed resolution to 7956] > > > > > > Is it the case that the only connection between Basic and > > > Constructs is > > > that some class specifications from Basic were copied into > > > Constructs by > > > the authors of the specification? > > > > > > I'm sure we intend more than that; my question is whether it > > > is the case > > > that there is no formal connection between the two models, the only > > > connection being that the two contain classes that happen to > > > have the same > > > name and structure. > > > > > > I don't know if the answer to this question has any practical > > > consequences. We certainly need to nail down the models and > > > finish the > > > finalization process. I'm wondering, though, if this exposes some > > > limitation in our specification, that makes it difficult or > > > impossible to > > > identify a certain class in Constructs with the class of the > > > same name in > > > Basic. > > > > > > > > > > > ATT603380.gif To: "Pete Rivett" Cc: "Branislav Selic" , "Joaquin Miller" , "MOF UML Infrastructure FTF" Subject: RE: a question for clarification X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Sat, 8 Jan 2005 11:42:53 -0500 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF678 | November 11, 2004) at 01/08/2005 09:42:55, Serialize complete at 01/08/2005 09:42:55 Pete, The Constructs metamodel does not contain inconsistencies with Basic, it just contains additional modeling capabilities that cannot be constructed from Basic using package merge. So the consistency, interoperability, and interchange between Basic and Constructs (not the other way around) is insured by how Constructs was developed, but didn't rely simply on package merge. It appears the developers of Constructs/CMOF felt package merge alone was too constraining. So there are no inconsistency or interoperability issues that I know of other than Operation needs a /type derived property. We may discover others as we generate the XMI and start attempting interchanges. But this is expected and can be handled in the next RTF. As to the relationship between Basic and Constructs, I don't really think it matters how they are interoperable, as long as they are. Using package merge only might have forced the models to be more similar. For example Operation might be a TypedElement and MultiplicityElement in both, and there would be no return ParameterDirectionKind. And using package merge might have reduced the need to maintain so many copies of the same metaclasses. But it wasn't done that way, and its too late to revisit this now. "Pete Rivett" 01/08/2005 10:33 AM To Jim Amsden/Raleigh/IBM@IBMUS, "Joaquin Miller" cc "MOF UML Infrastructure FTF" , "Branislav Selic" Subject RE: a question for clarification These inconsistencies sound like specific issues we should raise and address in the UML RTF. The 'intentional redesign' Jim refers to was to reconcile parameter/return type treatment between Kernel and Constructs and missed (to my awareness) the implications on relationship between Basic and Constructs. As others have noted in this thread, the connection between Constructs and Basic is significant. It was a feature (IMHO important) of the original Adopted specification and has never explicitly been abandoned. I'm concerned if people are able to interpret this newest resolution as implying that. In general, as far as I'm concerned, any inconsistency that means Constructs cannot be created by merging Basic (and adding other elements) is an Issue: what are the other examples you mention Jim? Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, January 08, 2005 2:16 PM To: Joaquin Miller Cc: MOF UML Infrastructure FTF Subject: RE: a question for clarification Joaquin, Here's and example of how Basic and Constructs differ in such a way that Basic could not be merged into Constructs. Basic defines Operation as a TypedElement (representing the return type of the operation) and a MultiplicityElement (indicating the return type might be multi-valued). This is a simple definition of Operation that is consistent with most programming languages. Constructs on the other hand defines Operation as as subclass of BehavioralFeature. Constructs::Opertation is neither a TypedElement or a MultiplicityElement. Instead its return type is provided in a parameter with ParameterDirectionKind return. Now in order to make Constructs consistent with Basic for XMI and interoperability purposes, Operation has derived properties /isOrdered, /isUnique, etc. corresponding to the properties it would have inheirted from MultiplicityElement. It also has an OCL <> operation called type (which should have been a derived property too) to determine the type of the operation from its return parameter. Basic could not be merged into Constructs without breaking Operation. There was an intentional redesign of how operations, parameters, and return types would be handled in Constructs that is different but compatible with Basic. Package merge cannot handle these differences. There are other examples, e.g., how packages handle their owned members. Joaquin Miller wrote on 01/07/2005 06:32:56 PM: > That does help, Pete; thanks. > > I do understand the bootstrap problem. > > And i begin to see that this does expose a limitation in our > technology. The only way we can identify two classes (declare that this is > only one class) is by import or merge. We can't, any other way, say that a > particular class in Basic is the same class as a particular class in > Constructs. That's because, in the absence of an import or merge, the fact > that they have different names means they are different classes. > > (I claim to understand the bootstrap problem. But maybe not. As i > understand it the problem arises because we want to use a tool to implement > the merge. It's unhappy to have to remove essential information from the > model to enable a tool. In the case of Smalltalk, for example, the tail > was eaten by hand, and then the original image passed around so that had to > be done only once. I guess the same might have happened in our case, if we > had made the starting model by hand and passed it around as XMI. But we > have chosen to make the starting model automatically, which requires > removing the information ("use an automated implementation of Package Merge > to create the Constructs"). > > X-Change Technologies has just voted yes. This is good enough for now. I > can't help but wonder if this failure to identify Basic classes with > Constructs classes might be avoided in MOF 3. > > (I'm taking the hard line: if they are not identified in the XMI, they are > not identical.) > > At 09:31 AM 1/7/2005, you wrote: > >My answer to your previous question applies here also: from a > >specification point of view the packages are connected through package > >merge, and the semantics of package merge determines the copying that > >has taken place by hand: however if you look at the technical > >realization of the metamodels you will not see a package merge > >relationship there since the hand-copying is required for bootstrapping > >reasons - which Jim can explain better but in essence you cannot use an > >automated implementation of Package Merge to create the Constructs > >package which is where Package Merge is defined! > > > >So you should be able to look at Constructs and verify that it does > >indeed implement the package merge rules in copying the classes from > >Basic: it's not just a random set of copies or naming coincidences. > >This also means that should Basic change at a future revision, then we > >know exactly the resultant changes to Constructs - by again applying the > >semantics of the package merge rules. > > > >Hope that helps > >Pete > > > > > >Pete Rivett (mailto:pete.rivett@adaptive.com) > >CTO, Adaptive Inc. > >Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > >Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > >http://www.adaptive.com > > > > > > > > > > > -----Original Message----- > > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > > Sent: Friday, January 07, 2005 4:56 PM > > > To: MOF UML Infrastructure FTF > > > Subject: a question for clarification > > > > > > I'm asking this for my own information, and so the answer > > > will be in the > > > archives. So i send it in a message separate from the previous. > > > > > > "As a result, there are actually no dependencies between the > > > Abstractions > > > packages, Basic, and/or Constructs." ... "Constructs also contains > > > metaclasses from Basic and shared metaclasses defined in > > > packages contained > > > in Abstractions. These shared metaclasses are included in > > > Constructs by > > > copy." [Proposed resolution to 7956] > > > > > > Is it the case that the only connection between Basic and > > > Constructs is > > > that some class specifications from Basic were copied into > > > Constructs by > > > the authors of the specification? > > > > > > I'm sure we intend more than that; my question is whether it > > > is the case > > > that there is no formal connection between the two models, the only > > > connection being that the two contain classes that happen to > > > have the same > > > name and structure. > > > > > > I don't know if the answer to this question has any practical > > > consequences. We certainly need to nail down the models and > > > finish the > > > finalization process. I'm wondering, though, if this exposes some > > > limitation in our specification, that makes it difficult or > > > impossible to > > > identify a certain class in Constructs with the class of the > > > same name in > > > Basic. > > > > > > > > > > > RE a question for clarificatio1.gif Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 08 Jan 2005 10:03:11 -0800 To: MOF UML Infrastructure FTF From: Joaquin Miller Subject: RE: a question for clarification Thanks, Jim. That's another reason for not using merge (or import), a quite different reason from the bootstrap problem. Maybe the RTF will choose to explain both reasons in the specification. (I don't propose the FTF delay to consider this.) It also, incidentally, points out a flaw in what i write below. We don't want to identify Basic Operation and Constructs Operation, because they are different objects (MOF speak), that is, different classes (UML speak). What i want to say, should have said, requires concepts that are not provided in the Infrastructure or MOF, since neither provides a theory of modeling. Basic Operation and Constructs Operation, though distinct, and different in structure, represent the same concept, operation. We have no way to say that. Certainly not an issue for the last days of this FTF. [It will be interesting to see how what i want to say can be said with QVT, and to consider what might be added to Infrastructure or to QVT to make this a standard capability.] Jim Amsden wrote: Joaquin, Here's an example of how Basic and Constructs differ in such a way that Basic could not be merged into Constructs. Basic defines Operation as a TypedElement (representing the return type of the operation) and a MultiplicityElement (indicating the return type might be multi-valued). This is a simple definition of Operation that is consistent with most programming languages. Constructs on the other hand defines Operation as as subclass of BehavioralFeature. Constructs::Opertation is neither a TypedElement or a MultiplicityElement. Instead its return type is provided in a parameter with ParameterDirectionKind return. Now in order to make Constructs consistent with Basic for XMI and interoperability purposes, Operation has derived properties /isOrdered, /isUnique, etc. corresponding to the properties it would have inheirted from MultiplicityElement. It also has an OCL <> operation called type (which should have been a derived property too) to determine the type of the operation from its return parameter. Basic could not be merged into Constructs without breaking Operation. There was an intentional redesign of how operations, parameters, and return types would be handled in Constructs that is different but compatible with Basic. Package merge cannot handle these differences. There are other examples, e.g., how packages handle their owned members. Joaquin Miller wrote on 01/07/2005 06:32:56 PM: > That does help, Pete; thanks. > > I do understand the bootstrap problem. > > And i begin to see that this does expose a limitation in our > technology. The only way we can identify two classes (declare that this is > only one class) is by import or merge. We can't, any other way, say that a > particular class in Basic is the same class as a particular class in > Constructs. That's because, in the absence of an import or merge, the fact > that they have different names means they are different classes. > > (I claim to understand the bootstrap problem. But maybe not. As i > understand it the problem arises because we want to use a tool to implement > the merge. It's unhappy to have to remove essential information from the > model to enable a tool. In the case of Smalltalk, for example, the tail > was eaten by hand, and then the original image passed around so that had to > be done only once. I guess the same might have happened in our case, if we > had made the starting model by hand and passed it around as XMI. But we > have chosen to make the starting model automatically, which requires > removing the information ("use an automated implementation of Package Merge > to create the Constructs"). > > X-Change Technologies has just voted yes. This is good enough for now. I > can't help but wonder if this failure to identify Basic classes with > Constructs classes might be avoided in MOF 3. > > (I'm taking the hard line: if they are not identified in the XMI, they are > not identical.) > > At 09:31 AM 1/7/2005, you wrote: > >My answer to your previous question applies here also: from a > >specification point of view the packages are connected through package > >merge, and the semantics of package merge determines the copying that > >has taken place by hand: however if you look at the technical > >realization of the metamodels you will not see a package merge > >relationship there since the hand-copying is required for bootstrapping > >reasons - which Jim can explain better but in essence you cannot use an > >automated implementation of Package Merge to create the Constructs > >package which is where Package Merge is defined! > > > >So you should be able to look at Constructs and verify that it does > >indeed implement the package merge rules in copying the classes from > >Basic: it's not just a random set of copies or naming coincidences. > >This also means that should Basic change at a future revision, then we > >know exactly the resultant changes to Constructs - by again applying the > >semantics of the package merge rules. > > > >Hope that helps > >Pete > > > > > >Pete Rivett (mailto:pete.rivett@adaptive.com) > >CTO, Adaptive Inc. > >Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > >Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > >http://www.adaptive.com > > > > > > > > > > > -----Original Message----- > > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > > Sent: Friday, January 07, 2005 4:56 PM > > > To: MOF UML Infrastructure FTF > > > Subject: a question for clarification > > > > > > I'm asking this for my own information, and so the answer > > > will be in the > > > archives. So i send it in a message separate from the previous. > > > > > > "As a result, there are actually no dependencies between the > > > Abstractions > > > packages, Basic, and/or Constructs." ... "Constructs also contains > > > metaclasses from Basic and shared metaclasses defined in > > > packages contained > > > in Abstractions. These shared metaclasses are included in > > > Constructs by > > > copy." [Proposed resolution to 7956] > > > > > > Is it the case that the only connection between Basic and > > > Constructs is > > > that some class specifications from Basic were copied into > > > Constructs by > > > the authors of the specification? > > > > > > I'm sure we intend more than that; my question is whether it > > > is the case > > > that there is no formal connection between the two models, the only > > > connection being that the two contain classes that happen to > > > have the same > > > name and structure. > > > > > > I don't know if the answer to this question has any practical > > > consequences. We certainly need to nail down the models and > > > finish the > > > finalization process. I'm wondering, though, if this exposes some > > > limitation in our specification, that makes it difficult or > > > impossible to > > > identify a certain class in Constructs with the class of the > > > same name in > > > Basic. > > > > > > > > > > > Subject: RE: a question for clarification Date: Sat, 8 Jan 2005 13:54:18 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: a question for clarification Thread-Index: AcT1o1G7qt0s/BseRF+bkhdsgFhNggADVTXA From: "Pete Rivett" To: "Jim Amsden" Cc: "Branislav Selic" , "Joaquin Miller" , "MOF UML Infrastructure FTF" X-Virus-Scanned: by amavisd-new at sentraliant.com Just to clarify: It's fine IMHO for Constructs to contain additional modeling aspects, which may use capabilities not available in Basic: however those aspects of the model which are contained in Basic should ideally all remain - as if they had been Merged in. Though it may work to have some explicit Redefinitions e.g. to redefine some properties as derived. I agree that this can be addressed in the RTF as I said in my first line. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, January 08, 2005 4:43 PM To: Pete Rivett Cc: Branislav Selic; Joaquin Miller; MOF UML Infrastructure FTF Subject: RE: a question for clarification Pete, The Constructs metamodel does not contain inconsistencies with Basic, it just contains additional modeling capabilities that cannot be constructed from Basic using package merge. So the consistency, interoperability, and interchange between Basic and Constructs (not the other way around) is insured by how Constructs was developed, but didn't rely simply on package merge. It appears the developers of Constructs/CMOF felt package merge alone was too constraining. So there are no inconsistency or interoperability issues that I know of other than Operation needs a /type derived property. We may discover others as we generate the XMI and start attempting interchanges. But this is expected and can be handled in the next RTF. As to the relationship between Basic and Constructs, I don't really think it matters how they are interoperable, as long as they are. Using package merge only might have forced the models to be more similar. For example Operation might be a TypedElement and MultiplicityElement in both, and there would be no return ParameterDirectionKind. And using package merge might have reduced the need to maintain so many copies of the same metaclasses. But it wasn't done that way, and its too late to revisit this now. "Pete Rivett" 01/08/2005 10:33 AM To Jim Amsden/Raleigh/IBM@IBMUS, "Joaquin Miller" cc "MOF UML Infrastructure FTF" , "Branislav Selic" Subject RE: a question for clarification These inconsistencies sound like specific issues we should raise and address in the UML RTF. The 'intentional redesign' Jim refers to was to reconcile parameter/return type treatment between Kernel and Constructs and missed (to my awareness) the implications on relationship between Basic and Constructs. As others have noted in this thread, the connection between Constructs and Basic is significant. It was a feature (IMHO important) of the original Adopted specification and has never explicitly been abandoned. I'm concerned if people are able to interpret this newest resolution as implying that. In general, as far as I'm concerned, any inconsistency that means Constructs cannot be created by merging Basic (and adding other elements) is an Issue: what are the other examples you mention Jim? Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, January 08, 2005 2:16 PM To: Joaquin Miller Cc: MOF UML Infrastructure FTF Subject: RE: a question for clarification Joaquin, Here's and example of how Basic and Constructs differ in such a way that Basic could not be merged into Constructs. Basic defines Operation as a TypedElement (representing the return type of the operation) and a MultiplicityElement (indicating the return type might be multi-valued). This is a simple definition of Operation that is consistent with most programming languages. Constructs on the other hand defines Operation as as subclass of BehavioralFeature. Constructs::Opertation is neither a TypedElement or a MultiplicityElement. Instead its return type is provided in a parameter with ParameterDirectionKind return. Now in order to make Constructs consistent with Basic for XMI and interoperability purposes, Operation has derived properties /isOrdered, /isUnique, etc. corresponding to the properties it would have inheirted from MultiplicityElement. It also has an OCL <> operation called type (which should have been a derived property too) to determine the type of the operation from its return parameter. Basic could not be merged into Constructs without breaking Operation. There was an intentional redesign of how operations, parameters, and return types would be handled in Constructs that is different but compatible with Basic. Package merge cannot handle these differences. There are other examples, e.g., how packages handle their owned members. Joaquin Miller wrote on 01/07/2005 06:32:56 PM: > That does help, Pete; thanks. > > I do understand the bootstrap problem. > > And i begin to see that this does expose a limitation in our > technology. The only way we can identify two classes (declare that this is > only one class) is by import or merge. We can't, any other way, say that a > particular class in Basic is the same class as a particular class in > Constructs. That's because, in the absence of an import or merge, the fact > that they have different names means they are different classes. > > (I claim to understand the bootstrap problem. But maybe not. As i > understand it the problem arises because we want to use a tool to implement > the merge. It's unhappy to have to remove essential information from the > model to enable a tool. In the case of Smalltalk, for example, the tail > was eaten by hand, and then the original image passed around so that had to > be done only once. I guess the same might have happened in our case, if we > had made the starting model by hand and passed it around as XMI. But we > have chosen to make the starting model automatically, which requires > removing the information ("use an automated implementation of Package Merge > to create the Constructs"). > > X-Change Technologies has just voted yes. This is good enough for now. I > can't help but wonder if this failure to identify Basic classes with > Constructs classes might be avoided in MOF 3. > > (I'm taking the hard line: if they are not identified in the XMI, they are > not identical.) > > At 09:31 AM 1/7/2005, you wrote: > >My answer to your previous question applies here also: from a > >specification point of view the packages are connected through package > >merge, and the semantics of package merge determines the copying that > >has taken place by hand: however if you look at the technical > >realization of the metamodels you will not see a package merge > >relationship there since the hand-copying is required for bootstrapping > >reasons - which Jim can explain better but in essence you cannot use an > >automated implementation of Package Merge to create the Constructs > >package which is where Package Merge is defined! > > > >So you should be able to look at Constructs and verify that it does > >indeed implement the package merge rules in copying the classes from > >Basic: it's not just a random set of copies or naming coincidences. > >This also means that should Basic change at a future revision, then we > >know exactly the resultant changes to Constructs - by again applying the > >semantics of the package merge rules. > > > >Hope that helps > >Pete > > > > > >Pete Rivett (mailto:pete.rivett@adaptive.com) > >CTO, Adaptive Inc. > >Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > >Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > >http://www.adaptive.com > > > > > > > > > > > -----Original Message----- > > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > > Sent: Friday, January 07, 2005 4:56 PM > > > To: MOF UML Infrastructure FTF > > > Subject: a question for clarification > > > > > > I'm asking this for my own information, and so the answer > > > will be in the > > > archives. So i send it in a message separate from the previous. > > > > > > "As a result, there are actually no dependencies between the > > > Abstractions > > > packages, Basic, and/or Constructs." ... "Constructs also contains > > > metaclasses from Basic and shared metaclasses defined in > > > packages contained > > > in Abstractions. These shared metaclasses are included in > > > Constructs by > > > copy." [Proposed resolution to 7956] > > > > > > Is it the case that the only connection between Basic and > > > Constructs is > > > that some class specifications from Basic were copied into > > > Constructs by > > > the authors of the specification? > > > > > > I'm sure we intend more than that; my question is whether it > > > is the case > > > that there is no formal connection between the two models, the only > > > connection being that the two contain classes that happen to > > > have the same > > > name and structure. > > > > > > I don't know if the answer to this question has any practical > > > consequences. We certainly need to nail down the models and > > > finish the > > > finalization process. I'm wondering, though, if this exposes some > > > limitation in our specification, that makes it difficult or > > > impossible to > > > identify a certain class in Constructs with the class of the > > > same name in > > > Basic. > > > > > > > > > > > ATT603382.gif Subject: RE: a question for clarification Date: Sat, 8 Jan 2005 14:16:54 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a question for clarification Thread-Index: AcT1E+I3rcLOmsbbTAq5teoBMPpBsAAn9IRg From: "Pete Rivett" To: "Joaquin Miller" , "MOF UML Infrastructure FTF" X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j08J6r1A026018 Joaquin, You said: > "I claim to understand the bootstrap problem. But maybe not. As i > understand it the problem arises because we want to use a > tool to implement > the merge. It's unhappy to have to remove essential > information from the > model to enable a tool. " I think this hits the nail on the head and I have had a disagreement with Jim on this. Personally I see no problem having the official normative XMI containing the merge: and then if the XMI generation tool cannot cope with its presence extend it into a tool chain that starts with a step (which could be simple XSL) to strip out what the tool cannot cope with. However this gives us the issue Jim has illustrated in a subsequent email - of inconsistencies between current Constructs and what one would get by doing a proper merge. Personally I think we could still reflect the merge in the model and then address the inconsistency issues. But that's not the proposed resolution. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > Sent: Friday, January 07, 2005 11:33 PM > To: MOF UML Infrastructure FTF > Subject: RE: a question for clarification > > That does help, Pete; thanks. > > I do understand the bootstrap problem. > > And i begin to see that this does expose a limitation in our > technology. The only way we can identify two classes > (declare that this is > only one class) is by import or merge. We can't, any other > way, say that a > particular class in Basic is the same class as a particular class in > Constructs. That's because, in the absence of an import or > merge, the fact > that they have different names means they are different classes. > > (I claim to understand the bootstrap problem. But maybe not. As i > understand it the problem arises because we want to use a > tool to implement > the merge. It's unhappy to have to remove essential > information from the > model to enable a tool. In the case of Smalltalk, for > example, the tail > was eaten by hand, and then the original image passed around > so that had to > be done only once. I guess the same might have happened in > our case, if we > had made the starting model by hand and passed it around as > XMI. But we > have chosen to make the starting model automatically, which requires > removing the information ("use an automated implementation of > Package Merge > to create the Constructs"). > > X-Change Technologies has just voted yes. This is good > enough for now. I > can't help but wonder if this failure to identify Basic classes with > Constructs classes might be avoided in MOF 3. > > (I'm taking the hard line: if they are not identified in the > XMI, they are > not identical.) > > At 09:31 AM 1/7/2005, you wrote: > >My answer to your previous question applies here also: from a > >specification point of view the packages are connected > through package > >merge, and the semantics of package merge determines the copying that > >has taken place by hand: however if you look at the technical > >realization of the metamodels you will not see a package merge > >relationship there since the hand-copying is required for > bootstrapping > >reasons - which Jim can explain better but in essence you > cannot use an > >automated implementation of Package Merge to create the Constructs > >package which is where Package Merge is defined! > > > >So you should be able to look at Constructs and verify that it does > >indeed implement the package merge rules in copying the classes from > >Basic: it's not just a random set of copies or naming coincidences. > >This also means that should Basic change at a future > revision, then we > >know exactly the resultant changes to Constructs - by again > applying the > >semantics of the package merge rules. > > > >Hope that helps > >Pete > > > > > >Pete Rivett (mailto:pete.rivett@adaptive.com) > >CTO, Adaptive Inc. > >Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > >Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > >http://www.adaptive.com > > > > > > > > > > > -----Original Message----- > > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > > Sent: Friday, January 07, 2005 4:56 PM > > > To: MOF UML Infrastructure FTF > > > Subject: a question for clarification > > > > > > I'm asking this for my own information, and so the answer > > > will be in the > > > archives. So i send it in a message separate from the previous. > > > > > > "As a result, there are actually no dependencies between the > > > Abstractions > > > packages, Basic, and/or Constructs." ... "Constructs also contains > > > metaclasses from Basic and shared metaclasses defined in > > > packages contained > > > in Abstractions. These shared metaclasses are included in > > > Constructs by > > > copy." [Proposed resolution to 7956] > > > > > > Is it the case that the only connection between Basic and > > > Constructs is > > > that some class specifications from Basic were copied into > > > Constructs by > > > the authors of the specification? > > > > > > I'm sure we intend more than that; my question is whether it > > > is the case > > > that there is no formal connection between the two > models, the only > > > connection being that the two contain classes that happen to > > > have the same > > > name and structure. > > > > > > I don't know if the answer to this question has any practical > > > consequences. We certainly need to nail down the models and > > > finish the > > > finalization process. I'm wondering, though, if this exposes some > > > limitation in our specification, that makes it difficult or > > > impossible to > > > identify a certain class in Constructs with the class of the > > > same name in > > > Basic. > > > > > > > > > > > > Subject: RE: a question for clarification Date: Sat, 8 Jan 2005 14:26:15 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a question for clarification Thread-Index: AcT03B4Oa3xATJWlR4e8J2DuOy+SzAAAHh7AAAEP8iAANPLt4A== From: "Pete Rivett" To: "Karl Frank" , "Joaquin Miller" , "MOF UML Infrastructure FTF" X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j08JGQ1A026076 Karl, I appreciate what (I think) you're getting it, but actually the thing that is missing from the spec is what Constructs looks like 'un-expanded' (e.g. what it adds to Basic and Abstractions). This is something I have suggested several times that Jim include in the resolution and have given up on for the FTF given the timescales. So we have no expression of what Constructs started out as prior to the expanded hand merge of Basic etc. As it stands the normative expression of Constructs is what is in the spec i.e. expanded-out so there is no issue of 2 possibly-conflicting normative expressions. We would have that issue to deal with if we had an un-expanded Constructs: however the situation is no different from having a normative metamodel XMI file and normative XML Schema (which is generated by a set of rules from the XMI). Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Friday, January 07, 2005 6:00 PM > To: Pete Rivett; Joaquin Miller; MOF UML Infrastructure FTF > Subject: RE: a question for clarification > > shouldn't the resolution of 7956 specify what the actual > contents of the > various infrastructure packages are as a consequence of the > hand-execution of packageMerge, and use the enumeration of > their actual > resulting contents as the normative def of what is to be there? > > weakness is that (on my reading of 7956 aided by Pete's answers to > Joaquin) the appearance of packageMerge in the syntax of > Infrastructure > is not removed, but the copying is to be done. As a result, > it seems we > will have two independent and normative specifications of the > same part > of the model, and it is therefore possible that the representation for > bootstrapping, with the results of the hand copying operation, will > differ from the result of an automated merge, coded on the > basis of the > rules of packageMerge, without regard to what the handexecuted result > says it "ought" to be. > > the only way to exclude the possibility of future trouble is to > explicitly specify the contents normatively in terms of one approach, > not two, and of the two, an enumeration of the contents seems the > safest. > > Karl Frank > Principal Architect, Product Strategy & Architecture > > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: Friday, January 07, 2005 12:31 PM > To: Joaquin Miller; MOF UML Infrastructure FTF > Subject: RE: a question for clarification > > My answer to your previous question applies here also: from a > specification point of view the packages are connected through package > merge, and the semantics of package merge determines the copying that > has taken place by hand: however if you look at the technical > realization of the metamodels you will not see a package merge > relationship there since the hand-copying is required for > bootstrapping > reasons - which Jim can explain better but in essence you > cannot use an > automated implementation of Package Merge to create the Constructs > package which is where Package Merge is defined! > > So you should be able to look at Constructs and verify that it does > indeed implement the package merge rules in copying the classes from > Basic: it's not just a random set of copies or naming coincidences. > This also means that should Basic change at a future revision, then we > know exactly the resultant changes to Constructs - by again > applying the > semantics of the package merge rules. > > Hope that helps > Pete > > > Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > http://www.adaptive.com > > > > > > > -----Original Message----- > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > Sent: Friday, January 07, 2005 4:56 PM > > To: MOF UML Infrastructure FTF > > Subject: a question for clarification > > > > I'm asking this for my own information, and so the answer > will be in > > the archives. So i send it in a message separate from the previous. > > > > "As a result, there are actually no dependencies between the > > Abstractions packages, Basic, and/or Constructs." ... > "Constructs also > > > contains metaclasses from Basic and shared metaclasses defined in > > packages contained in Abstractions. These shared metaclasses are > > included in Constructs by copy." [Proposed resolution to 7956] > > > > Is it the case that the only connection between Basic and > Constructs > > is that some class specifications from Basic were copied into > > Constructs by the authors of the specification? > > > > I'm sure we intend more than that; my question is whether it is the > > case that there is no formal connection between the two models, the > > only connection being that the two contain classes that > happen to have > > > the same name and structure. > > > > I don't know if the answer to this question has any practical > > consequences. We certainly need to nail down the models and finish > > the finalization process. I'm wondering, though, if this > exposes some > > > limitation in our specification, that makes it difficult or > impossible > > > to identify a certain class in Constructs with the class of > the same > > name in Basic. > > > > > > > > > Subject: RE: a question for clarification Date: Sat, 8 Jan 2005 14:38:05 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a question for clarification Thread-Index: AcT09dFbPUVci8xaQOOG7+uYn8dt0gAwBTjg From: "Pete Rivett" To: "Jim Amsden" , "Karl Frank" Cc: "Joaquin Miller" , "MOF UML Infrastructure FTF" X-Virus-Scanned: by amavisd-new at sentraliant.com Basic and Constructs were never intended to be independent and standalone. Though Constructs was completed before Package Merge, it was originally defined with heavy inheritance from Basic: this connectivity/re-use was meant to be replaced by the use of package Merge: IMHO the intention was never that the use of Package Merge would end up with them completely independent. I think we want to end up with them formally connected - so that any changes in Basic at a new version are properly reflected in Constructs - so that the Package Merge is more than just historical even if it's not reflected in the metamodel XMI. Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, January 07, 2005 8:01 PM To: Karl Frank Cc: Joaquin Miller; MOF UML Infrastructure FTF; Pete Rivett Subject: RE: a question for clarification This is the very problem I wanted to avoid by keeping package merge out of Basic and Constructs altogether. The fact is Basic and Constructs are what they are in the spec, regardless of how they were produced. Constructs was not actually produced by "hand-merging" Abstractions and Basic. It couldn't have been because Constructs was mostly completed before packckage merge was defined - it had to be because package merge required Constructs. Constructs was just developed based on Abstractions and Basic (which were also changing all the time) primiarily through copy and paste. It is possible that merging Abstractions and Basic with Constructs would produce no change in Constructs (it shouldn't) but that has not been verified. And even if such a merge did produced something different, it wouldn't matter anyway. Constructs is fully defined in the spec as what it is. This package merge discussion and its inclusion in the spec is for historical and explanatory purposes only. "Karl Frank" 01/07/2005 01:00 PM To "Pete Rivett" , "Joaquin Miller" , "MOF UML Infrastructure FTF" cc Subject RE: a question for clarification shouldn't the resolution of 7956 specify what the actual contents of the various infrastructure packages are as a consequence of the hand-execution of packageMerge, and use the enumeration of their actual resulting contents as the normative def of what is to be there? weakness is that (on my reading of 7956 aided by Pete's answers to Joaquin) the appearance of packageMerge in the syntax of Infrastructure is not removed, but the copying is to be done. As a result, it seems we will have two independent and normative specifications of the same part of the model, and it is therefore possible that the representation for bootstrapping, with the results of the hand copying operation, will differ from the result of an automated merge, coded on the basis of the rules of packageMerge, without regard to what the handexecuted result says it "ought" to be. the only way to exclude the possibility of future trouble is to explicitly specify the contents normatively in terms of one approach, not two, and of the two, an enumeration of the contents seems the safest. Karl Frank Principal Architect, Product Strategy & Architecture -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, January 07, 2005 12:31 PM To: Joaquin Miller; MOF UML Infrastructure FTF Subject: RE: a question for clarification My answer to your previous question applies here also: from a specification point of view the packages are connected through package merge, and the semantics of package merge determines the copying that has taken place by hand: however if you look at the technical realization of the metamodels you will not see a package merge relationship there since the hand-copying is required for bootstrapping reasons - which Jim can explain better but in essence you cannot use an automated implementation of Package Merge to create the Constructs package which is where Package Merge is defined! So you should be able to look at Constructs and verify that it does indeed implement the package merge rules in copying the classes from Basic: it's not just a random set of copies or naming coincidences. This also means that should Basic change at a future revision, then we know exactly the resultant changes to Constructs - by again applying the semantics of the package merge rules. Hope that helps Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > Sent: Friday, January 07, 2005 4:56 PM > To: MOF UML Infrastructure FTF > Subject: a question for clarification > > I'm asking this for my own information, and so the answer will be in > the archives. So i send it in a message separate from the previous. > > "As a result, there are actually no dependencies between the > Abstractions packages, Basic, and/or Constructs." ... "Constructs also > contains metaclasses from Basic and shared metaclasses defined in > packages contained in Abstractions. These shared metaclasses are > included in Constructs by copy." [Proposed resolution to 7956] > > Is it the case that the only connection between Basic and Constructs > is that some class specifications from Basic were copied into > Constructs by the authors of the specification? > > I'm sure we intend more than that; my question is whether it is the > case that there is no formal connection between the two models, the > only connection being that the two contain classes that happen to have > the same name and structure. > > I don't know if the answer to this question has any practical > consequences. We certainly need to nail down the models and finish > the finalization process. I'm wondering, though, if this exposes some > limitation in our specification, that makes it difficult or impossible > to identify a certain class in Constructs with the class of the same > name in Basic. > > > Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 08 Jan 2005 11:41:55 -0800 To: MOF UML Infrastructure FTF From: Joaquin Miller Subject: two classes are the same; one class is a copy of the other Jim Amsden wrote: "... many copies of the same metaclasses." To help nail down one (or maybe the other) of the two concepts my recent messages have been about: There is no way we can say using constructs of Infrastructure or MOF that a each of several certain classes is a copy of the same class. (I'm following William Frank's style: Make a flat statement. If someone shows what is wrong with it, that's good progress.) Subject: RE: a question for clarification Date: Sat, 8 Jan 2005 19:16:50 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a question for clarification Thread-Index: AcT03B4Oa3xATJWlR4e8J2DuOy+SzAAAHh7AAAEP8iAANPLt4AARL6UA From: "Karl Frank" To: "Pete Rivett" , "Joaquin Miller" , "MOF UML Infrastructure FTF" X-OriginalArrivalTime: 09 Jan 2005 03:16:52.0198 (UTC) FILETIME=[AA0EE060:01C4F5F9] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j093P31A028187 Pete: Your preferred resolution turns mine right-side out. You make a good case for having the spec show clearly only the unexpanded view of constructs (or any other) merging package. That way, revisions made later to the merged package will be understood to propagate without having to rewrite the spec for the merging package. My goal in wanting to handle this the other way round was short term user convenience. users of the spec should not have figure out package merge rules and execute the merge (whether by hand or otherwise) and then debate with others who got it right to see what is in an infrastructure package. I see that this short-term convenience approach is inconsistent with the accepted role of packagemerge in the incremental construction of UML as per the superstructure. I would back your proposal. Karl Frank Product Strategy & Architecture Borland Software Corp. -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Saturday, January 08, 2005 2:26 PM To: Karl Frank; Joaquin Miller; MOF UML Infrastructure FTF Subject: RE: a question for clarification Karl, I appreciate what (I think) you're getting it, but actually the thing that is missing from the spec is what Constructs looks like 'un-expanded' (e.g. what it adds to Basic and Abstractions). This is something I have suggested several times that Jim include in the resolution and have given up on for the FTF given the timescales. So we have no expression of what Constructs started out as prior to the expanded hand merge of Basic etc. As it stands the normative expression of Constructs is what is in the spec i.e. expanded-out so there is no issue of 2 possibly-conflicting normative expressions. We would have that issue to deal with if we had an un-expanded Constructs: however the situation is no different from having a normative metamodel XMI file and normative XML Schema (which is generated by a set of rules from the XMI). Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Friday, January 07, 2005 6:00 PM > To: Pete Rivett; Joaquin Miller; MOF UML Infrastructure FTF > Subject: RE: a question for clarification > > shouldn't the resolution of 7956 specify what the actual contents of > the various infrastructure packages are as a consequence of the > hand-execution of packageMerge, and use the enumeration of their > actual resulting contents as the normative def of what is to be there? > > weakness is that (on my reading of 7956 aided by Pete's answers to > Joaquin) the appearance of packageMerge in the syntax of > Infrastructure is not removed, but the copying is to be done. As a > result, it seems we will have two independent and normative > specifications of the same part of the model, and it is therefore > possible that the representation for bootstrapping, with the results > of the hand copying operation, will differ from the result of an > automated merge, coded on the basis of the rules of packageMerge, > without regard to what the handexecuted result says it "ought" to be. > > the only way to exclude the possibility of future trouble is to > explicitly specify the contents normatively in terms of one approach, > not two, and of the two, an enumeration of the contents seems the > safest. > > Karl Frank > Principal Architect, Product Strategy & Architecture > > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: Friday, January 07, 2005 12:31 PM > To: Joaquin Miller; MOF UML Infrastructure FTF > Subject: RE: a question for clarification > > My answer to your previous question applies here also: from a > specification point of view the packages are connected through package > merge, and the semantics of package merge determines the copying that > has taken place by hand: however if you look at the technical > realization of the metamodels you will not see a package merge > relationship there since the hand-copying is required for > bootstrapping reasons - which Jim can explain better but in essence > you cannot use an automated implementation of Package Merge to create > the Constructs package which is where Package Merge is defined! > > So you should be able to look at Constructs and verify that it does > indeed implement the package merge rules in copying the classes from > Basic: it's not just a random set of copies or naming coincidences. > This also means that should Basic change at a future revision, then we > know exactly the resultant changes to Constructs - by again applying > the semantics of the package merge rules. > > Hope that helps > Pete > > > Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > http://www.adaptive.com > > > > > > > -----Original Message----- > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > Sent: Friday, January 07, 2005 4:56 PM > > To: MOF UML Infrastructure FTF > > Subject: a question for clarification > > > > I'm asking this for my own information, and so the answer > will be in > > the archives. So i send it in a message separate from the previous. > > > > "As a result, there are actually no dependencies between the > > Abstractions packages, Basic, and/or Constructs." ... > "Constructs also > > > contains metaclasses from Basic and shared metaclasses defined in > > packages contained in Abstractions. These shared metaclasses are > > included in Constructs by copy." [Proposed resolution to 7956] > > > > Is it the case that the only connection between Basic and > Constructs > > is that some class specifications from Basic were copied into > > Constructs by the authors of the specification? > > > > I'm sure we intend more than that; my question is whether it is the > > case that there is no formal connection between the two models, the > > only connection being that the two contain classes that > happen to have > > > the same name and structure. > > > > I don't know if the answer to this question has any practical > > consequences. We certainly need to nail down the models and finish > > the finalization process. I'm wondering, though, if this > exposes some > > > limitation in our specification, that makes it difficult or > impossible > > > to identify a certain class in Constructs with the class of > the same > > name in Basic. > > > > > > > > > Subject: RE: a question for clarification Date: Sun, 9 Jan 2005 06:54:28 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a question for clarification Thread-Index: AcT03B4Oa3xATJWlR4e8J2DuOy+SzAAAHh7AAAEP8iAANPLt4AARL6UAABFCL8A= From: "Pete Rivett" To: "Karl Frank" , "Joaquin Miller" , "MOF UML Infrastructure FTF" X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j09BkC1A002359 > My goal in wanting to handle this the other way round was short term > user convenience. users of the spec should not have figure > out package > merge rules and execute the merge (whether by hand or otherwise) and > then debate with others who got it right to see what is in an > infrastructure package. My proposal was actually not to remove the expended version but to supplement it with the un-expanded version and clearly explain how the expanded version is derived (whether automated or not). The convenience of the expanded version need not necessarily be short-term: I can see a longer-term need for the expanded version also - especially as in general (for the bootstrapping reasons) the expansion may not be automated. And it will take a while for people to 'internalize' the package merge rules in the same way they already have for class inheritance (where we no longer need to show the subclasses expanded with all inherited superclass properties). I don't see it being a major issue to have both versions in the spec - it's up to us to make sure they are consistent: I gave the example of where we have a similar situation with XML Schema for UML where we have a normative Schema (equivalent of the expanded version) and a normative XMI for the metamodel (equivalent of the unexpanded version): in this case the expansion rules are the XMI generation rules. With respect to the current ballot the key questions I think are: - is the proposed resolution sufficiently clear on how things are derived? - are we happy to postpone creating the unexpanded versions of Constructs (and Basic though that's trivial)? Regards Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Sunday, January 09, 2005 3:17 AM > To: Pete Rivett; Joaquin Miller; MOF UML Infrastructure FTF > Subject: RE: a question for clarification > > Pete: > > Your preferred resolution turns mine right-side out. > > You make a good case for having the spec show clearly only the > unexpanded view of constructs (or any other) merging package. > That way, > revisions made later to the merged package will be understood to > propagate without having to rewrite the spec for the merging > package. > > My goal in wanting to handle this the other way round was short term > user convenience. users of the spec should not have figure > out package > merge rules and execute the merge (whether by hand or otherwise) and > then debate with others who got it right to see what is in an > infrastructure package. > > I see that this short-term convenience approach is > inconsistent with the > accepted role of packagemerge in the incremental construction > of UML as > per the superstructure. I would back your proposal. > > Karl Frank > Product Strategy & Architecture > Borland Software Corp. > > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: Saturday, January 08, 2005 2:26 PM > To: Karl Frank; Joaquin Miller; MOF UML Infrastructure FTF > Subject: RE: a question for clarification > > Karl, > I appreciate what (I think) you're getting it, but actually the thing > that is missing from the spec is what Constructs looks like > 'un-expanded' (e.g. what it adds to Basic and Abstractions). This is > something I have suggested several times that Jim include in the > resolution and have given up on for the FTF given the timescales. > So we have no expression of what Constructs started out as > prior to the > expanded hand merge of Basic etc. > > As it stands the normative expression of Constructs is what is in the > spec i.e. expanded-out so there is no issue of 2 possibly-conflicting > normative expressions. > We would have that issue to deal with if we had an un-expanded > Constructs: however the situation is no different from having a > normative metamodel XMI file and normative XML Schema (which is > generated by a set of rules from the XMI). > > Pete > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > http://www.adaptive.com > > > > > > > -----Original Message----- > > From: Karl Frank [mailto:Karl.Frank@borland.com] > > Sent: Friday, January 07, 2005 6:00 PM > > To: Pete Rivett; Joaquin Miller; MOF UML Infrastructure FTF > > Subject: RE: a question for clarification > > > > shouldn't the resolution of 7956 specify what the actual > contents of > > the various infrastructure packages are as a consequence of the > > hand-execution of packageMerge, and use the enumeration of their > > actual resulting contents as the normative def of what is > to be there? > > > > weakness is that (on my reading of 7956 aided by Pete's answers to > > Joaquin) the appearance of packageMerge in the syntax of > > Infrastructure is not removed, but the copying is to be done. As a > > result, it seems we will have two independent and normative > > specifications of the same part of the model, and it is therefore > > possible that the representation for bootstrapping, with > the results > > of the hand copying operation, will differ from the result of an > > automated merge, coded on the basis of the rules of packageMerge, > > without regard to what the handexecuted result says it > "ought" to be. > > > > the only way to exclude the possibility of future trouble is to > > explicitly specify the contents normatively in terms of one > approach, > > not two, and of the two, an enumeration of the contents seems the > > safest. > > > > Karl Frank > > Principal Architect, Product Strategy & Architecture > > > > -----Original Message----- > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > Sent: Friday, January 07, 2005 12:31 PM > > To: Joaquin Miller; MOF UML Infrastructure FTF > > Subject: RE: a question for clarification > > > > My answer to your previous question applies here also: from a > > specification point of view the packages are connected > through package > > > merge, and the semantics of package merge determines the > copying that > > has taken place by hand: however if you look at the technical > > realization of the metamodels you will not see a package merge > > relationship there since the hand-copying is required for > > bootstrapping reasons - which Jim can explain better but in essence > > you cannot use an automated implementation of Package Merge > to create > > the Constructs package which is where Package Merge is defined! > > > > So you should be able to look at Constructs and verify that it does > > indeed implement the package merge rules in copying the classes from > > Basic: it's not just a random set of copies or naming coincidences. > > This also means that should Basic change at a future > revision, then we > > > know exactly the resultant changes to Constructs - by again > applying > > the semantics of the package merge rules. > > > > Hope that helps > > Pete > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > http://www.adaptive.com > > > > > > > > > > > > > -----Original Message----- > > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > > Sent: Friday, January 07, 2005 4:56 PM > > > To: MOF UML Infrastructure FTF > > > Subject: a question for clarification > > > > > > I'm asking this for my own information, and so the answer > > will be in > > > the archives. So i send it in a message separate from > the previous. > > > > > > "As a result, there are actually no dependencies between the > > > Abstractions packages, Basic, and/or Constructs." ... > > "Constructs also > > > > > contains metaclasses from Basic and shared metaclasses defined in > > > packages contained in Abstractions. These shared metaclasses are > > > included in Constructs by copy." [Proposed resolution to 7956] > > > > > > Is it the case that the only connection between Basic and > > Constructs > > > is that some class specifications from Basic were copied into > > > Constructs by the authors of the specification? > > > > > > I'm sure we intend more than that; my question is whether > it is the > > > case that there is no formal connection between the two > models, the > > > only connection being that the two contain classes that > > happen to have > > > > > the same name and structure. > > > > > > I don't know if the answer to this question has any practical > > > consequences. We certainly need to nail down the models > and finish > > > the finalization process. I'm wondering, though, if this > > exposes some > > > > > limitation in our specification, that makes it difficult or > > impossible > > > > > to identify a certain class in Constructs with the class of > > the same > > > name in Basic. > > > > > > > > > > > > > > > > > > To: "Pete Rivett" Cc: "Joaquin Miller" , "Karl Frank" , "MOF UML Infrastructure FTF" Subject: RE: a question for clarification X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Sun, 9 Jan 2005 09:01:24 -0500 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF678 | November 11, 2004) at 01/09/2005 07:01:26, Serialize complete at 01/09/2005 07:01:26 With respect to the current ballot the key questions I think are: - is the proposed resolution sufficiently clear on how things are derived? Probably not, but its much more important at this point to understand what Constructs is and start using it than it is to understand how it was derived. - are we happy to postpone creating the unexpanded versions of Constructs (and Basic though that's trivial)? Absolutely. A list of new capabilities added would be sufficient: Visibility Generalization of datatypes (not classes) Operation exceptions Associations with more than 2 member ends Datatypes with attributes and operations Element Imports Importing into namespaces other than packages Visibility of imports Parameter default values Operation pre and post-conditions Package import Property redefinition Derived supersets Package merge Constraints "Pete Rivett" wrote on 01/09/2005 06:54:28 AM: > > My goal in wanting to handle this the other way round was short term > > user convenience. users of the spec should not have figure > > out package > > merge rules and execute the merge (whether by hand or otherwise) and > > then debate with others who got it right to see what is in an > > infrastructure package. > > My proposal was actually not to remove the expended version but to > supplement it with the un-expanded version and clearly explain how the > expanded version is derived (whether automated or not). > > The convenience of the expanded version need not necessarily be > short-term: I can see a longer-term need for the expanded version also - > especially as in general (for the bootstrapping reasons) the expansion > may not be automated. And it will take a while for people to > 'internalize' the package merge rules in the same way they already have > for class inheritance (where we no longer need to show the subclasses > expanded with all inherited superclass properties). > > I don't see it being a major issue to have both versions in the spec - > it's up to us to make sure they are consistent: I gave the example of > where we have a similar situation with XML Schema for UML where we have > a normative Schema (equivalent of the expanded version) and a normative > XMI for the metamodel (equivalent of the unexpanded version): in this > case the expansion rules are the XMI generation rules. > > With respect to the current ballot the key questions I think are: > - is the proposed resolution sufficiently clear on how things are > derived? > - are we happy to postpone creating the unexpanded versions of > Constructs (and Basic though that's trivial)? > > Regards > Pete > > Pete Rivett (mailto:pete.rivett@adaptive.com) > CTO, Adaptive Inc. > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > http://www.adaptive.com > > > > > > -----Original Message----- > > From: Karl Frank [mailto:Karl.Frank@borland.com] > > Sent: Sunday, January 09, 2005 3:17 AM > > To: Pete Rivett; Joaquin Miller; MOF UML Infrastructure FTF > > Subject: RE: a question for clarification > > > > Pete: > > > > Your preferred resolution turns mine right-side out. > > > > You make a good case for having the spec show clearly only the > > unexpanded view of constructs (or any other) merging package. > > That way, > > revisions made later to the merged package will be understood to > > propagate without having to rewrite the spec for the merging > > package. > > > > My goal in wanting to handle this the other way round was short term > > user convenience. users of the spec should not have figure > > out package > > merge rules and execute the merge (whether by hand or otherwise) and > > then debate with others who got it right to see what is in an > > infrastructure package. > > > > I see that this short-term convenience approach is > > inconsistent with the > > accepted role of packagemerge in the incremental construction > > of UML as > > per the superstructure. I would back your proposal. > > > > Karl Frank > > Product Strategy & Architecture > > Borland Software Corp. > > > > -----Original Message----- > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > Sent: Saturday, January 08, 2005 2:26 PM > > To: Karl Frank; Joaquin Miller; MOF UML Infrastructure FTF > > Subject: RE: a question for clarification > > > > Karl, > > I appreciate what (I think) you're getting it, but actually the thing > > that is missing from the spec is what Constructs looks like > > 'un-expanded' (e.g. what it adds to Basic and Abstractions). This is > > something I have suggested several times that Jim include in the > > resolution and have given up on for the FTF given the timescales. > > So we have no expression of what Constructs started out as > > prior to the > > expanded hand merge of Basic etc. > > > > As it stands the normative expression of Constructs is what is in the > > spec i.e. expanded-out so there is no issue of 2 possibly-conflicting > > normative expressions. > > We would have that issue to deal with if we had an un-expanded > > Constructs: however the situation is no different from having a > > normative metamodel XMI file and normative XML Schema (which is > > generated by a set of rules from the XMI). > > > > Pete > > > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > http://www.adaptive.com > > > > > > > > > > > > > -----Original Message----- > > > From: Karl Frank [mailto:Karl.Frank@borland.com] > > > Sent: Friday, January 07, 2005 6:00 PM > > > To: Pete Rivett; Joaquin Miller; MOF UML Infrastructure FTF > > > Subject: RE: a question for clarification > > > > > > shouldn't the resolution of 7956 specify what the actual > > contents of > > > the various infrastructure packages are as a consequence of the > > > hand-execution of packageMerge, and use the enumeration of their > > > actual resulting contents as the normative def of what is > > to be there? > > > > > > weakness is that (on my reading of 7956 aided by Pete's answers to > > > Joaquin) the appearance of packageMerge in the syntax of > > > Infrastructure is not removed, but the copying is to be done. As a > > > result, it seems we will have two independent and normative > > > specifications of the same part of the model, and it is therefore > > > possible that the representation for bootstrapping, with > > the results > > > of the hand copying operation, will differ from the result of an > > > automated merge, coded on the basis of the rules of packageMerge, > > > without regard to what the handexecuted result says it > > "ought" to be. > > > > > > the only way to exclude the possibility of future trouble is to > > > explicitly specify the contents normatively in terms of one > > approach, > > > not two, and of the two, an enumeration of the contents seems the > > > safest. > > > > > > Karl Frank > > > Principal Architect, Product Strategy & Architecture > > > > > > -----Original Message----- > > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > > Sent: Friday, January 07, 2005 12:31 PM > > > To: Joaquin Miller; MOF UML Infrastructure FTF > > > Subject: RE: a question for clarification > > > > > > My answer to your previous question applies here also: from a > > > specification point of view the packages are connected > > through package > > > > > merge, and the semantics of package merge determines the > > copying that > > > has taken place by hand: however if you look at the technical > > > realization of the metamodels you will not see a package merge > > > relationship there since the hand-copying is required for > > > bootstrapping reasons - which Jim can explain better but in essence > > > you cannot use an automated implementation of Package Merge > > to create > > > the Constructs package which is where Package Merge is defined! > > > > > > So you should be able to look at Constructs and verify that it does > > > indeed implement the package merge rules in copying the classes from > > > Basic: it's not just a random set of copies or naming coincidences. > > > This also means that should Basic change at a future > > revision, then we > > > > > know exactly the resultant changes to Constructs - by again > > applying > > > the semantics of the package merge rules. > > > > > > Hope that helps > > > Pete > > > > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. > > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > > http://www.adaptive.com > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > > > > Sent: Friday, January 07, 2005 4:56 PM > > > > To: MOF UML Infrastructure FTF > > > > Subject: a question for clarification > > > > > > > > I'm asking this for my own information, and so the answer > > > will be in > > > > the archives. So i send it in a message separate from > > the previous. > > > > > > > > "As a result, there are actually no dependencies between the > > > > Abstractions packages, Basic, and/or Constructs." ... > > > "Constructs also > > > > > > > contains metaclasses from Basic and shared metaclasses defined in > > > > packages contained in Abstractions. These shared metaclasses are > > > > included in Constructs by copy." [Proposed resolution to 7956] > > > > > > > > Is it the case that the only connection between Basic and > > > Constructs > > > > is that some class specifications from Basic were copied into > > > > Constructs by the authors of the specification? > > > > > > > > I'm sure we intend more than that; my question is whether > > it is the > > > > case that there is no formal connection between the two > > models, the > > > > only connection being that the two contain classes that > > > happen to have > > > > > > > the same name and structure. > > > > > > > > I don't know if the answer to this question has any practical > > > > consequences. We certainly need to nail down the models > > and finish > > > > the finalization process. I'm wondering, though, if this > > > exposes some > > > > > > > limitation in our specification, that makes it difficult or > > > impossible > > > > > > > to identify a certain class in Constructs with the class of > > > the same > > > > name in Basic. > > > > > > > > > > > > > > > > > > > > > > > > > > > To: "Karl Frank" Cc: "Joaquin Miller" , "MOF UML Infrastructure FTF" , "Pete Rivett" Subject: RE: a question for clarification X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Fri, 7 Jan 2005 15:00:49 -0500 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF678 | November 11, 2004) at 01/07/2005 13:00:50, Serialize complete at 01/07/2005 13:00:50 This is the very problem I wanted to avoid by keeping package merge out of Basic and Constructs altogether. The fact is Basic and Constructs are what they are in the spec, regardless of how they were produced. Constructs was not actually produced by "hand-merging" Abstractions and Basic. It couldn't have been because Constructs was mostly completed before packckage merge was defined - it had to be because package merge required Constructs. Constructs was just developed based on Abstractions and Basic (which were also changing all the time) primiarily through copy and paste. It is possible that merging Abstractions and Basic with Constructs would produce no change in Constructs (it shouldn't) but that has not been verified. And even if such a merge did produced something different, it wouldn't matter anyway. Constructs is fully defined in the spec as what it is. This package merge discussion and its inclusion in the spec is for historical and explanatory purposes only. "Karl Frank" 01/07/2005 01:00 PM To "Pete Rivett" , "Joaquin Miller" , "MOF UML Infrastructure FTF" cc Subject RE: a question for clarification shouldn't the resolution of 7956 specify what the actual contents of the various infrastructure packages are as a consequence of the hand-execution of packageMerge, and use the enumeration of their actual resulting contents as the normative def of what is to be there? weakness is that (on my reading of 7956 aided by Pete's answers to Joaquin) the appearance of packageMerge in the syntax of Infrastructure is not removed, but the copying is to be done. As a result, it seems we will have two independent and normative specifications of the same part of the model, and it is therefore possible that the representation for bootstrapping, with the results of the hand copying operation, will differ from the result of an automated merge, coded on the basis of the rules of packageMerge, without regard to what the handexecuted result says it "ought" to be. the only way to exclude the possibility of future trouble is to explicitly specify the contents normatively in terms of one approach, not two, and of the two, an enumeration of the contents seems the safest. Karl Frank Principal Architect, Product Strategy & Architecture -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, January 07, 2005 12:31 PM To: Joaquin Miller; MOF UML Infrastructure FTF Subject: RE: a question for clarification My answer to your previous question applies here also: from a specification point of view the packages are connected through package merge, and the semantics of package merge determines the copying that has taken place by hand: however if you look at the technical realization of the metamodels you will not see a package merge relationship there since the hand-copying is required for bootstrapping reasons - which Jim can explain better but in essence you cannot use an automated implementation of Package Merge to create the Constructs package which is where Package Merge is defined! So you should be able to look at Constructs and verify that it does indeed implement the package merge rules in copying the classes from Basic: it's not just a random set of copies or naming coincidences. This also means that should Basic change at a future revision, then we know exactly the resultant changes to Constructs - by again applying the semantics of the package merge rules. Hope that helps Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > Sent: Friday, January 07, 2005 4:56 PM > To: MOF UML Infrastructure FTF > Subject: a question for clarification > > I'm asking this for my own information, and so the answer will be in > the archives. So i send it in a message separate from the previous. > > "As a result, there are actually no dependencies between the > Abstractions packages, Basic, and/or Constructs." ... "Constructs also > contains metaclasses from Basic and shared metaclasses defined in > packages contained in Abstractions. These shared metaclasses are > included in Constructs by copy." [Proposed resolution to 7956] > > Is it the case that the only connection between Basic and Constructs > is that some class specifications from Basic were copied into > Constructs by the authors of the specification? > > I'm sure we intend more than that; my question is whether it is the > case that there is no formal connection between the two models, the > only connection being that the two contain classes that happen to have > the same name and structure. > > I don't know if the answer to this question has any practical > consequences. We certainly need to nail down the models and finish > the finalization process. I'm wondering, though, if this exposes some > limitation in our specification, that makes it difficult or impossible > to identify a certain class in Constructs with the class of the same > name in Basic. > > > Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Jan 2005 15:32:56 -0800 To: MOF UML Infrastructure FTF From: Joaquin Miller Subject: RE: a question for clarification That does help, Pete; thanks. I do understand the bootstrap problem. And i begin to see that this does expose a limitation in our technology. The only way we can identify two classes (declare that this is only one class) is by import or merge. We can't, any other way, say that a particular class in Basic is the same class as a particular class in Constructs. That's because, in the absence of an import or merge, the fact that they have different names means they are different classes. (I claim to understand the bootstrap problem. But maybe not. As i understand it the problem arises because we want to use a tool to implement the merge. It's unhappy to have to remove essential information from the model to enable a tool. In the case of Smalltalk, for example, the tail was eaten by hand, and then the original image passed around so that had to be done only once. I guess the same might have happened in our case, if we had made the starting model by hand and passed it around as XMI. But we have chosen to make the starting model automatically, which requires removing the information ("use an automated implementation of Package Merge to create the Constructs"). X-Change Technologies has just voted yes. This is good enough for now. I can't help but wonder if this failure to identify Basic classes with Constructs classes might be avoided in MOF 3. (I'm taking the hard line: if they are not identified in the XMI, they are not identical.) At 09:31 AM 1/7/2005, you wrote: My answer to your previous question applies here also: from a specification point of view the packages are connected through package merge, and the semantics of package merge determines the copying that has taken place by hand: however if you look at the technical realization of the metamodels you will not see a package merge relationship there since the hand-copying is required for bootstrapping reasons - which Jim can explain better but in essence you cannot use an automated implementation of Package Merge to create the Constructs package which is where Package Merge is defined! So you should be able to look at Constructs and verify that it does indeed implement the package merge rules in copying the classes from Basic: it's not just a random set of copies or naming coincidences. This also means that should Basic change at a future revision, then we know exactly the resultant changes to Constructs - by again applying the semantics of the package merge rules. Hope that helps Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] > Sent: Friday, January 07, 2005 4:56 PM > To: MOF UML Infrastructure FTF > Subject: a question for clarification > > I'm asking this for my own information, and so the answer > will be in the > archives. So i send it in a message separate from the previous. > > "As a result, there are actually no dependencies between the > Abstractions > packages, Basic, and/or Constructs." ... "Constructs also contains > metaclasses from Basic and shared metaclasses defined in > packages contained > in Abstractions. These shared metaclasses are included in > Constructs by > copy." [Proposed resolution to 7956] > > Is it the case that the only connection between Basic and > Constructs is > that some class specifications from Basic were copied into > Constructs by > the authors of the specification? > > I'm sure we intend more than that; my question is whether it > is the case > that there is no formal connection between the two models, the only > connection being that the two contain classes that happen to > have the same > name and structure. > > I don't know if the answer to this question has any practical > consequences. We certainly need to nail down the models and > finish the > finalization process. I'm wondering, though, if this exposes some > limitation in our specification, that makes it difficult or > impossible to > identify a certain class in Constructs with the class of the > same name in > Basic. > > > Subject: RE: [mu2i] Official Ballot 6 - VOTE NOW Date: Fri, 7 Jan 2005 12:23:32 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mu2i] Official Ballot 6 - VOTE NOW Thread-Index: AcT02tjECAbBNDXLRHSu2uCPUqUaEQAAHhzg From: "Pete Rivett" To: "Joaquin Miller" , "MOF UML Infrastructure FTF" X-Virus-Scanned: by amavisd-new at sentraliant.com That is not crystal clear. How do the classes from Basic get into Constructs? They get into Constructs through a package merge operation as indicated in the diagram - however this is a 'logical' package merge for specification purposes only - and is in fact carried out by hand for bootstrapping reasons. Hope that helps Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Friday, January 07, 2005 4:45 PM To: MOF UML Infrastructure FTF Subject: Re: [mu2i] Official Ballot 6 - VOTE NOW I apologize; i overlooked this until just now: "Constructs also contains metaclasses from Basic and shared metaclasses defined in packages contained in Abstractions. These shared metaclasses are included in Constructs by copy." [Proposed resolution to 7956] That is not crystal clear. How do the classes from Basic get into Constructs? The only classes called "shared" are the ones in Abstractions. Does the following change fix this, or do classes from Basic get over some other way? "Constructs also contains shared metaclasses from Basic and shared metaclasses defined in packages contained in Abstractions. These shared metaclasses are included in Constructs by copy." Should i post an issue on this? At 06:22 AM 1/7/2005, Pete Rivett wrote: Jim has updated this following comments on the draft and I'm sending it out for vote in his behalf. Note that votes are due by end Monday in order to try and get this all complete for the forthcoming meeting. Regards Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com