Issue 6971: property CoreSemanticModelBridge.element (uml2di-ftf) Source: Adaptive (Mr. Pete Rivett, pete.rivett@adaptive.com) Nature: Uncategorized Issue Severity: Summary: The property CoreSemanticModelBridge.element should reference the class MOF::Object rather than Elements::Element. MOF::Object is the implicit superclass of everything in UML2/MOF2. Making this change allows diagram elements to refer to instances of any metamodel: not just UML2. Resolution: Revised Text: a) Figure 3: remove the classes Uml1SemanticModelBridge, Core::Element.replace the class Elements::Element by MOF::Object. The full resolution must include the new redrawn diagram. b) Section 8.10, para 1 replace the existing text: For UML 2.0 and later, this can be the class Element from the package Kernel, referenced by CoreSemanticModelBridge. By the new text: For UML 2.0 and later, this can be the class Object from the package MOF, referenced by CoreSemanticModelBridge.DI-Metamodel (Fig. 3 from adopted specification) Actions taken: February 3, 2004: received issue November 1, 2005: closed issue Discussion: The intension of the draft is to reference a superclass of all metamodels specified with MOF so the change is to MOF::Object is necessary End of Annotations:===== ubject: Issue on UML2 Diagram Interchange Date: Tue, 3 Feb 2004 20:22:15 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue on UML2 Diagram Interchange Thread-Index: AcPqcyKa2kqCRuyAT7aL0xnNnobFwA== From: "Pete Rivett" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i141BLJN019579 The property CoreSemanticModelBridge.element should reference the class MOF::Object rather than Elements::Element. MOF::Object is the implicit superclass of everything in UML2/MOF2. Making this change allows diagram elements to refer to instances of any metamodel: not just UML2. Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 Subject: RE: Ballot 1 Second Proposal Date: Wed, 28 Apr 2004 12:47:27 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 1 Second Proposal Thread-Index: AcQrsXs8hhOIug2sQEau/r9G7hh/VQBg2GEA From: "Pete Rivett" To: "Marko Boger" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i3SGiATE024368 Hi Marko, In the issue resolution for 6971 when I said "The full resolution must include the new redrawn diagram" I intended someone with access to the original metamodel to redraw the diagram and include it in the resolution before voting! The Nesting Guide is much improved, but still has some issues: The nesting guide still refers to UML 1.4 in the introduction. More worryingly still, the Guide is completely based on the UML 1.4 not the UML 2.0 metamodel (e.g. it refers to AssociationEnd as a metaclass). Line 7 of the Notation states "if it is a Uml1- or CoreSemanticModelBridge ": if we adopt 6971 then Uml1- bridge will be deleted. The notation consistently misspells Compartment as Compartement and there are a few other typos. The Notation states: "Lists of elements are separated with a semicolon ','. ". Is it a comma ',' or a semicolon ';' ? For description of Bridges for UML2 you'll have to specify not just the class name but the package name also. There are 2 DiAssociationClass elements and nothing for Association. The Association element refers to a Multiplicity element which is not defined. What are the Names such as DiClass for - what do they actually name in the DI XMI file, or are they merely for cross-referencing in the Nesting Guide itself. The Nesting Guide is a complex section that would require a lot more time than I have right now to review properly. And I'm not sure it's worth it until it's brought up to UML 2.0 level. It's still not clear to me what is the intended status of the guide: you say it's required for 'rigor' which implies that implementations have to conform to it: so that, in effect, it constrains valid DI files. In which case words to that effect need to be added to the compliance section. I'd also be interested to hear why you found it necessary to come up with this guide for implementation purposes: while I'm sympathetic with the intention it is going beyond the scope of the original submission, and into the territory of the new RFP that Jochen Seeman was proposing. So I think it does need more justification. The Issue does not say much about the problem being addressed except "This guide avoid confusions that will occur if the nesting of diagram elements is not specified". I'm also not convinced that a textual representation is the best expression of the rules - this seems to beg the need for a model supported by some diagrams to show the structural relationships. Regards Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, 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: Marko Boger [mailto:marko.boger@gentleware.com] Sent: Monday, April 26, 2004 12:03 PM To: uml2di-ftf@omg.org Subject: Ballot 1 Second Proposal Hello everyone, attached you find a revised version of Ballot 1. It contains corrections that Pete Rivett had rightfully pointed out are needed. This is still for discussion, there is one issue number missing that we have not received from Jürgen Bold. We have also tried to better explain how to read the nesting appendix. It is a grammar like notation and it might be a little unhandy to read but it is needed for the required rigor. Regarding the extension of the DI FTF, I would like to make clear that (as I stated in a previous mail) I am in favor of extending the DI FTF until June 6 2004 to give other implementers an additional chance to review the Diagram Interchange. However, I strongly appose an extension beyond that point as is currently discussed for the Superstructure. Regards, Marko ------------------------------------------------------------------------------ Dr. Marko Boger, CEO, +49 (0) 40 32 89 98 78 Subject: RE: Ballot 1 now complete Date: Sun, 9 May 2004 18:24:48 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Ballot 1 now complete Thread-Index: AcQ2FHB6nMLoyilKQ2OcKO4eagZX+A== From: "Pete Rivett" To: , Cc: , X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i49MHdFh018049 Hi Marko, I do object. I already provided comments on the ballot on 28th April and these do not seem to have been addressed. For convenience here they are again. Furthermore I think it's pointless adopting a resolution (for the nesting guide) that applies only to UML 1.4 and it's not realistic to wait for the Infra and Super to be 'finally adopted' (by which I assume is meant 'finalized'). IMHO the FTFs have to synchronize and finish together, and the chairs have to manage dependencies. In practice I don't see a large amount of change from this point on with respect to diagrams. And I'm sure Bran/Guus would be amenable to specifically alerting you as and when any diagram-related issue gets resolved in Super. Regards Pete ----------- Hi Marko, In the issue resolution for 6971 when I said "The full resolution must include the new redrawn diagram" I intended someone with access to the original metamodel to redraw the diagram and include it in the resolution before voting! The Nesting Guide is much improved, but still has some issues: The nesting guide still refers to UML 1.4 in the introduction. More worryingly still, the Guide is completely based on the UML 1.4 not the UML 2.0 metamodel (e.g. it refers to AssociationEnd as a metaclass). Line 7 of the Notation states "if it is a Uml1- or CoreSemanticModelBridge ": if we adopt 6971 then Uml1- bridge will be deleted. The notation consistently misspells Compartment as Compartement and there are a few other typos. The Notation states: "Lists of elements are separated with a semicolon ','. ". Is it a comma ',' or a semicolon ';' ? For description of Bridges for UML2 you'll have to specify not just the class name but the package name also. There are 2 DiAssociationClass elements and nothing for Association. The Association element refers to a Multiplicity element which is not defined. What are the Names such as DiClass for - what do they actually name in the DI XMI file, or are they merely for cross-referencing in the Nesting Guide itself. The Nesting Guide is a complex section that would require a lot more time than I have right now to review properly. And I'm not sure it's worth it until it's brought up to UML 2.0 level. It's still not clear to me what is the intended status of the guide: you say it's required for 'rigor' which implies that implementations have to conform to it: so that, in effect, it constrains valid DI files. In which case words to that effect need to be added to the compliance section. I'd also be interested to hear why you found it necessary to come up with this guide for implementation purposes: while I'm sympathetic with the intention it is going beyond the scope of the original submission, and into the territory of the new RFP that Jochen Seeman was proposing. So I think it does need more justification. The Issue does not say much about the problem being addressed except "This guide avoid confusions that will occur if the nesting of diagram elements is not specified". I'm also not convinced that a textual representation is the best expression of the rules - this seems to beg the need for a model supported by some diagrams to show the structural relationships. Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, 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: Marko Boger [mailto:marko.boger@gentleware.com] Sent: Thursday, May 06, 2004 7:00 AM To: uml2di-ftf@omg.org Subject: Ballot 1 now complete Hello everyone, after the turbulances of the deadlines have now calmed down, I am sending you now the complete Ballot 1. The only change over the last version is that we entered the missing issue number. Are there any objections to vote on this ballot at this time? I suggest we wait for a response to this and if there are no objections move to a vote on my next email. Regards, Marko Dr. Marko Boger, CEO Gentleware AG Schanzenstr. 70, D-20357 Hamburg T:+49(0)40 32 899 878, F:+49(0)40 24425331 email: Marko.Boger@gentleware.com www.gentleware.com http://www.adaptive.com