Issue 7651: Compliance points - Diagram Interchange (uml2-superstructure-ftf) Source: Gentleware AG (Dr. Marko Boger, marko.boger(at)gentleware.com) Nature: Uncategorized Issue Severity: Summary: From letters from Bran Selic and Pete Rivett I learn that the Superstructure FTF plans to revoke Diagram Interchange as a compliance point to UML 2 compliance. As the Chair of the Diagram Interchange FTF I urge you to make compliance Diagram Interchange a necessity for full compliance. In all discussions I attended it was always pointed out that the ability to exchange UML diagrams compliant to a standard using XMI was the single most important issue missing in UML 1. The Diagram Interchange specification was specifically designed to solve this problem. It is of essence that Diagram Interchange remains a part of UML 2 compliance. Otherwise the whole UML 2 standard is drastically reduces in its value. The Diagram Interchange specification is of high quality. It is fully implemented by Gentleware to provide a reference, we have made cross checks with various other vendors that confirm high quality and interchangability. May I also point out that Prof. Mario Jeckle, our friend we miss dearly, has implemented an XSLT transformation from XMI to SVG. It is available on his web site at www.jeckle.de. Resolution: Revised Text: Actions taken: August 20, 2004: received issue Discussion: End of Annotations:===== m: "Marko Boger" To: , "'Karl Frank'" , "'Pete Rivett'" , "'Branislav Selic'" , , , Cc: Subject: Compliance points - Diagram Interchange. Date: Fri, 20 Aug 2004 16:38:21 +0200 X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7KEpQlj011555 Gentlemen, >From letters from Bran Selic and Pete Rivett I learn that the Superstructure FTF plans to revoke Diagram Interchange as a compliance point to UML 2 compliance. As the Chair of the Diagram Interchange FTF I urge you to make compliance Diagram Interchange a necessity for full compliance. In all discussions I attended it was always pointed out that the ability to exchange UML diagrams compliant to a standard using XMI was the single most important issue missing in UML 1. The Diagram Interchange specification was specifically designed to solve this problem. It is of essence that Diagram Interchange remains a part of UML 2 compliance. Otherwise the whole UML 2 standard is drastically reduces in its value. The Diagram Interchange specification is of high quality. It is fully implemented by Gentleware to provide a reference, we have made cross checks with various other vendors that confirm high quality and interchangability. May I also point out that Prof. Mario Jeckle, our friend we miss dearly, has implemented an XSLT transformation from XMI to SVG. It is available on his web site at www.jeckle.de. Regards, Marko Boger 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 Bran wrote: > I further note that Concrete Syntax compliance no longer addresses Diagram > Interchange compliance, which Bran's 8/8/04 email proposal included > (although the 8/8/04 draft referred to it as "UML Design Interchange > specification"). What happened here? Was this a publicly discussed consensus > decision on a mailing list, or has the OMG formally dropped the UML 2 DI > specification? If UML 2 DI is still part of the UML 2 FAS quartet, we need > to address DI compliance in some sort of straightforward manner. There was a public discussion on this point and the conclusion was to remove reference to DI compliance. This is because it was pointed out that DI elements have a pointer to model elements and are, therefore, it is not separable as an independent compliance type. Note that the other two compliance types are independent of each other. As for DI compliance, it is appropriate to declare that in the DI spec itself, rather than in the Superstructure (note that the coupling between these two specs is strictly one way: the DI depends on the superstructure but not the other way around). Unfortunately, that FTF is working at a different pace and it will likely require further delays before they are finished. > What to do? I am inclined to your support your point if we: 1) include > Diagram Interchange compliance; 2) explain clearly what the implications of > using "Abstract Syntax", "Concrete Syntax", "Diagram Interchange" and > combinations of them are for lower levels. I am afraid that, with time running out, we no longer have the luxury to ponder these "what if" scenarios. We have to make a decision and the mechanism by which this is done in such circumstances is by voting. Therefore, I will be issuing the special compliance point ballot tomorrow morning with what I think represents the majority opinion of what this text should look like. I will do my best to incorporate all the feedback that was provided. If people feel that they can contribute to this, please forward me your suggestions. Cheers...Bran ----------------------------------- Pete wrote: Bran, In fact, as it stands, the DI spec does not depend on Superstructure - it just has a generic model element link which allows any sort of metamodel to have diagrams interchanged. Which is a good thing. Though it does have an Appendix A (which the FAS states needs to be updated by the FTF) covering how the model elements from Super are represented in the DI metamodel for specific diagram types. I think the DI spec should have a separate compliance point specifically for UML 2, requiring generic compliance to the DI spec (as in the current DI compliance point) and correct representation of the diagrams according to Appendix A for those diagram types supported by the tool (the statement of supported diagram types for the tool will be covered by its UML2 compliance statement). Pete ----------------------------------- Cris wrote: > Please do not propose adding DI compliance to the definition of UML 2 > compliance. We first need to explain why Diagram Interchange (DI) was abruptly dropped from the 8/8/04 compliance draft with no public explanation that I have read or heard. When and how was this decided? Please point me to public email or minutes, since I must have missed this... > Diagram Interchange is a separate spec with separate technology issues > surrounding its implementation. I disagree. Although DI has separate technical issues, it also has strongly related technology issues. In particular, DI's primary reason for existence is to exchange UML 2 diagrams between tools. Isn't this something UML 2 users will expect from a modeling tool standard? So are we as a standards body saying that Diagram Interchange is relevant or irrelevant for UML 2 Superstructure compliance? If it is the former, we need to explain its relevance; if it is the latter, let's explain why it is irrelevant and retire it. One way or the other, let's be clear! Thanks, Cris > -----Original Message----- > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > Sent: Thursday, August 19, 2004 1:03 PM > To: 'Pete Rivett'; cris.kobryn@telelogic.com; 'Branislav Selic'; > uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal - "Feature Support > Statement" example > > > I'm not sure the Compliance Summary needs to list levels *beneath* > > that which compliance is claimed - since compliance at level N > > automatically implies/requires support at Level N-1 (start of section > > 1.3 of the new section states: "Compliance to a given level entails > > full realization of all language units that are defined for that > > compliance level (note that this implies compliance with all levels > below it)." > > So, the example is not actually valid: it is not possible to have > > Concrete Syntax compliance at Level 1 but not at Level 0. > > Although I am inclined to agree with your intention here, I disagree > that what you are saying is clearly explained by the current spec draft. > The sentence you cite is insufficient, since the section that defines > the "two distinct types of compliance" (section 1.3, par. 3) does not > explain what the individual or combined (i.e., "both") usage of the > distinct types implies for lower levels. > > I further note that Concrete Syntax compliance no longer addresses > Diagram Interchange compliance, which Bran's 8/8/04 email proposal > included (although the 8/8/04 draft referred to it as "UML Design > Interchange specification"). What happened here? Was this a publicly > discussed consensus decision on a mailing list, or has the OMG formally > dropped the UML 2 DI specification? If UML 2 DI is still part of the UML > 2 FAS quartet, we need to address DI compliance in some sort of > straightforward manner. > > What to do? I am inclined to your support your point if we: 1) include > Diagram Interchange compliance; 2) explain clearly what the implications > of using "Abstract Syntax", "Concrete Syntax", "Diagram Interchange" and > combinations of them are for lower levels. > > > > > With respect to the feature support table I think we (or a vendor > > claiming support)needs to have more definition of the terms than, for > > example, 'Action Semantics' or 'Dynamic Semantics': since the spec > > does not already define what it means to support dynamic semantics for > > > a package - which is one of the reasons it is not included in the > > formal compliance levels. And 'Action Semantics' is even less clear > > (how does it differ from Dynamic Semantics for the Actions > package(s)?). > > I agree, and also think we can whack "Action Semantics". > > > Not sure it's necessary to have entries where no support is claimed, > > but I'm not that bothered. > > Good. > > > I think the section should include very specific examples of support > > for presentation options and semantic variation points: I think for > > these the table approach may become awkward which is why I originally > > suggested a semi-structured English approach. Maybe we could have a > > table followed by semi-structured text for the latter? > > There should always be the option to elaborate on anything, and if we > want to add semi-structured text to further explain the example, I am > fine with that! > > Thanks, > > Cris > > > > > > > -----Original Message----- > > > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > > > Sent: Thursday, August 19, 2004 1:56 AM > > > To: 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > > > mu2i-ftf@omg.org; ocl2-ftf@omg.org > > > Subject: RE: Compliance points resolution proposal - "Feature > > > Support Statement" example > > > > > > FTFers, > > > > > > Attached is an example of a "Feature Support Statement" > > > (formerly known as > > > a"Compliance Support Statement") that Anders and I were asked to > > > generate during today's FTF telecon. > > > > > > Thanks to Bran and Pete for providing review feedback to improve the > > > > example prior to sending it out to the mailing list. > > > > > > -- Cris > > > > > > > > > > -----Original Message----- > > > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > > > Sent: Tuesday, August 17, 2004 3:05 PM > > > > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; > > > ocl2-ftf@omg.org > > > > Subject: Compliance points resolution proposal > > > > > > > > > > > > After yet more cycles of the proposed resolution between > > > Anders and Pete > > > > and myself, attached, please find a copy of the proposed > > > resolution to the > > > > compliance point issue (6248). > > > > > > > > Since this is a gating issue, I would like to have a definitive > > > > FTF position on this specific resolution before the OMG meeting > > > in Montreal > > > > next week. This likely means having a special vote just on > > > this resolution > > > > outside the usual weekly cycle. > > > > > > > > Regards, > > > > Bran > > > > > > > > > > > From: Edwin Seidewitz To: "'Marko Boger'" , "'uml2-superstructure-ftf@omg.org'" , "'mu2i-ftf@omg.org'" , "'ocl2-ftf@omg.org'" Cc: "'uml2di-ftf@omg.org'" Subject: RE: Compliance points - Diagram Interchange. Date: Fri, 20 Aug 2004 10:54:20 -0400 X-Mailer: Internet Mail Service (5.5.2655.55) Marko -- I am a bit confused by this, as I have been by some of the other times diagram interchange compliance has come up. Doesn't the UML Diagram Interchange specification have a compliance section? Isn't this where the compliance points for diagram interchange should be? Just looking at this from the point of view of a user of the OMG UML specs, it seems confusing to have compliance for diagram interchange in the UML Superstructure spec, when that spec does not define diagram interchange. I remember this being discussed at some FTF meeting a while ago, but I must admit I have not caught up on all the recent compliance discussion. Is the expectation that ALL compliance points for ALL the UML 2.0 specifications be defined in the Superstructure spec? (For example, what about OCL 2.0 compliance?) -- Ed > -----Original Message----- > From: Marko Boger [mailto:marko.boger@gentleware.com] > Sent: Friday, August 20, 2004 10:38 AM > To: cris.kobryn@telelogic.com; 'Karl Frank'; 'Pete Rivett'; > 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > mu2i-ftf@omg.org; ocl2-ftf@omg.org > Cc: uml2di-ftf@omg.org > Subject: Compliance points - Diagram Interchange. > > > Gentlemen, > > From letters from Bran Selic and Pete Rivett I learn that the > Superstructure FTF plans to revoke Diagram Interchange as a > compliance point to UML 2 compliance. As the Chair of the > Diagram Interchange FTF I urge you to make compliance Diagram > Interchange a necessity for full compliance. > > In all discussions I attended it was always pointed out that > the ability to exchange UML diagrams compliant to a standard > using XMI was the single most important issue missing in UML > 1. The Diagram Interchange specification was specifically > designed to solve this problem. It is of essence that Diagram > Interchange remains a part of UML 2 compliance. Otherwise the > whole UML 2 standard is drastically reduces in its value. > > The Diagram Interchange specification is of high quality. It > is fully implemented by Gentleware to provide a reference, we > have made cross checks with various other vendors that > confirm high quality and interchangability. May I also point > out that Prof. Mario Jeckle, our friend we miss dearly, has > implemented an XSLT transformation from XMI to SVG. It is > available on his web site at www.jeckle.de. > > Regards, Marko Boger > > 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 > > Bran wrote: > > > I further note that Concrete Syntax compliance no longer addresses > > Diagram Interchange compliance, which Bran's 8/8/04 email proposal > > included (although the 8/8/04 draft referred to it as "UML Design > > Interchange specification"). What happened here? Was this a > publicly > > discussed > consensus > > decision on a mailing list, or has the OMG formally dropped > the UML 2 > > DI specification? If UML 2 DI is still part of the UML 2 > FAS quartet, > > we need to address DI compliance in some sort of straightforward > > manner. > > There was a public discussion on this point and the > conclusion was to remove reference to DI compliance. This is > because it was pointed out that DI elements have a pointer to > model elements and are, therefore, it is not separable as an > independent compliance type. Note that the other two > compliance types are independent of each other. > > As for DI compliance, it is appropriate to declare that in > the DI spec itself, rather than in the Superstructure (note > that the coupling between these two specs is strictly one > way: the DI depends on the superstructure but not the other > way around). Unfortunately, that FTF is working at a > different pace and it will likely require further delays > before they are finished. > > > What to do? I am inclined to your support your point if we: > 1) include > > Diagram Interchange compliance; 2) explain clearly what the > > implications > of > > using "Abstract Syntax", "Concrete Syntax", "Diagram > Interchange" and > > combinations of them are for lower levels. > > I am afraid that, with time running out, we no longer have > the luxury to ponder these "what if" scenarios. We have to > make a decision and the mechanism by which this is done in > such circumstances is by voting. Therefore, I will be issuing > the special compliance point ballot tomorrow morning with > what I think represents the majority opinion of what this > text should look like. I will do my best to incorporate all > the feedback that was provided. If people feel that they can > contribute to this, please forward me your suggestions. > > Cheers...Bran > ----------------------------------- > Pete wrote: > > > Bran, > In fact, as it stands, the DI spec does not depend on > Superstructure - it just has a generic model element link > which allows any sort of metamodel to have diagrams > interchanged. Which is a good thing. Though it does have an > Appendix A (which the FAS states needs to be updated by the > FTF) covering how the model elements from Super are > represented in the DI metamodel for specific diagram types. > > I think the DI spec should have a separate compliance point > specifically for UML 2, requiring generic compliance to the > DI spec (as in the current DI compliance point) and correct > representation of the diagrams according to Appendix A for > those diagram types supported by the tool (the statement of > supported diagram types for the tool will be covered by its > UML2 compliance statement). > > Pete > > ----------------------------------- > Cris wrote: > > > Please do not propose adding DI compliance to the > definition of UML 2 > > compliance. > > We first need to explain why Diagram Interchange (DI) was > abruptly dropped from the 8/8/04 compliance draft with no > public explanation that I have read or heard. When and how > was this decided? Please point me to public email or minutes, > since I must have missed this... > > > Diagram Interchange is a separate spec with separate > technology issues > > surrounding its implementation. > > I disagree. Although DI has separate technical issues, it > also has strongly related technology issues. In particular, > DI's primary reason for existence is to exchange UML 2 > diagrams between tools. Isn't this something UML 2 users will > expect from a modeling tool standard? > > So are we as a standards body saying that Diagram Interchange > is relevant or irrelevant for UML 2 Superstructure > compliance? If it is the former, we need to explain its > relevance; if it is the latter, let's explain why it is > irrelevant and retire it. One way or the other, let's be clear! > > Thanks, > > Cris > > > > > -----Original Message----- > > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > > Sent: Thursday, August 19, 2004 1:03 PM > > To: 'Pete Rivett'; cris.kobryn@telelogic.com; 'Branislav Selic'; > > uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > > Subject: RE: Compliance points resolution proposal - > "Feature Support > > Statement" example > > > > > I'm not sure the Compliance Summary needs to list levels > *beneath* > > > that which compliance is claimed - since compliance at level N > > > automatically implies/requires support at Level N-1 (start of > > > section 1.3 of the new section states: "Compliance to a > given level > > > entails full realization of all language units that are > defined for > > > that compliance level (note that this implies compliance with all > > > levels > > below it)." > > > So, the example is not actually valid: it is not possible to have > > > Concrete Syntax compliance at Level 1 but not at Level 0. > > > > Although I am inclined to agree with your intention here, I > disagree > > that what you are saying is clearly explained by the current spec > > draft. The sentence you cite is insufficient, since the > section that > > defines the "two distinct types of compliance" (section > 1.3, par. 3) > > does not explain what the individual or combined (i.e., > "both") usage > > of the distinct types implies for lower levels. > > > > I further note that Concrete Syntax compliance no longer addresses > > Diagram Interchange compliance, which Bran's 8/8/04 email proposal > > included (although the 8/8/04 draft referred to it as "UML Design > > Interchange specification"). What happened here? Was this a > publicly > > discussed consensus decision on a mailing list, or has the OMG > > formally dropped the UML 2 DI specification? If UML 2 DI is > still part > > of the UML 2 FAS quartet, we need to address DI compliance in some > > sort of straightforward manner. > > > > What to do? I am inclined to your support your point if we: > 1) include > > Diagram Interchange compliance; 2) explain clearly what the > > implications of using "Abstract Syntax", "Concrete Syntax", > "Diagram > > Interchange" and combinations of them are for lower levels. > > > > > > > > With respect to the feature support table I think we (or a vendor > > > claiming support)needs to have more definition of the terms than, > > > for example, 'Action Semantics' or 'Dynamic Semantics': since the > > > spec does not already define what it means to support dynamic > > > semantics for > > > > > a package - which is one of the reasons it is not included in the > > > formal compliance levels. And 'Action Semantics' is even > less clear > > > (how does it differ from Dynamic Semantics for the Actions > > package(s)?). > > > > I agree, and also think we can whack "Action Semantics". > > > > > Not sure it's necessary to have entries where no support > is claimed, > > > but I'm not that bothered. > > > > Good. > > > > > I think the section should include very specific examples > of support > > > for presentation options and semantic variation points: I > think for > > > these the table approach may become awkward which is why I > > > originally suggested a semi-structured English approach. Maybe we > > > could have a table followed by semi-structured text for > the latter? > > > > There should always be the option to elaborate on anything, > and if we > > want to add semi-structured text to further explain the > example, I am > > fine with that! > > > > Thanks, > > > > Cris > > > > > > > > > > > > -----Original Message----- > > > > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > > > > Sent: Thursday, August 19, 2004 1:56 AM > > > > To: 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > > > > mu2i-ftf@omg.org; ocl2-ftf@omg.org > > > > Subject: RE: Compliance points resolution proposal - "Feature > > > > Support Statement" example > > > > > > > > FTFers, > > > > > > > > Attached is an example of a "Feature Support Statement" > (formerly > > > > known as a"Compliance Support Statement") that Anders > and I were > > > > asked to generate during today's FTF telecon. > > > > > > > > Thanks to Bran and Pete for providing review feedback > to improve > > > > the > > > > > > example prior to sending it out to the mailing list. > > > > > > > > -- Cris > > > > > > > > > > > > > -----Original Message----- > > > > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > > > > Sent: Tuesday, August 17, 2004 3:05 PM > > > > > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; > > > > ocl2-ftf@omg.org > > > > > Subject: Compliance points resolution proposal > > > > > > > > > > > > > > > After yet more cycles of the proposed resolution between > > > > Anders and Pete > > > > > and myself, attached, please find a copy of the proposed > > > > resolution to the > > > > > compliance point issue (6248). > > > > > > > > > > Since this is a gating issue, I would like to have a > definitive > > > > > FTF position on this specific resolution before the > OMG meeting > > > > in Montreal > > > > > next week. This likely means having a special vote just on > > > > this resolution > > > > > outside the usual weekly cycle. > > > > > > > > > > Regards, > > > > > Bran > > > > > > > > > > > > > > > > > > > > > > > > To: "Marko Boger" Cc: cris.kobryn@telelogic.com, "'Karl Frank'" , mu2i-ftf@omg.org, ocl2-ftf@omg.org, "'Pete Rivett'" , uml2-superstructure-ftf@omg.org, uml2di-ftf@omg.org Subject: Re: Compliance points - Diagram Interchange. X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 20 Aug 2004 10:59:48 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/20/2004 10:59:49, Serialize complete at 08/20/2004 10:59:49 Marko, Please note that Diagram Interchange was never a compliance point for the UML 2.0 Superstructure -- not in the original submission, nor in final adopted spec that was recommended by the AB and adopted by the PTC. I believe that the confusion stems from a draft resolution to an issue related to UML 2 superstructure compliance points that suggested that it should be included, but this was discarded. Adding this new capability to the UML 2.0 superstructure, although it may be a good idea, was not a requirement imposed by either the AB or the PTC. (There is not even an issue raised by any OMG member asking for that capability.) Under those circumstances, adding this new capability to the UML superstructure in a rush, without due technical analysis, does not seem appropriate. We should definitely address this issue in the coming months. One excellent forum for dealing with it is the Diagram Interchange FTF, which I presume will ask for an extension of its September 30 deadline. Hope this helps. Regards, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Marko Boger" 08/20/2004 10:38 AM To , "'Karl Frank'" , "'Pete Rivett'" , Branislav Selic/Ottawa/IBM@IBMCA, , , cc Subject Compliance points - Diagram Interchange. Gentlemen, >From letters from Bran Selic and Pete Rivett I learn that the Superstructure FTF plans to revoke Diagram Interchange as a compliance point to UML 2 compliance. As the Chair of the Diagram Interchange FTF I urge you to make compliance Diagram Interchange a necessity for full compliance. In all discussions I attended it was always pointed out that the ability to exchange UML diagrams compliant to a standard using XMI was the single most important issue missing in UML 1. The Diagram Interchange specification was specifically designed to solve this problem. It is of essence that Diagram Interchange remains a part of UML 2 compliance. Otherwise the whole UML 2 standard is drastically reduces in its value. The Diagram Interchange specification is of high quality. It is fully implemented by Gentleware to provide a reference, we have made cross checks with various other vendors that confirm high quality and interchangability. May I also point out that Prof. Mario Jeckle, our friend we miss dearly, has implemented an XSLT transformation from XMI to SVG. It is available on his web site at www.jeckle.de. Regards, Marko Boger 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 Bran wrote: > I further note that Concrete Syntax compliance no longer addresses Diagram > Interchange compliance, which Bran's 8/8/04 email proposal included > (although the 8/8/04 draft referred to it as "UML Design Interchange > specification"). What happened here? Was this a publicly discussed consensus > decision on a mailing list, or has the OMG formally dropped the UML 2 DI > specification? If UML 2 DI is still part of the UML 2 FAS quartet, we need > to address DI compliance in some sort of straightforward manner. There was a public discussion on this point and the conclusion was to remove reference to DI compliance. This is because it was pointed out that DI elements have a pointer to model elements and are, therefore, it is not separable as an independent compliance type. Note that the other two compliance types are independent of each other. As for DI compliance, it is appropriate to declare that in the DI spec itself, rather than in the Superstructure (note that the coupling between these two specs is strictly one way: the DI depends on the superstructure but not the other way around). Unfortunately, that FTF is working at a different pace and it will likely require further delays before they are finished. > What to do? I am inclined to your support your point if we: 1) include > Diagram Interchange compliance; 2) explain clearly what the implications of > using "Abstract Syntax", "Concrete Syntax", "Diagram Interchange" and > combinations of them are for lower levels. I am afraid that, with time running out, we no longer have the luxury to ponder these "what if" scenarios. We have to make a decision and the mechanism by which this is done in such circumstances is by voting. Therefore, I will be issuing the special compliance point ballot tomorrow morning with what I think represents the majority opinion of what this text should look like. I will do my best to incorporate all the feedback that was provided. If people feel that they can contribute to this, please forward me your suggestions. Cheers...Bran ----------------------------------- Pete wrote: Bran, In fact, as it stands, the DI spec does not depend on Superstructure - it just has a generic model element link which allows any sort of metamodel to have diagrams interchanged. Which is a good thing. Though it does have an Appendix A (which the FAS states needs to be updated by the FTF) covering how the model elements from Super are represented in the DI metamodel for specific diagram types. I think the DI spec should have a separate compliance point specifically for UML 2, requiring generic compliance to the DI spec (as in the current DI compliance point) and correct representation of the diagrams according to Appendix A for those diagram types supported by the tool (the statement of supported diagram types for the tool will be covered by its UML2 compliance statement). Pete ----------------------------------- Cris wrote: > Please do not propose adding DI compliance to the definition of UML 2 > compliance. We first need to explain why Diagram Interchange (DI) was abruptly dropped from the 8/8/04 compliance draft with no public explanation that I have read or heard. When and how was this decided? Please point me to public email or minutes, since I must have missed this... > Diagram Interchange is a separate spec with separate technology issues > surrounding its implementation. I disagree. Although DI has separate technical issues, it also has strongly related technology issues. In particular, DI's primary reason for existence is to exchange UML 2 diagrams between tools. Isn't this something UML 2 users will expect from a modeling tool standard? So are we as a standards body saying that Diagram Interchange is relevant or irrelevant for UML 2 Superstructure compliance? If it is the former, we need to explain its relevance; if it is the latter, let's explain why it is irrelevant and retire it. One way or the other, let's be clear! Thanks, Cris > -----Original Message----- > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > Sent: Thursday, August 19, 2004 1:03 PM > To: 'Pete Rivett'; cris.kobryn@telelogic.com; 'Branislav Selic'; > uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal - "Feature Support > Statement" example > > > I'm not sure the Compliance Summary needs to list levels *beneath* > > that which compliance is claimed - since compliance at level N > > automatically implies/requires support at Level N-1 (start of section > > 1.3 of the new section states: "Compliance to a given level entails > > full realization of all language units that are defined for that > > compliance level (note that this implies compliance with all levels > below it)." > > So, the example is not actually valid: it is not possible to have > > Concrete Syntax compliance at Level 1 but not at Level 0. > > Although I am inclined to agree with your intention here, I disagree > that what you are saying is clearly explained by the current spec draft. > The sentence you cite is insufficient, since the section that defines > the "two distinct types of compliance" (section 1.3, par. 3) does not > explain what the individual or combined (i.e., "both") usage of the > distinct types implies for lower levels. > > I further note that Concrete Syntax compliance no longer addresses > Diagram Interchange compliance, which Bran's 8/8/04 email proposal > included (although the 8/8/04 draft referred to it as "UML Design > Interchange specification"). What happened here? Was this a publicly > discussed consensus decision on a mailing list, or has the OMG formally > dropped the UML 2 DI specification? If UML 2 DI is still part of the UML > 2 FAS quartet, we need to address DI compliance in some sort of > straightforward manner. > > What to do? I am inclined to your support your point if we: 1) include > Diagram Interchange compliance; 2) explain clearly what the implications > of using "Abstract Syntax", "Concrete Syntax", "Diagram Interchange" and > combinations of them are for lower levels. > > > > > With respect to the feature support table I think we (or a vendor > > claiming support)needs to have more definition of the terms than, for > > example, 'Action Semantics' or 'Dynamic Semantics': since the spec > > does not already define what it means to support dynamic semantics for > > > a package - which is one of the reasons it is not included in the > > formal compliance levels. And 'Action Semantics' is even less clear > > (how does it differ from Dynamic Semantics for the Actions > package(s)?). > > I agree, and also think we can whack "Action Semantics". > > > Not sure it's necessary to have entries where no support is claimed, > > but I'm not that bothered. > > Good. > > > I think the section should include very specific examples of support > > for presentation options and semantic variation points: I think for > > these the table approach may become awkward which is why I originally > > suggested a semi-structured English approach. Maybe we could have a > > table followed by semi-structured text for the latter? > > There should always be the option to elaborate on anything, and if we > want to add semi-structured text to further explain the example, I am > fine with that! > > Thanks, > > Cris > > > > > > > -----Original Message----- > > > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > > > Sent: Thursday, August 19, 2004 1:56 AM > > > To: 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > > > mu2i-ftf@omg.org; ocl2-ftf@omg.org > > > Subject: RE: Compliance points resolution proposal - "Feature > > > Support Statement" example > > > > > > FTFers, > > > > > > Attached is an example of a "Feature Support Statement" > > > (formerly known as > > > a"Compliance Support Statement") that Anders and I were asked to > > > generate during today's FTF telecon. > > > > > > Thanks to Bran and Pete for providing review feedback to improve the > > > > example prior to sending it out to the mailing list. > > > > > > -- Cris > > > > > > > > > > -----Original Message----- > > > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > > > Sent: Tuesday, August 17, 2004 3:05 PM > > > > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; > > > ocl2-ftf@omg.org > > > > Subject: Compliance points resolution proposal > > > > > > > > > > > > After yet more cycles of the proposed resolution between > > > Anders and Pete > > > > and myself, attached, please find a copy of the proposed > > > resolution to the > > > > compliance point issue (6248). > > > > > > > > Since this is a gating issue, I would like to have a definitive > > > > FTF position on this specific resolution before the OMG meeting > > > in Montreal > > > > next week. This likely means having a special vote just on > > > this resolution > > > > outside the usual weekly cycle. > > > > > > > > Regards, > > > > Bran > > > > > > > > > > > Subject: RE: Compliance points - Diagram Interchange. Date: Mon, 23 Aug 2004 08:17:25 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance points - Diagram Interchange. Thread-Index: AcSI7DSqHM3dP6GSQZis/HgghvEFqgAHFJ4Q From: "Pete Rivett" To: "Marko Boger" , "Edwin Seidewitz" , , , Cc: X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7NCUnlj010211 The DI spec already contains an Appendix A that states how the different UML 2 model elements map to DI elements when used on specific UML2 Diagrams. As I already suggested in another mail why not have another compliance point for DI that is UML2 specific and states that to be compliant a tool must represent UML2 diagrams in this way. I disagree with Marko when he says 'to be compliant with DI itself has no meaning': DI already has a single compliance point though it could do with some refinement. This consists of just importing/exporting instances of the DI metamodel (in association with some other model be it UML or anything else). A further level of general compliance could be defined which is 'rendering compliance' which would represent the ability to turn the DI representation into a visual depiction. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Marko Boger [mailto:marko.boger@gentleware.com] > Sent: Monday, August 23, 2004 4:25 AM > To: 'Edwin Seidewitz'; uml2-superstructure-ftf@omg.org; > mu2i-ftf@omg.org; ocl2-ftf@omg.org > Cc: uml2di-ftf@omg.org > Subject: AW: Compliance points - Diagram Interchange. > > Ed, everyone, > > the metamodel of Diagram Interchange contains some 20 > classes. What should > the compliance to Diagram Interchange be? A tool supports nodes but no > edges? A tool either does support Diagram Interchange or it > doesn't. So > there are no compliance points within Diagram Interchange itself. > > The Metamodel of Diagram Interchange (DI) can be applied to > UML 1 or UML 2. > In fact, it could be used for any graphical notation that is > graph-oriented > (as UML is). It talks about nodes and edges, nesting and > adornments. Every > diagram element can have one unidirectional link to the > semantic model (a > node to a class, use case or actor etc., and an edge to an > association, > dependency or inheritance etc.). > > To be compliant to DI by itself has no meaning. It only > becomes relevant as > the interchange format for a graphical notation. In the > definition of our > graphical notation UML we can choose to use DI as the mechanism to > interchange diagram and layout information or we can choose > not to. UML 1 > was lacking this interchange mechanism and it is my > understanding that the > RFP for UML 2 and the AB made it a requirement for UML 2 to > support such an > interchange mechanism. > > So the compliance should be in the UML specification. UML 2 > should make it a > necessity for a tool to export to XMI including DI to be > fully compliant. > Otherwise UML 2 models are simply not interchangeable. > > 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 > > -----Ursprüngliche Nachricht----- > Von: Edwin Seidewitz [mailto:eseidewitz@intelidata.com] > Gesendet: Freitag, 20. August 2004 16:54 > An: 'Marko Boger'; 'uml2-superstructure-ftf@omg.org'; > 'mu2i-ftf@omg.org'; > 'ocl2-ftf@omg.org' > Cc: 'uml2di-ftf@omg.org' > Betreff: RE: Compliance points - Diagram Interchange. > > Marko -- > > I am a bit confused by this, as I have been by some of the other times > diagram interchange compliance has come up. > > Doesn't the UML Diagram Interchange specification have a > compliance section? > Isn't this where the compliance points for diagram > interchange should be? > > Just looking at this from the point of view of a user of the > OMG UML specs, > it seems confusing to have compliance for diagram interchange > in the UML > Superstructure spec, when that spec does not define diagram > interchange. > > I remember this being discussed at some FTF meeting a while > ago, but I must > admit I have not caught up on all the recent compliance > discussion. Is the > expectation that ALL compliance points for ALL the UML 2.0 > specifications be > defined in the Superstructure spec? (For example, what about OCL 2.0 > compliance?) > > -- Ed > > > -----Original Message----- > > From: Marko Boger [mailto:marko.boger@gentleware.com] > > Sent: Friday, August 20, 2004 10:38 AM > > To: cris.kobryn@telelogic.com; 'Karl Frank'; 'Pete Rivett'; > > 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > > mu2i-ftf@omg.org; ocl2-ftf@omg.org > > Cc: uml2di-ftf@omg.org > > Subject: Compliance points - Diagram Interchange. > > > > > > Gentlemen, > > > > From letters from Bran Selic and Pete Rivett I learn that the > > Superstructure FTF plans to revoke Diagram Interchange as a > > compliance point to UML 2 compliance. As the Chair of the > > Diagram Interchange FTF I urge you to make compliance Diagram > > Interchange a necessity for full compliance. > > > > In all discussions I attended it was always pointed out that > > the ability to exchange UML diagrams compliant to a standard > > using XMI was the single most important issue missing in UML > > 1. The Diagram Interchange specification was specifically > > designed to solve this problem. It is of essence that Diagram > > Interchange remains a part of UML 2 compliance. Otherwise the > > whole UML 2 standard is drastically reduces in its value. > > > > The Diagram Interchange specification is of high quality. It > > is fully implemented by Gentleware to provide a reference, we > > have made cross checks with various other vendors that > > confirm high quality and interchangability. May I also point > > out that Prof. Mario Jeckle, our friend we miss dearly, has > > implemented an XSLT transformation from XMI to SVG. It is > > available on his web site at www.jeckle.de. > > > > Regards, Marko Boger > > > > 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 > > > > Bran wrote: > > > > > I further note that Concrete Syntax compliance no longer > addresses > > > Diagram Interchange compliance, which Bran's 8/8/04 email > proposal > > > included (although the 8/8/04 draft referred to it as "UML Design > > > Interchange specification"). What happened here? Was this a > > publicly > > > discussed > > consensus > > > decision on a mailing list, or has the OMG formally dropped > > the UML 2 > > > DI specification? If UML 2 DI is still part of the UML 2 > > FAS quartet, > > > we need to address DI compliance in some sort of straightforward > > > manner. > > > > There was a public discussion on this point and the > > conclusion was to remove reference to DI compliance. This is > > because it was pointed out that DI elements have a pointer to > > model elements and are, therefore, it is not separable as an > > independent compliance type. Note that the other two > > compliance types are independent of each other. > > > > As for DI compliance, it is appropriate to declare that in > > the DI spec itself, rather than in the Superstructure (note > > that the coupling between these two specs is strictly one > > way: the DI depends on the superstructure but not the other > > way around). Unfortunately, that FTF is working at a > > different pace and it will likely require further delays > > before they are finished. > > > > > What to do? I am inclined to your support your point if we: > > 1) include > > > Diagram Interchange compliance; 2) explain clearly what the > > > implications > > of > > > using "Abstract Syntax", "Concrete Syntax", "Diagram > > Interchange" and > > > combinations of them are for lower levels. > > > > I am afraid that, with time running out, we no longer have > > the luxury to ponder these "what if" scenarios. We have to > > make a decision and the mechanism by which this is done in > > such circumstances is by voting. Therefore, I will be issuing > > the special compliance point ballot tomorrow morning with > > what I think represents the majority opinion of what this > > text should look like. I will do my best to incorporate all > > the feedback that was provided. If people feel that they can > > contribute to this, please forward me your suggestions. > > > > Cheers...Bran > > ----------------------------------- > > Pete wrote: > > > > > > Bran, > > In fact, as it stands, the DI spec does not depend on > > Superstructure - it just has a generic model element link > > which allows any sort of metamodel to have diagrams > > interchanged. Which is a good thing. Though it does have an > > Appendix A (which the FAS states needs to be updated by the > > FTF) covering how the model elements from Super are > > represented in the DI metamodel for specific diagram types. > > > > I think the DI spec should have a separate compliance point > > specifically for UML 2, requiring generic compliance to the > > DI spec (as in the current DI compliance point) and correct > > representation of the diagrams according to Appendix A for > > those diagram types supported by the tool (the statement of > > supported diagram types for the tool will be covered by its > > UML2 compliance statement). > > > > Pete > > > > ----------------------------------- > > Cris wrote: > > > > > Please do not propose adding DI compliance to the > > definition of UML 2 > > > compliance. > > > > We first need to explain why Diagram Interchange (DI) was > > abruptly dropped from the 8/8/04 compliance draft with no > > public explanation that I have read or heard. When and how > > was this decided? Please point me to public email or minutes, > > since I must have missed this... > > > > > Diagram Interchange is a separate spec with separate > > technology issues > > > surrounding its implementation. > > > > I disagree. Although DI has separate technical issues, it > > also has strongly related technology issues. In particular, > > DI's primary reason for existence is to exchange UML 2 > > diagrams between tools. Isn't this something UML 2 users will > > expect from a modeling tool standard? > > > > So are we as a standards body saying that Diagram Interchange > > is relevant or irrelevant for UML 2 Superstructure > > compliance? If it is the former, we need to explain its > > relevance; if it is the latter, let's explain why it is > > irrelevant and retire it. One way or the other, let's be clear! > > > > Thanks, > > > > Cris > > > > > > > > > -----Original Message----- > > > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > > > Sent: Thursday, August 19, 2004 1:03 PM > > > To: 'Pete Rivett'; cris.kobryn@telelogic.com; 'Branislav Selic'; > > > uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; > ocl2-ftf@omg.org > > > Subject: RE: Compliance points resolution proposal - > > "Feature Support > > > Statement" example > > > > > > > I'm not sure the Compliance Summary needs to list levels > > *beneath* > > > > that which compliance is claimed - since compliance at level N > > > > automatically implies/requires support at Level N-1 (start of > > > > section 1.3 of the new section states: "Compliance to a > > given level > > > > entails full realization of all language units that are > > defined for > > > > that compliance level (note that this implies > compliance with all > > > > levels > > > below it)." > > > > So, the example is not actually valid: it is not > possible to have > > > > Concrete Syntax compliance at Level 1 but not at Level 0. > > > > > > Although I am inclined to agree with your intention here, I > > disagree > > > that what you are saying is clearly explained by the current spec > > > draft. The sentence you cite is insufficient, since the > > section that > > > defines the "two distinct types of compliance" (section > > 1.3, par. 3) > > > does not explain what the individual or combined (i.e., > > "both") usage > > > of the distinct types implies for lower levels. > > > > > > I further note that Concrete Syntax compliance no longer > addresses > > > Diagram Interchange compliance, which Bran's 8/8/04 email > proposal > > > included (although the 8/8/04 draft referred to it as "UML Design > > > Interchange specification"). What happened here? Was this a > > publicly > > > discussed consensus decision on a mailing list, or has the OMG > > > formally dropped the UML 2 DI specification? If UML 2 DI is > > still part > > > of the UML 2 FAS quartet, we need to address DI > compliance in some > > > sort of straightforward manner. > > > > > > What to do? I am inclined to your support your point if we: > > 1) include > > > Diagram Interchange compliance; 2) explain clearly what the > > > implications of using "Abstract Syntax", "Concrete Syntax", > > "Diagram > > > Interchange" and combinations of them are for lower levels. > > > > > > > > > > > With respect to the feature support table I think we > (or a vendor > > > > claiming support)needs to have more definition of the > terms than, > > > > for example, 'Action Semantics' or 'Dynamic Semantics': > since the > > > > spec does not already define what it means to support dynamic > > > > semantics for > > > > > > > a package - which is one of the reasons it is not > included in the > > > > formal compliance levels. And 'Action Semantics' is even > > less clear > > > > (how does it differ from Dynamic Semantics for the Actions > > > package(s)?). > > > > > > I agree, and also think we can whack "Action Semantics". > > > > > > > Not sure it's necessary to have entries where no support > > is claimed, > > > > but I'm not that bothered. > > > > > > Good. > > > > > > > I think the section should include very specific examples > > of support > > > > for presentation options and semantic variation points: I > > think for > > > > these the table approach may become awkward which is why I > > > > originally suggested a semi-structured English > approach. Maybe we > > > > could have a table followed by semi-structured text for > > the latter? > > > > > > There should always be the option to elaborate on anything, > > and if we > > > want to add semi-structured text to further explain the > > example, I am > > > fine with that! > > > > > > Thanks, > > > > > > Cris > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > > > > > Sent: Thursday, August 19, 2004 1:56 AM > > > > > To: 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > > > > > mu2i-ftf@omg.org; ocl2-ftf@omg.org > > > > > Subject: RE: Compliance points resolution proposal - "Feature > > > > > Support Statement" example > > > > > > > > > > FTFers, > > > > > > > > > > Attached is an example of a "Feature Support Statement" > > (formerly > > > > > known as a"Compliance Support Statement") that Anders > > and I were > > > > > asked to generate during today's FTF telecon. > > > > > > > > > > Thanks to Bran and Pete for providing review feedback > > to improve > > > > > the > > > > > > > > example prior to sending it out to the mailing list. > > > > > > > > > > -- Cris > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > > > > > Sent: Tuesday, August 17, 2004 3:05 PM > > > > > > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; > > > > > ocl2-ftf@omg.org > > > > > > Subject: Compliance points resolution proposal > > > > > > > > > > > > > > > > > > After yet more cycles of the proposed resolution between > > > > > Anders and Pete > > > > > > and myself, attached, please find a copy of the proposed > > > > > resolution to the > > > > > > compliance point issue (6248). > > > > > > > > > > > > Since this is a gating issue, I would like to have a > > definitive > > > > > > FTF position on this specific resolution before the > > OMG meeting > > > > > in Montreal > > > > > > next week. This likely means having a special vote just on > > > > > this resolution > > > > > > outside the usual weekly cycle. > > > > > > > > > > > > Regards, > > > > > > Bran > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: "Thomas Weigert" To: "Pete Rivett" , "Marko Boger" , "Edwin Seidewitz" , , , Cc: Subject: RE: Compliance points - Diagram Interchange. Date: Mon, 23 Aug 2004 07:26:24 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) I think Marko makes a good point. He argues that the DI specification is a generic specification of interchanging any diagram, not just UML diagrams. Given that, a compliance point on a UML tool to exchange diagrams based on DI is indeed appropriate in the UML specification, rather than the DI specification. This is similar to other technologies the UML is based on, e.g., XMI. It is the UML that says that a tool has to comply to interchange the metamodel using XMI, not the XMI specification. Similarly, the UML should say that the tool has to comply to interchange the diagrams using DI. Of course, we could say that such compliance is not necessary, which is the current situation. However, that sends quite a strong statement. It would probably be better (and do no harm) to include compliance to interchange using DI amongst the UML compliance points. Th. > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: Monday, August 23, 2004 7:17 AM > To: Marko Boger; Edwin Seidewitz; uml2-superstructure-ftf@omg.org; > mu2i-ftf@omg.org; ocl2-ftf@omg.org > Cc: uml2di-ftf@omg.org > Subject: RE: Compliance points - Diagram Interchange. > > > The DI spec already contains an Appendix A that states how the > different UML 2 model elements map to DI elements when used on > specific UML2 Diagrams. > > As I already suggested in another mail why not have another > compliance point for DI that is UML2 specific and states that to > be compliant a tool must represent UML2 diagrams in this way. > > I disagree with Marko when he says 'to be compliant with DI > itself has no meaning': DI already has a single compliance point > though it could do with some refinement. This consists of just > importing/exporting instances of the DI metamodel (in association > with some other model be it UML or anything else). > > A further level of general compliance could be defined which is > 'rendering compliance' which would represent the ability to turn > the DI representation into a visual depiction. > > > > > -----Original Message----- > > From: Marko Boger [mailto:marko.boger@gentleware.com] > > Sent: Monday, August 23, 2004 4:25 AM > > To: 'Edwin Seidewitz'; uml2-superstructure-ftf@omg.org; > > mu2i-ftf@omg.org; ocl2-ftf@omg.org > > Cc: uml2di-ftf@omg.org > > Subject: AW: Compliance points - Diagram Interchange. > > > > Ed, everyone, > > > > the metamodel of Diagram Interchange contains some 20 > > classes. What should > > the compliance to Diagram Interchange be? A tool supports nodes but no > > edges? A tool either does support Diagram Interchange or it > > doesn't. So > > there are no compliance points within Diagram Interchange itself. > > > > The Metamodel of Diagram Interchange (DI) can be applied to > > UML 1 or UML 2. > > In fact, it could be used for any graphical notation that is > > graph-oriented > > (as UML is). It talks about nodes and edges, nesting and > > adornments. Every > > diagram element can have one unidirectional link to the > > semantic model (a > > node to a class, use case or actor etc., and an edge to an > > association, > > dependency or inheritance etc.). > > > > To be compliant to DI by itself has no meaning. It only > > becomes relevant as > > the interchange format for a graphical notation. In the > > definition of our > > graphical notation UML we can choose to use DI as the mechanism to > > interchange diagram and layout information or we can choose > > not to. UML 1 > > was lacking this interchange mechanism and it is my > > understanding that the > > RFP for UML 2 and the AB made it a requirement for UML 2 to > > support such an > > interchange mechanism. > > > > So the compliance should be in the UML specification. UML 2 > > should make it a > > necessity for a tool to export to XMI including DI to be > > fully compliant. > > Otherwise UML 2 models are simply not interchangeable. > > > > 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 > > > > -----Ursprüngliche Nachricht----- > > Von: Edwin Seidewitz [mailto:eseidewitz@intelidata.com] > > Gesendet: Freitag, 20. August 2004 16:54 > > An: 'Marko Boger'; 'uml2-superstructure-ftf@omg.org'; > > 'mu2i-ftf@omg.org'; > > 'ocl2-ftf@omg.org' > > Cc: 'uml2di-ftf@omg.org' > > Betreff: RE: Compliance points - Diagram Interchange. > > > > Marko -- > > > > I am a bit confused by this, as I have been by some of the other times > > diagram interchange compliance has come up. > > > > Doesn't the UML Diagram Interchange specification have a > > compliance section? > > Isn't this where the compliance points for diagram > > interchange should be? > > > > Just looking at this from the point of view of a user of the > > OMG UML specs, > > it seems confusing to have compliance for diagram interchange > > in the UML > > Superstructure spec, when that spec does not define diagram > > interchange. > > > > I remember this being discussed at some FTF meeting a while > > ago, but I must > > admit I have not caught up on all the recent compliance > > discussion. Is the > > expectation that ALL compliance points for ALL the UML 2.0 > > specifications be > > defined in the Superstructure spec? (For example, what about OCL 2.0 > > compliance?) > > > > -- Ed > > > > > -----Original Message----- > > > From: Marko Boger [mailto:marko.boger@gentleware.com] > > > Sent: Friday, August 20, 2004 10:38 AM > > > To: cris.kobryn@telelogic.com; 'Karl Frank'; 'Pete Rivett'; > > > 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > > > mu2i-ftf@omg.org; ocl2-ftf@omg.org > > > Cc: uml2di-ftf@omg.org > > > Subject: Compliance points - Diagram Interchange. > > > > > > > > > Gentlemen, > > > > > > From letters from Bran Selic and Pete Rivett I learn that the > > > Superstructure FTF plans to revoke Diagram Interchange as a > > > compliance point to UML 2 compliance. As the Chair of the > > > Diagram Interchange FTF I urge you to make compliance Diagram > > > Interchange a necessity for full compliance. > > > > > > In all discussions I attended it was always pointed out that > > > the ability to exchange UML diagrams compliant to a standard > > > using XMI was the single most important issue missing in UML > > > 1. The Diagram Interchange specification was specifically > > > designed to solve this problem. It is of essence that Diagram > > > Interchange remains a part of UML 2 compliance. Otherwise the > > > whole UML 2 standard is drastically reduces in its value. > > > > > > The Diagram Interchange specification is of high quality. It > > > is fully implemented by Gentleware to provide a reference, we > > > have made cross checks with various other vendors that > > > confirm high quality and interchangability. May I also point > > > out that Prof. Mario Jeckle, our friend we miss dearly, has > > > implemented an XSLT transformation from XMI to SVG. It is > > > available on his web site at www.jeckle.de. > > > > > > Regards, Marko Boger > > > > > > 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 > > > > > > Bran wrote: > > > > > > > I further note that Concrete Syntax compliance no longer > > addresses > > > > Diagram Interchange compliance, which Bran's 8/8/04 email > > proposal > > > > included (although the 8/8/04 draft referred to it as "UML Design > > > > Interchange specification"). What happened here? Was this a > > > publicly > > > > discussed > > > consensus > > > > decision on a mailing list, or has the OMG formally dropped > > > the UML 2 > > > > DI specification? If UML 2 DI is still part of the UML 2 > > > FAS quartet, > > > > we need to address DI compliance in some sort of straightforward > > > > manner. > > > > > > There was a public discussion on this point and the > > > conclusion was to remove reference to DI compliance. This is > > > because it was pointed out that DI elements have a pointer to > > > model elements and are, therefore, it is not separable as an > > > independent compliance type. Note that the other two > > > compliance types are independent of each other. > > > > > > As for DI compliance, it is appropriate to declare that in > > > the DI spec itself, rather than in the Superstructure (note > > > that the coupling between these two specs is strictly one > > > way: the DI depends on the superstructure but not the other > > > way around). Unfortunately, that FTF is working at a > > > different pace and it will likely require further delays > > > before they are finished. > > > > > > > What to do? I am inclined to your support your point if we: > > > 1) include > > > > Diagram Interchange compliance; 2) explain clearly what the > > > > implications > > > of > > > > using "Abstract Syntax", "Concrete Syntax", "Diagram > > > Interchange" and > > > > combinations of them are for lower levels. > > > > > > I am afraid that, with time running out, we no longer have > > > the luxury to ponder these "what if" scenarios. We have to > > > make a decision and the mechanism by which this is done in > > > such circumstances is by voting. Therefore, I will be issuing > > > the special compliance point ballot tomorrow morning with > > > what I think represents the majority opinion of what this > > > text should look like. I will do my best to incorporate all > > > the feedback that was provided. If people feel that they can > > > contribute to this, please forward me your suggestions. > > > > > > Cheers...Bran > > > ----------------------------------- > > > Pete wrote: > > > > > > > > > Bran, > > > In fact, as it stands, the DI spec does not depend on > > > Superstructure - it just has a generic model element link > > > which allows any sort of metamodel to have diagrams > > > interchanged. Which is a good thing. Though it does have an > > > Appendix A (which the FAS states needs to be updated by the > > > FTF) covering how the model elements from Super are > > > represented in the DI metamodel for specific diagram types. > > > > > > I think the DI spec should have a separate compliance point > > > specifically for UML 2, requiring generic compliance to the > > > DI spec (as in the current DI compliance point) and correct > > > representation of the diagrams according to Appendix A for > > > those diagram types supported by the tool (the statement of > > > supported diagram types for the tool will be covered by its > > > UML2 compliance statement). > > > > > > Pete > > > > > > ----------------------------------- > > > Cris wrote: > > > > > > > Please do not propose adding DI compliance to the > > > definition of UML 2 > > > > compliance. > > > > > > We first need to explain why Diagram Interchange (DI) was > > > abruptly dropped from the 8/8/04 compliance draft with no > > > public explanation that I have read or heard. When and how > > > was this decided? Please point me to public email or minutes, > > > since I must have missed this... > > > > > > > Diagram Interchange is a separate spec with separate > > > technology issues > > > > surrounding its implementation. > > > > > > I disagree. Although DI has separate technical issues, it > > > also has strongly related technology issues. In particular, > > > DI's primary reason for existence is to exchange UML 2 > > > diagrams between tools. Isn't this something UML 2 users will > > > expect from a modeling tool standard? > > > > > > So are we as a standards body saying that Diagram Interchange > > > is relevant or irrelevant for UML 2 Superstructure > > > compliance? If it is the former, we need to explain its > > > relevance; if it is the latter, let's explain why it is > > > irrelevant and retire it. One way or the other, let's be clear! > > > > > > Thanks, > > > > > > Cris > > > > > > > > > > > > > -----Original Message----- > > > > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > > > > Sent: Thursday, August 19, 2004 1:03 PM > > > > To: 'Pete Rivett'; cris.kobryn@telelogic.com; 'Branislav Selic'; > > > > uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; > > ocl2-ftf@omg.org > > > > Subject: RE: Compliance points resolution proposal - > > > "Feature Support > > > > Statement" example > > > > > > > > > I'm not sure the Compliance Summary needs to list levels > > > *beneath* > > > > > that which compliance is claimed - since compliance at level N > > > > > automatically implies/requires support at Level N-1 (start of > > > > > section 1.3 of the new section states: "Compliance to a > > > given level > > > > > entails full realization of all language units that are > > > defined for > > > > > that compliance level (note that this implies > > compliance with all > > > > > levels > > > > below it)." > > > > > So, the example is not actually valid: it is not > > possible to have > > > > > Concrete Syntax compliance at Level 1 but not at Level 0. > > > > > > > > Although I am inclined to agree with your intention here, I > > > disagree > > > > that what you are saying is clearly explained by the current spec > > > > draft. The sentence you cite is insufficient, since the > > > section that > > > > defines the "two distinct types of compliance" (section > > > 1.3, par. 3) > > > > does not explain what the individual or combined (i.e., > > > "both") usage > > > > of the distinct types implies for lower levels. > > > > > > > > I further note that Concrete Syntax compliance no longer > > addresses > > > > Diagram Interchange compliance, which Bran's 8/8/04 email > > proposal > > > > included (although the 8/8/04 draft referred to it as "UML Design > > > > Interchange specification"). What happened here? Was this a > > > publicly > > > > discussed consensus decision on a mailing list, or has the OMG > > > > formally dropped the UML 2 DI specification? If UML 2 DI is > > > still part > > > > of the UML 2 FAS quartet, we need to address DI > > compliance in some > > > > sort of straightforward manner. > > > > > > > > What to do? I am inclined to your support your point if we: > > > 1) include > > > > Diagram Interchange compliance; 2) explain clearly what the > > > > implications of using "Abstract Syntax", "Concrete Syntax", > > > "Diagram > > > > Interchange" and combinations of them are for lower levels. > > > > > > > > > > > > > > With respect to the feature support table I think we > > (or a vendor > > > > > claiming support)needs to have more definition of the > > terms than, > > > > > for example, 'Action Semantics' or 'Dynamic Semantics': > > since the > > > > > spec does not already define what it means to support dynamic > > > > > semantics for > > > > > > > > > a package - which is one of the reasons it is not > > included in the > > > > > formal compliance levels. And 'Action Semantics' is even > > > less clear > > > > > (how does it differ from Dynamic Semantics for the Actions > > > > package(s)?). > > > > > > > > I agree, and also think we can whack "Action Semantics". > > > > > > > > > Not sure it's necessary to have entries where no support > > > is claimed, > > > > > but I'm not that bothered. > > > > > > > > Good. > > > > > > > > > I think the section should include very specific examples > > > of support > > > > > for presentation options and semantic variation points: I > > > think for > > > > > these the table approach may become awkward which is why I > > > > > originally suggested a semi-structured English > > approach. Maybe we > > > > > could have a table followed by semi-structured text for > > > the latter? > > > > > > > > There should always be the option to elaborate on anything, > > > and if we > > > > want to add semi-structured text to further explain the > > > example, I am > > > > fine with that! > > > > > > > > Thanks, > > > > > > > > Cris > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > > > > > > Sent: Thursday, August 19, 2004 1:56 AM > > > > > > To: 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > > > > > > mu2i-ftf@omg.org; ocl2-ftf@omg.org > > > > > > Subject: RE: Compliance points resolution proposal - "Feature > > > > > > Support Statement" example > > > > > > > > > > > > FTFers, > > > > > > > > > > > > Attached is an example of a "Feature Support Statement" > > > (formerly > > > > > > known as a"Compliance Support Statement") that Anders > > > and I were > > > > > > asked to generate during today's FTF telecon. > > > > > > > > > > > > Thanks to Bran and Pete for providing review feedback > > > to improve > > > > > > the > > > > > > > > > > example prior to sending it out to the mailing list. > > > > > > > > > > > > -- Cris > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > > > > > > Sent: Tuesday, August 17, 2004 3:05 PM > > > > > > > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; > > > > > > ocl2-ftf@omg.org > > > > > > > Subject: Compliance points resolution proposal > > > > > > > > > > > > > > > > > > > > > After yet more cycles of the proposed resolution between > > > > > > Anders and Pete > > > > > > > and myself, attached, please find a copy of the proposed > > > > > > resolution to the > > > > > > > compliance point issue (6248). > > > > > > > > > > > > > > Since this is a gating issue, I would like to have a > > > definitive > > > > > > > FTF position on this specific resolution before the > > > OMG meeting > > > > > > in Montreal > > > > > > > next week. This likely means having a special vote just on > > > > > > this resolution > > > > > > > outside the usual weekly cycle. > > > > > > > > > > > > > > Regards, > > > > > > > Bran > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reply-To: From: "Desfray" To: "'Marko Boger'" , "'Edwin Seidewitz'" , , , Cc: Subject: RE: Compliance points - Diagram Interchange. Date: Mon, 23 Aug 2004 14:29:55 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-Virus-Scanned: by amavisd-new at softeam.com Let me second Marco's point here: for most users, it has no sense interchanging models without diagrams. The XMI interchange of UML models should include the diagram interchange. ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Marko Boger [mailto:marko.boger@gentleware.com] Envoyé : lundi 23 aoűt 2004 10:25 Ŕ : 'Edwin Seidewitz'; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Cc : uml2di-ftf@omg.org Objet : AW: Compliance points - Diagram Interchange. Ed, everyone, the metamodel of Diagram Interchange contains some 20 classes. What should the compliance to Diagram Interchange be? A tool supports nodes but no edges? A tool either does support Diagram Interchange or it doesn't. So there are no compliance points within Diagram Interchange itself. The Metamodel of Diagram Interchange (DI) can be applied to UML 1 or UML 2. In fact, it could be used for any graphical notation that is graph-oriented (as UML is). It talks about nodes and edges, nesting and adornments. Every diagram element can have one unidirectional link to the semantic model (a node to a class, use case or actor etc., and an edge to an association, dependency or inheritance etc.). To be compliant to DI by itself has no meaning. It only becomes relevant as the interchange format for a graphical notation. In the definition of our graphical notation UML we can choose to use DI as the mechanism to interchange diagram and layout information or we can choose not to. UML 1 was lacking this interchange mechanism and it is my understanding that the RFP for UML 2 and the AB made it a requirement for UML 2 to support such an interchange mechanism. So the compliance should be in the UML specification. UML 2 should make it a necessity for a tool to export to XMI including DI to be fully compliant. Otherwise UML 2 models are simply not interchangeable. 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 -----Ursprüngliche Nachricht----- Von: Edwin Seidewitz [mailto:eseidewitz@intelidata.com] Gesendet: Freitag, 20. August 2004 16:54 An: 'Marko Boger'; 'uml2-superstructure-ftf@omg.org'; 'mu2i-ftf@omg.org'; 'ocl2-ftf@omg.org' Cc: 'uml2di-ftf@omg.org' Betreff: RE: Compliance points - Diagram Interchange. Marko -- I am a bit confused by this, as I have been by some of the other times diagram interchange compliance has come up. Doesn't the UML Diagram Interchange specification have a compliance section? Isn't this where the compliance points for diagram interchange should be? Just looking at this from the point of view of a user of the OMG UML specs, it seems confusing to have compliance for diagram interchange in the UML Superstructure spec, when that spec does not define diagram interchange. I remember this being discussed at some FTF meeting a while ago, but I must admit I have not caught up on all the recent compliance discussion. Is the expectation that ALL compliance points for ALL the UML 2.0 specifications be defined in the Superstructure spec? (For example, what about OCL 2.0 compliance?) -- Ed > -----Original Message----- > From: Marko Boger [mailto:marko.boger@gentleware.com] > Sent: Friday, August 20, 2004 10:38 AM > To: cris.kobryn@telelogic.com; 'Karl Frank'; 'Pete Rivett'; > 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > mu2i-ftf@omg.org; ocl2-ftf@omg.org > Cc: uml2di-ftf@omg.org > Subject: Compliance points - Diagram Interchange. > > > Gentlemen, > > From letters from Bran Selic and Pete Rivett I learn that the > Superstructure FTF plans to revoke Diagram Interchange as a > compliance point to UML 2 compliance. As the Chair of the > Diagram Interchange FTF I urge you to make compliance Diagram > Interchange a necessity for full compliance. > > In all discussions I attended it was always pointed out that > the ability to exchange UML diagrams compliant to a standard > using XMI was the single most important issue missing in UML > 1. The Diagram Interchange specification was specifically > designed to solve this problem. It is of essence that Diagram > Interchange remains a part of UML 2 compliance. Otherwise the > whole UML 2 standard is drastically reduces in its value. > > The Diagram Interchange specification is of high quality. It > is fully implemented by Gentleware to provide a reference, we > have made cross checks with various other vendors that > confirm high quality and interchangability. May I also point > out that Prof. Mario Jeckle, our friend we miss dearly, has > implemented an XSLT transformation from XMI to SVG. It is > available on his web site at www.jeckle.de. > > Regards, Marko Boger > > 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 > > Bran wrote: > > > I further note that Concrete Syntax compliance no longer addresses > > Diagram Interchange compliance, which Bran's 8/8/04 email proposal > > included (although the 8/8/04 draft referred to it as "UML Design > > Interchange specification"). What happened here? Was this a > publicly > > discussed > consensus > > decision on a mailing list, or has the OMG formally dropped > the UML 2 > > DI specification? If UML 2 DI is still part of the UML 2 > FAS quartet, > > we need to address DI compliance in some sort of straightforward > > manner. > > There was a public discussion on this point and the > conclusion was to remove reference to DI compliance. This is > because it was pointed out that DI elements have a pointer to > model elements and are, therefore, it is not separable as an > independent compliance type. Note that the other two > compliance types are independent of each other. > > As for DI compliance, it is appropriate to declare that in > the DI spec itself, rather than in the Superstructure (note > that the coupling between these two specs is strictly one > way: the DI depends on the superstructure but not the other > way around). Unfortunately, that FTF is working at a > different pace and it will likely require further delays > before they are finished. > > > What to do? I am inclined to your support your point if we: > 1) include > > Diagram Interchange compliance; 2) explain clearly what the > > implications > of > > using "Abstract Syntax", "Concrete Syntax", "Diagram > Interchange" and > > combinations of them are for lower levels. > > I am afraid that, with time running out, we no longer have > the luxury to ponder these "what if" scenarios. We have to > make a decision and the mechanism by which this is done in > such circumstances is by voting. Therefore, I will be issuing > the special compliance point ballot tomorrow morning with > what I think represents the majority opinion of what this > text should look like. I will do my best to incorporate all > the feedback that was provided. If people feel that they can > contribute to this, please forward me your suggestions. > > Cheers...Bran > ----------------------------------- > Pete wrote: > > > Bran, > In fact, as it stands, the DI spec does not depend on > Superstructure - it just has a generic model element link > which allows any sort of metamodel to have diagrams > interchanged. Which is a good thing. Though it does have an > Appendix A (which the FAS states needs to be updated by the > FTF) covering how the model elements from Super are > represented in the DI metamodel for specific diagram types. > > I think the DI spec should have a separate compliance point > specifically for UML 2, requiring generic compliance to the > DI spec (as in the current DI compliance point) and correct > representation of the diagrams according to Appendix A for > those diagram types supported by the tool (the statement of > supported diagram types for the tool will be covered by its > UML2 compliance statement). > > Pete > > ----------------------------------- > Cris wrote: > > > Please do not propose adding DI compliance to the > definition of UML 2 > > compliance. > > We first need to explain why Diagram Interchange (DI) was > abruptly dropped from the 8/8/04 compliance draft with no > public explanation that I have read or heard. When and how > was this decided? Please point me to public email or minutes, > since I must have missed this... > > > Diagram Interchange is a separate spec with separate > technology issues > > surrounding its implementation. > > I disagree. Although DI has separate technical issues, it > also has strongly related technology issues. In particular, > DI's primary reason for existence is to exchange UML 2 > diagrams between tools. Isn't this something UML 2 users will > expect from a modeling tool standard? > > So are we as a standards body saying that Diagram Interchange > is relevant or irrelevant for UML 2 Superstructure > compliance? If it is the former, we need to explain its > relevance; if it is the latter, let's explain why it is > irrelevant and retire it. One way or the other, let's be clear! > > Thanks, > > Cris > > > > > -----Original Message----- > > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > > Sent: Thursday, August 19, 2004 1:03 PM > > To: 'Pete Rivett'; cris.kobryn@telelogic.com; 'Branislav Selic'; > > uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > > Subject: RE: Compliance points resolution proposal - > "Feature Support > > Statement" example > > > > > I'm not sure the Compliance Summary needs to list levels > *beneath* > > > that which compliance is claimed - since compliance at level N > > > automatically implies/requires support at Level N-1 (start of > > > section 1.3 of the new section states: "Compliance to a > given level > > > entails full realization of all language units that are > defined for > > > that compliance level (note that this implies compliance with all > > > levels > > below it)." > > > So, the example is not actually valid: it is not possible to have > > > Concrete Syntax compliance at Level 1 but not at Level 0. > > > > Although I am inclined to agree with your intention here, I > disagree > > that what you are saying is clearly explained by the current spec > > draft. The sentence you cite is insufficient, since the > section that > > defines the "two distinct types of compliance" (section > 1.3, par. 3) > > does not explain what the individual or combined (i.e., > "both") usage > > of the distinct types implies for lower levels. > > > > I further note that Concrete Syntax compliance no longer addresses > > Diagram Interchange compliance, which Bran's 8/8/04 email proposal > > included (although the 8/8/04 draft referred to it as "UML Design > > Interchange specification"). What happened here? Was this a > publicly > > discussed consensus decision on a mailing list, or has the OMG > > formally dropped the UML 2 DI specification? If UML 2 DI is > still part > > of the UML 2 FAS quartet, we need to address DI compliance in some > > sort of straightforward manner. > > > > What to do? I am inclined to your support your point if we: > 1) include > > Diagram Interchange compliance; 2) explain clearly what the > > implications of using "Abstract Syntax", "Concrete Syntax", > "Diagram > > Interchange" and combinations of them are for lower levels. > > > > > > > > With respect to the feature support table I think we (or a vendor > > > claiming support)needs to have more definition of the terms than, > > > for example, 'Action Semantics' or 'Dynamic Semantics': since the > > > spec does not already define what it means to support dynamic > > > semantics for > > > > > a package - which is one of the reasons it is not included in the > > > formal compliance levels. And 'Action Semantics' is even > less clear > > > (how does it differ from Dynamic Semantics for the Actions > > package(s)?). > > > > I agree, and also think we can whack "Action Semantics". > > > > > Not sure it's necessary to have entries where no support > is claimed, > > > but I'm not that bothered. > > > > Good. > > > > > I think the section should include very specific examples > of support > > > for presentation options and semantic variation points: I > think for > > > these the table approach may become awkward which is why I > > > originally suggested a semi-structured English approach. Maybe we > > > could have a table followed by semi-structured text for > the latter? > > > > There should always be the option to elaborate on anything, > and if we > > want to add semi-structured text to further explain the > example, I am > > fine with that! > > > > Thanks, > > > > Cris > > > > > > > > > > > > -----Original Message----- > > > > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > > > > Sent: Thursday, August 19, 2004 1:56 AM > > > > To: 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > > > > mu2i-ftf@omg.org; ocl2-ftf@omg.org > > > > Subject: RE: Compliance points resolution proposal - "Feature > > > > Support Statement" example > > > > > > > > FTFers, > > > > > > > > Attached is an example of a "Feature Support Statement" > (formerly > > > > known as a"Compliance Support Statement") that Anders > and I were > > > > asked to generate during today's FTF telecon. > > > > > > > > Thanks to Bran and Pete for providing review feedback > to improve > > > > the > > > > > > example prior to sending it out to the mailing list. > > > > > > > > -- Cris > > > > > > > > > > > > > -----Original Message----- > > > > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > > > > Sent: Tuesday, August 17, 2004 3:05 PM > > > > > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; > > > > ocl2-ftf@omg.org > > > > > Subject: Compliance points resolution proposal > > > > > > > > > > > > > > > After yet more cycles of the proposed resolution between > > > > Anders and Pete > > > > > and myself, attached, please find a copy of the proposed > > > > resolution to the > > > > > compliance point issue (6248). > > > > > > > > > > Since this is a gating issue, I would like to have a > definitive > > > > > FTF position on this specific resolution before the > OMG meeting > > > > in Montreal > > > > > next week. This likely means having a special vote just on > > > > this resolution > > > > > outside the usual weekly cycle. > > > > > > > > > > Regards, > > > > > Bran > > > > > > > > > > > > > > > > > > > > > > > >To: Cc: "'Edwin Seidewitz'" , "'Marko Boger'" , mu2i-ftf@omg.org, ocl2-ftf@omg.org, uml2-superstructure-ftf@omg.org, uml2di-ftf@omg.org Subject: RE: Compliance points - Diagram Interchange. X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Mon, 23 Aug 2004 09:48:23 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/23/2004 07:48:25, Serialize complete at 08/23/2004 07:48:25 I see Marco's point, but don't think it is necessary to couple UML model interchange with diagram interchange. MDA does not rely on diagram interchange, but it will rely on model interchange. There are also more many notation options that will need to be addressed, perhaps with their own compliance levels, before UML diagram interchange will be reliable. Subject: RE: Compliance points - Diagram Interchange. Date: Mon, 23 Aug 2004 10:01:11 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance points - Diagram Interchange. Thread-Index: AcSJEcJlhwq0yqoBT+axyBcbSMBLJAABdyVw From: "Pete Rivett" To: , "Marko Boger" , "Edwin Seidewitz" , , , Cc: X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7NE4nlj011489 It depends on the context: when thinking about tool chains with transformation engines, code generators etc then diagrams are an irrelevance and unnecessary clutter. Similarly for UML generated from other tools such as business modeling tools. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: "Thomas Weigert" To: "Pete Rivett" , , "Marko Boger" , "Edwin Seidewitz" , , , Cc: Subject: RE: Compliance points - Diagram Interchange. Date: Mon, 23 Aug 2004 09:02:02 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Pete, I think we cannot have it both ways. On the one hand we argue that we need a compliance point that is such a low hurdle it does not even qualify as UML (L0), on the other hand are saying that users are so sophisticated they don't need diagrams any more. In addition, in particular where diagrams are the assets (users never think in terms of the metamodel) rather than the code, the interchange of diagrams between tools becomes crucial. This is an experience I can confirm from the earlier standardization of SDL. Having the ability to interchange diagrams between tools was considered essential by the users. Th. > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: Monday, August 23, 2004 9:01 AM > To: Philippe.Desfray@softeam.fr; Marko Boger; Edwin Seidewitz; > uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > Cc: uml2di-ftf@omg.org > Subject: RE: Compliance points - Diagram Interchange. > > > It depends on the context: when thinking about tool chains with > transformation engines, code generators etc then diagrams are an > irrelevance and unnecessary clutter. Similarly for UML generated > from other tools such as business modeling tools. > > > > -----Original Message----- > > From: Desfray [mailto:Philippe.Desfray@softeam.fr] > > Sent: Monday, August 23, 2004 8:30 AM > > To: 'Marko Boger'; 'Edwin Seidewitz'; > > uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > > Cc: uml2di-ftf@omg.org > > Subject: RE: Compliance points - Diagram Interchange. > > > > Let me second Marco's point here: for most users, it has no sense > > interchanging models without diagrams. The XMI interchange of > > UML models > > should include the diagram interchange. > > > > > > -----Message d'origine----- > > De : Marko Boger [mailto:marko.boger@gentleware.com] > > Envoyé : lundi 23 aoűt 2004 10:25 > > Ŕ : 'Edwin Seidewitz'; uml2-superstructure-ftf@omg.org; > > mu2i-ftf@omg.org; ocl2-ftf@omg.org > > Cc : uml2di-ftf@omg.org > > Objet : AW: Compliance points - Diagram Interchange. > > > > > > Ed, everyone, > > > > the metamodel of Diagram Interchange contains some 20 > > classes. What should > > the compliance to Diagram Interchange be? A tool supports nodes but no > > edges? A tool either does support Diagram Interchange or it > > doesn't. So > > there are no compliance points within Diagram Interchange itself. > > > > The Metamodel of Diagram Interchange (DI) can be applied to > > UML 1 or UML 2. > > In fact, it could be used for any graphical notation that is > > graph-oriented > > (as UML is). It talks about nodes and edges, nesting and > > adornments. Every > > diagram element can have one unidirectional link to the > > semantic model (a > > node to a class, use case or actor etc., and an edge to an > > association, > > dependency or inheritance etc.). > > > > To be compliant to DI by itself has no meaning. It only > > becomes relevant as > > the interchange format for a graphical notation. In the > > definition of our > > graphical notation UML we can choose to use DI as the mechanism to > > interchange diagram and layout information or we can choose > > not to. UML 1 > > was lacking this interchange mechanism and it is my > > understanding that the > > RFP for UML 2 and the AB made it a requirement for UML 2 to > > support such an > > interchange mechanism. > > > > So the compliance should be in the UML specification. UML 2 > > should make it a > > necessity for a tool to export to XMI including DI to be > > fully compliant. > > Otherwise UML 2 models are simply not interchangeable. > > > > 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 > > > > -----Ursprüngliche Nachricht----- > > Von: Edwin Seidewitz [mailto:eseidewitz@intelidata.com] > > Gesendet: Freitag, 20. August 2004 16:54 > > An: 'Marko Boger'; 'uml2-superstructure-ftf@omg.org'; > > 'mu2i-ftf@omg.org'; > > 'ocl2-ftf@omg.org' > > Cc: 'uml2di-ftf@omg.org' > > Betreff: RE: Compliance points - Diagram Interchange. > > > > Marko -- > > > > I am a bit confused by this, as I have been by some of the other times > > diagram interchange compliance has come up. > > > > Doesn't the UML Diagram Interchange specification have a > > compliance section? > > Isn't this where the compliance points for diagram > > interchange should be? > > > > Just looking at this from the point of view of a user of the > > OMG UML specs, > > it seems confusing to have compliance for diagram interchange > > in the UML > > Superstructure spec, when that spec does not define diagram > > interchange. > > > > I remember this being discussed at some FTF meeting a while > > ago, but I must > > admit I have not caught up on all the recent compliance > > discussion. Is the > > expectation that ALL compliance points for ALL the UML 2.0 > > specifications be > > defined in the Superstructure spec? (For example, what about OCL 2.0 > > compliance?) > > > > -- Ed > > > > > -----Original Message----- > > > From: Marko Boger [mailto:marko.boger@gentleware.com] > > > Sent: Friday, August 20, 2004 10:38 AM > > > To: cris.kobryn@telelogic.com; 'Karl Frank'; 'Pete Rivett'; > > > 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > > > mu2i-ftf@omg.org; ocl2-ftf@omg.org > > > Cc: uml2di-ftf@omg.org > > > Subject: Compliance points - Diagram Interchange. > > > > > > > > > Gentlemen, > > > > > > From letters from Bran Selic and Pete Rivett I learn that the > > > Superstructure FTF plans to revoke Diagram Interchange as a > > > compliance point to UML 2 compliance. As the Chair of the > > > Diagram Interchange FTF I urge you to make compliance Diagram > > > Interchange a necessity for full compliance. > > > > > > In all discussions I attended it was always pointed out that > > > the ability to exchange UML diagrams compliant to a standard > > > using XMI was the single most important issue missing in UML > > > 1. The Diagram Interchange specification was specifically > > > designed to solve this problem. It is of essence that Diagram > > > Interchange remains a part of UML 2 compliance. Otherwise the > > > whole UML 2 standard is drastically reduces in its value. > > > > > > The Diagram Interchange specification is of high quality. It > > > is fully implemented by Gentleware to provide a reference, we > > > have made cross checks with various other vendors that > > > confirm high quality and interchangability. May I also point > > > out that Prof. Mario Jeckle, our friend we miss dearly, has > > > implemented an XSLT transformation from XMI to SVG. It is > > > available on his web site at www.jeckle.de. > > > > > > Regards, Marko Boger > > > > > > 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 > > > > > > Bran wrote: > > > > > > > I further note that Concrete Syntax compliance no longer addresses > > > > Diagram Interchange compliance, which Bran's 8/8/04 email proposal > > > > included (although the 8/8/04 draft referred to it as "UML Design > > > > Interchange specification"). What happened here? Was this a > > > publicly > > > > discussed > > > consensus > > > > decision on a mailing list, or has the OMG formally dropped > > > the UML 2 > > > > DI specification? If UML 2 DI is still part of the UML 2 > > > FAS quartet, > > > > we need to address DI compliance in some sort of straightforward > > > > manner. > > > > > > There was a public discussion on this point and the > > > conclusion was to remove reference to DI compliance. This is > > > because it was pointed out that DI elements have a pointer to > > > model elements and are, therefore, it is not separable as an > > > independent compliance type. Note that the other two > > > compliance types are independent of each other. > > > > > > As for DI compliance, it is appropriate to declare that in > > > the DI spec itself, rather than in the Superstructure (note > > > that the coupling between these two specs is strictly one > > > way: the DI depends on the superstructure but not the other > > > way around). Unfortunately, that FTF is working at a > > > different pace and it will likely require further delays > > > before they are finished. > > > > > > > What to do? I am inclined to your support your point if we: > > > 1) include > > > > Diagram Interchange compliance; 2) explain clearly what the > > > > implications > > > of > > > > using "Abstract Syntax", "Concrete Syntax", "Diagram > > > Interchange" and > > > > combinations of them are for lower levels. > > > > > > I am afraid that, with time running out, we no longer have > > > the luxury to ponder these "what if" scenarios. We have to > > > make a decision and the mechanism by which this is done in > > > such circumstances is by voting. Therefore, I will be issuing > > > the special compliance point ballot tomorrow morning with > > > what I think represents the majority opinion of what this > > > text should look like. I will do my best to incorporate all > > > the feedback that was provided. If people feel that they can > > > contribute to this, please forward me your suggestions. > > > > > > Cheers...Bran > > > ----------------------------------- > > > Pete wrote: > > > > > > > > > Bran, > > > In fact, as it stands, the DI spec does not depend on > > > Superstructure - it just has a generic model element link > > > which allows any sort of metamodel to have diagrams > > > interchanged. Which is a good thing. Though it does have an > > > Appendix A (which the FAS states needs to be updated by the > > > FTF) covering how the model elements from Super are > > > represented in the DI metamodel for specific diagram types. > > > > > > I think the DI spec should have a separate compliance point > > > specifically for UML 2, requiring generic compliance to the > > > DI spec (as in the current DI compliance point) and correct > > > representation of the diagrams according to Appendix A for > > > those diagram types supported by the tool (the statement of > > > supported diagram types for the tool will be covered by its > > > UML2 compliance statement). > > > > > > Pete > > > > > > ----------------------------------- > > > Cris wrote: > > > > > > > Please do not propose adding DI compliance to the > > > definition of UML 2 > > > > compliance. > > > > > > We first need to explain why Diagram Interchange (DI) was > > > abruptly dropped from the 8/8/04 compliance draft with no > > > public explanation that I have read or heard. When and how > > > was this decided? Please point me to public email or minutes, > > > since I must have missed this... > > > > > > > Diagram Interchange is a separate spec with separate > > > technology issues > > > > surrounding its implementation. > > > > > > I disagree. Although DI has separate technical issues, it > > > also has strongly related technology issues. In particular, > > > DI's primary reason for existence is to exchange UML 2 > > > diagrams between tools. Isn't this something UML 2 users will > > > expect from a modeling tool standard? > > > > > > So are we as a standards body saying that Diagram Interchange > > > is relevant or irrelevant for UML 2 Superstructure > > > compliance? If it is the former, we need to explain its > > > relevance; if it is the latter, let's explain why it is > > > irrelevant and retire it. One way or the other, let's be clear! > > > > > > Thanks, > > > > > > Cris > > > > > > > > > > > > > -----Original Message----- > > > > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > > > > Sent: Thursday, August 19, 2004 1:03 PM > > > > To: 'Pete Rivett'; cris.kobryn@telelogic.com; 'Branislav Selic'; > > > > uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; > > ocl2-ftf@omg.org > > > > Subject: RE: Compliance points resolution proposal - > > > "Feature Support > > > > Statement" example > > > > > > > > > I'm not sure the Compliance Summary needs to list levels > > > *beneath* > > > > > that which compliance is claimed - since compliance at level N > > > > > automatically implies/requires support at Level N-1 (start of > > > > > section 1.3 of the new section states: "Compliance to a > > > given level > > > > > entails full realization of all language units that are > > > defined for > > > > > that compliance level (note that this implies > > compliance with all > > > > > levels > > > > below it)." > > > > > So, the example is not actually valid: it is not > > possible to have > > > > > Concrete Syntax compliance at Level 1 but not at Level 0. > > > > > > > > Although I am inclined to agree with your intention here, I > > > disagree > > > > that what you are saying is clearly explained by the current spec > > > > draft. The sentence you cite is insufficient, since the > > > section that > > > > defines the "two distinct types of compliance" (section > > > 1.3, par. 3) > > > > does not explain what the individual or combined (i.e., > > > "both") usage > > > > of the distinct types implies for lower levels. > > > > > > > > I further note that Concrete Syntax compliance no longer addresses > > > > Diagram Interchange compliance, which Bran's 8/8/04 email proposal > > > > included (although the 8/8/04 draft referred to it as "UML Design > > > > Interchange specification"). What happened here? Was this a > > > publicly > > > > discussed consensus decision on a mailing list, or has the OMG > > > > formally dropped the UML 2 DI specification? If UML 2 DI is > > > still part > > > > of the UML 2 FAS quartet, we need to address DI compliance in some > > > > sort of straightforward manner. > > > > > > > > What to do? I am inclined to your support your point if we: > > > 1) include > > > > Diagram Interchange compliance; 2) explain clearly what the > > > > implications of using "Abstract Syntax", "Concrete Syntax", > > > "Diagram > > > > Interchange" and combinations of them are for lower levels. > > > > > > > > > > > > > > With respect to the feature support table I think we > > (or a vendor > > > > > claiming support)needs to have more definition of the > > terms than, > > > > > for example, 'Action Semantics' or 'Dynamic Semantics': > > since the > > > > > spec does not already define what it means to support dynamic > > > > > semantics for > > > > > > > > > a package - which is one of the reasons it is not > > included in the > > > > > formal compliance levels. And 'Action Semantics' is even > > > less clear > > > > > (how does it differ from Dynamic Semantics for the Actions > > > > package(s)?). > > > > > > > > I agree, and also think we can whack "Action Semantics". > > > > > > > > > Not sure it's necessary to have entries where no support > > > is claimed, > > > > > but I'm not that bothered. > > > > > > > > Good. > > > > > > > > > I think the section should include very specific examples > > > of support > > > > > for presentation options and semantic variation points: I > > > think for > > > > > these the table approach may become awkward which is why I > > > > > originally suggested a semi-structured English > > approach. Maybe we > > > > > could have a table followed by semi-structured text for > > > the latter? > > > > > > > > There should always be the option to elaborate on anything, > > > and if we > > > > want to add semi-structured text to further explain the > > > example, I am > > > > fine with that! > > > > > > > > Thanks, > > > > > > > > Cris > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > > > > > > Sent: Thursday, August 19, 2004 1:56 AM > > > > > > To: 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > > > > > > mu2i-ftf@omg.org; ocl2-ftf@omg.org > > > > > > Subject: RE: Compliance points resolution proposal - "Feature > > > > > > Support Statement" example > > > > > > > > > > > > FTFers, > > > > > > > > > > > > Attached is an example of a "Feature Support Statement" > > > (formerly > > > > > > known as a"Compliance Support Statement") that Anders > > > and I were > > > > > > asked to generate during today's FTF telecon. > > > > > > > > > > > > Thanks to Bran and Pete for providing review feedback > > > to improve > > > > > > the > > > > > > > > > > example prior to sending it out to the mailing list. > > > > > > > > > > > > -- Cris > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > > > > > > Sent: Tuesday, August 17, 2004 3:05 PM > > > > > > > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; > > > > > > ocl2-ftf@omg.org > > > > > > > Subject: Compliance points resolution proposal > > > > > > > > > > > > > > > > > > > > > After yet more cycles of the proposed resolution between > > > > > > Anders and Pete > > > > > > > and myself, attached, please find a copy of the proposed > > > > > > resolution to the > > > > > > > compliance point issue (6248). > > > > > > > > > > > > > > Since this is a gating issue, I would like to have a > > > definitive > > > > > > > FTF position on this specific resolution before the > > > OMG meeting > > > > > > in Montreal > > > > > > > next week. This likely means having a special vote just on > > > > > > this resolution > > > > > > > outside the usual weekly cycle. > > > > > > > > > > > > > > Regards, > > > > > > > Bran > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reply-To: From: "Desfray" To: "'Pete Rivett'" , "'Marko Boger'" , "'Edwin Seidewitz'" , , , Cc: Subject: RE: Compliance points - Diagram Interchange. Date: Mon, 23 Aug 2004 16:09:02 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MS-TNEF-Correlator: 0000000000C3B727BFC1BC11A4646E0283BD88A8C40FB400 X-Virus-Scanned: by amavisd-new at softeam.com I do reply to Jim and Pete in this mail. I agree with Pete's comment and do not claim that this is a 100% necessity. Though the cases where DI is required is a significant percentage. It allows users to consider XMI as a fully exploitable format. In the cases of UML generated from other tools such as business modeling tools, it is also an interesting capacity that the tool generating XMI generates also DI (translating activity modeling or ER modeling into UML can reuse diagram positioning information). Jim says : >>> MDA does not rely on diagram interchange, but it will rely on model interchange Sure but end users do not separate internal semantics from notation. >>> There are also more many notation options that will need to be addressed, perhaps with their own compliance levels, before UML diagram interchange will be reliable That is also correct, but we have experienced diagram exchange with external tools, based on proprietary format, recovering what we can from the specific information, and we have gotten surprisingly interesting results. From notational hints and informtion, a tool can reinterpret it and provide a view that immediately makes sense to the end user. Apart from a canonical 1 to 1 exchange capacity, the fact that a tool can get as much as it can from another and keep the semantics is already quite an impressive and required result. Again, if we miss the diagram interchange capacity on the compliance subject, I beleive that we miss one important rationale behind UML2.0. ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : lundi 23 aoűt 2004 16:01 Ŕ : Philippe.Desfray@softeam.fr; Marko Boger; Edwin Seidewitz; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Cc : uml2di-ftf@omg.org Objet : RE: Compliance points - Diagram Interchange. It depends on the context: when thinking about tool chains with transformation engines, code generators etc then diagrams are an irrelevance and unnecessary clutter. Similarly for UML generated from other tools such as business modeling tools. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Desfray [mailto:Philippe.Desfray@softeam.fr] > Sent: Monday, August 23, 2004 8:30 AM > To: 'Marko Boger'; 'Edwin Seidewitz'; > uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > Cc: uml2di-ftf@omg.org > Subject: RE: Compliance points - Diagram Interchange. > > Let me second Marco's point here: for most users, it has no sense > interchanging models without diagrams. The XMI interchange of > UML models > should include the diagram interchange. > > ==================================== > Philippe Desfray > VP for R&D - SOFTEAM > Tel: (33) 01 53968400 > Fax: (33) 01 53968401 > 144 Av. des champs Elysées 75008 PARIS > www.softeam.com > www.objecteering.com > > > -----Message d'origine----- > De : Marko Boger [mailto:marko.boger@gentleware.com] > Envoyé : lundi 23 aoűt 2004 10:25 > Ŕ : 'Edwin Seidewitz'; uml2-superstructure-ftf@omg.org; > mu2i-ftf@omg.org; ocl2-ftf@omg.org > Cc : uml2di-ftf@omg.org > Objet : AW: Compliance points - Diagram Interchange. > > > Ed, everyone, > > the metamodel of Diagram Interchange contains some 20 > classes. What should > the compliance to Diagram Interchange be? A tool supports nodes but no > edges? A tool either does support Diagram Interchange or it > doesn't. So > there are no compliance points within Diagram Interchange itself. > > The Metamodel of Diagram Interchange (DI) can be applied to > UML 1 or UML 2. > In fact, it could be used for any graphical notation that is > graph-oriented > (as UML is). It talks about nodes and edges, nesting and > adornments. Every > diagram element can have one unidirectional link to the > semantic model (a > node to a class, use case or actor etc., and an edge to an > association, > dependency or inheritance etc.). > > To be compliant to DI by itself has no meaning. It only > becomes relevant as > the interchange format for a graphical notation. In the > definition of our > graphical notation UML we can choose to use DI as the mechanism to > interchange diagram and layout information or we can choose > not to. UML 1 > was lacking this interchange mechanism and it is my > understanding that the > RFP for UML 2 and the AB made it a requirement for UML 2 to > support such an > interchange mechanism. > > So the compliance should be in the UML specification. UML 2 > should make it a > necessity for a tool to export to XMI including DI to be > fully compliant. > Otherwise UML 2 models are simply not interchangeable. > > 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 > > -----Ursprüngliche Nachricht----- > Von: Edwin Seidewitz [mailto:eseidewitz@intelidata.com] > Gesendet: Freitag, 20. August 2004 16:54 > An: 'Marko Boger'; 'uml2-superstructure-ftf@omg.org'; > 'mu2i-ftf@omg.org'; > 'ocl2-ftf@omg.org' > Cc: 'uml2di-ftf@omg.org' > Betreff: RE: Compliance points - Diagram Interchange. > > Marko -- > > I am a bit confused by this, as I have been by some of the other times > diagram interchange compliance has come up. > > Doesn't the UML Diagram Interchange specification have a > compliance section? > Isn't this where the compliance points for diagram > interchange should be? > > Just looking at this from the point of view of a user of the > OMG UML specs, > it seems confusing to have compliance for diagram interchange > in the UML > Superstructure spec, when that spec does not define diagram > interchange. > > I remember this being discussed at some FTF meeting a while > ago, but I must > admit I have not caught up on all the recent compliance > discussion. Is the > expectation that ALL compliance points for ALL the UML 2.0 > specifications be > defined in the Superstructure spec? (For example, what about OCL 2.0 > compliance?) > > -- Ed > > > -----Original Message----- > > From: Marko Boger [mailto:marko.boger@gentleware.com] > > Sent: Friday, August 20, 2004 10:38 AM > > To: cris.kobryn@telelogic.com; 'Karl Frank'; 'Pete Rivett'; > > 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > > mu2i-ftf@omg.org; ocl2-ftf@omg.org > > Cc: uml2di-ftf@omg.org > > Subject: Compliance points - Diagram Interchange. > > > > > > Gentlemen, > > > > From letters from Bran Selic and Pete Rivett I learn that the > > Superstructure FTF plans to revoke Diagram Interchange as a > > compliance point to UML 2 compliance. As the Chair of the > > Diagram Interchange FTF I urge you to make compliance Diagram > > Interchange a necessity for full compliance. > > > > In all discussions I attended it was always pointed out that > > the ability to exchange UML diagrams compliant to a standard > > using XMI was the single most important issue missing in UML > > 1. The Diagram Interchange specification was specifically > > designed to solve this problem. It is of essence that Diagram > > Interchange remains a part of UML 2 compliance. Otherwise the > > whole UML 2 standard is drastically reduces in its value. > > > > The Diagram Interchange specification is of high quality. It > > is fully implemented by Gentleware to provide a reference, we > > have made cross checks with various other vendors that > > confirm high quality and interchangability. May I also point > > out that Prof. Mario Jeckle, our friend we miss dearly, has > > implemented an XSLT transformation from XMI to SVG. It is > > available on his web site at www.jeckle.de. > > > > Regards, Marko Boger > > > > 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 > > > > Bran wrote: > > > > > I further note that Concrete Syntax compliance no longer addresses > > > Diagram Interchange compliance, which Bran's 8/8/04 email proposal > > > included (although the 8/8/04 draft referred to it as "UML Design > > > Interchange specification"). What happened here? Was this a > > publicly > > > discussed > > consensus > > > decision on a mailing list, or has the OMG formally dropped > > the UML 2 > > > DI specification? If UML 2 DI is still part of the UML 2 > > FAS quartet, > > > we need to address DI compliance in some sort of straightforward > > > manner. > > > > There was a public discussion on this point and the > > conclusion was to remove reference to DI compliance. This is > > because it was pointed out that DI elements have a pointer to > > model elements and are, therefore, it is not separable as an > > independent compliance type. Note that the other two > > compliance types are independent of each other. > > > > As for DI compliance, it is appropriate to declare that in > > the DI spec itself, rather than in the Superstructure (note > > that the coupling between these two specs is strictly one > > way: the DI depends on the superstructure but not the other > > way around). Unfortunately, that FTF is working at a > > different pace and it will likely require further delays > > before they are finished. > > > > > What to do? I am inclined to your support your point if we: > > 1) include > > > Diagram Interchange compliance; 2) explain clearly what the > > > implications > > of > > > using "Abstract Syntax", "Concrete Syntax", "Diagram > > Interchange" and > > > combinations of them are for lower levels. > > > > I am afraid that, with time running out, we no longer have > > the luxury to ponder these "what if" scenarios. We have to > > make a decision and the mechanism by which this is done in > > such circumstances is by voting. Therefore, I will be issuing > > the special compliance point ballot tomorrow morning with > > what I think represents the majority opinion of what this > > text should look like. I will do my best to incorporate all > > the feedback that was provided. If people feel that they can > > contribute to this, please forward me your suggestions. > > > > Cheers...Bran > > ----------------------------------- > > Pete wrote: > > > > > > Bran, > > In fact, as it stands, the DI spec does not depend on > > Superstructure - it just has a generic model element link > > which allows any sort of metamodel to have diagrams > > interchanged. Which is a good thing. Though it does have an > > Appendix A (which the FAS states needs to be updated by the > > FTF) covering how the model elements from Super are > > represented in the DI metamodel for specific diagram types. > > > > I think the DI spec should have a separate compliance point > > specifically for UML 2, requiring generic compliance to the > > DI spec (as in the current DI compliance point) and correct > > representation of the diagrams according to Appendix A for > > those diagram types supported by the tool (the statement of > > supported diagram types for the tool will be covered by its > > UML2 compliance statement). > > > > Pete > > > > ----------------------------------- > > Cris wrote: > > > > > Please do not propose adding DI compliance to the > > definition of UML 2 > > > compliance. > > > > We first need to explain why Diagram Interchange (DI) was > > abruptly dropped from the 8/8/04 compliance draft with no > > public explanation that I have read or heard. When and how > > was this decided? Please point me to public email or minutes, > > since I must have missed this... > > > > > Diagram Interchange is a separate spec with separate > > technology issues > > > surrounding its implementation. > > > > I disagree. Although DI has separate technical issues, it > > also has strongly related technology issues. In particular, > > DI's primary reason for existence is to exchange UML 2 > > diagrams between tools. Isn't this something UML 2 users will > > expect from a modeling tool standard? > > > > So are we as a standards body saying that Diagram Interchange > > is relevant or irrelevant for UML 2 Superstructure > > compliance? If it is the former, we need to explain its > > relevance; if it is the latter, let's explain why it is > > irrelevant and retire it. One way or the other, let's be clear! > > > > Thanks, > > > > Cris > > > > > > > > > -----Original Message----- > > > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > > > Sent: Thursday, August 19, 2004 1:03 PM > > > To: 'Pete Rivett'; cris.kobryn@telelogic.com; 'Branislav Selic'; > > > uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; > ocl2-ftf@omg.org > > > Subject: RE: Compliance points resolution proposal - > > "Feature Support > > > Statement" example > > > > > > > I'm not sure the Compliance Summary needs to list levels > > *beneath* > > > > that which compliance is claimed - since compliance at level N > > > > automatically implies/requires support at Level N-1 (start of > > > > section 1.3 of the new section states: "Compliance to a > > given level > > > > entails full realization of all language units that are > > defined for > > > > that compliance level (note that this implies > compliance with all > > > > levels > > > below it)." > > > > So, the example is not actually valid: it is not > possible to have > > > > Concrete Syntax compliance at Level 1 but not at Level 0. > > > > > > Although I am inclined to agree with your intention here, I > > disagree > > > that what you are saying is clearly explained by the current spec > > > draft. The sentence you cite is insufficient, since the > > section that > > > defines the "two distinct types of compliance" (section > > 1.3, par. 3) > > > does not explain what the individual or combined (i.e., > > "both") usage > > > of the distinct types implies for lower levels. > > > > > > I further note that Concrete Syntax compliance no longer addresses > > > Diagram Interchange compliance, which Bran's 8/8/04 email proposal > > > included (although the 8/8/04 draft referred to it as "UML Design > > > Interchange specification"). What happened here? Was this a > > publicly > > > discussed consensus decision on a mailing list, or has the OMG > > > formally dropped the UML 2 DI specification? If UML 2 DI is > > still part > > > of the UML 2 FAS quartet, we need to address DI compliance in some > > > sort of straightforward manner. > > > > > > What to do? I am inclined to your support your point if we: > > 1) include > > > Diagram Interchange compliance; 2) explain clearly what the > > > implications of using "Abstract Syntax", "Concrete Syntax", > > "Diagram > > > Interchange" and combinations of them are for lower levels. > > > > > > > > > > > With respect to the feature support table I think we > (or a vendor > > > > claiming support)needs to have more definition of the > terms than, > > > > for example, 'Action Semantics' or 'Dynamic Semantics': > since the > > > > spec does not already define what it means to support dynamic > > > > semantics for > > > > > > > a package - which is one of the reasons it is not > included in the > > > > formal compliance levels. And 'Action Semantics' is even > > less clear > > > > (how does it differ from Dynamic Semantics for the Actions > > > package(s)?). > > > > > > I agree, and also think we can whack "Action Semantics". > > > > > > > Not sure it's necessary to have entries where no support > > is claimed, > > > > but I'm not that bothered. > > > > > > Good. > > > > > > > I think the section should include very specific examples > > of support > > > > for presentation options and semantic variation points: I > > think for > > > > these the table approach may become awkward which is why I > > > > originally suggested a semi-structured English > approach. Maybe we > > > > could have a table followed by semi-structured text for > > the latter? > > > > > > There should always be the option to elaborate on anything, > > and if we > > > want to add semi-structured text to further explain the > > example, I am > > > fine with that! > > > > > > Thanks, > > > > > > Cris > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > > > > > Sent: Thursday, August 19, 2004 1:56 AM > > > > > To: 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > > > > > mu2i-ftf@omg.org; ocl2-ftf@omg.org > > > > > Subject: RE: Compliance points resolution proposal - "Feature > > > > > Support Statement" example > > > > > > > > > > FTFers, > > > > > > > > > > Attached is an example of a "Feature Support Statement" > > (formerly > > > > > known as a"Compliance Support Statement") that Anders > > and I were > > > > > asked to generate during today's FTF telecon. > > > > > > > > > > Thanks to Bran and Pete for providing review feedback > > to improve > > > > > the > > > > > > > > example prior to sending it out to the mailing list. > > > > > > > > > > -- Cris > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > > > > > Sent: Tuesday, August 17, 2004 3:05 PM > > > > > > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; > > > > > ocl2-ftf@omg.org > > > > > > Subject: Compliance points resolution proposal > > > > > > > > > > > > > > > > > > After yet more cycles of the proposed resolution between > > > > > Anders and Pete > > > > > > and myself, attached, please find a copy of the proposed > > > > > resolution to the > > > > > > compliance point issue (6248). > > > > > > > > > > > > Since this is a gating issue, I would like to have a > > definitive > > > > > > FTF position on this specific resolution before the > > OMG meeting > > > > > in Montreal > > > > > > next week. This likely means having a special vote just on > > > > > this resolution > > > > > > outside the usual weekly cycle. > > > > > > > > > > > > Regards, > > > > > > Bran > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > winmail.dat Reply-To: From: "James A. Schardt" To: Subject: RE: Compliance points - Diagram Interchange. Date: Mon, 23 Aug 2004 10:25:01 -0400 Organization: Advanced Concepts Center, LLC. X-Mailer: Microsoft Outlook, Build 10.0.6626 X-OriginalArrivalTime: 23 Aug 2004 14:25:29.0583 (UTC) FILETIME=[0A76C7F0:01C4891D] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7NEevlj012069 At the end of the day, UML 2 is about making the Developer (Business Modeler, Analyst, Designer, Programmer, Systems Engineer, etc.) more productive. Spending time rearranging diagrams because I moved from one tool to another is not making me more productive. As we work on complex MDA projects we will need "best of breed" tools to communicate among developers. We will need diagram interchange as well as a common notation. Help maximize productivity, make diagram interchange a compliance point. Cheers, --jas Subject: RE: Compliance points - Diagram Interchange. Date: Mon, 23 Aug 2004 11:29:16 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance points - Diagram Interchange. Thread-Index: AcSJGzKe2Sv3PL5qQ5+dY/eds03LDAAB2NEQ From: "Pete Rivett" To: "Thomas Weigert" , , "Marko Boger" , "Edwin Seidewitz" , , , Cc: X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7NFX4lj012939 In response to Philippe and Thomas I am very much in favor of exchanging diagrams - indeed I am a submitter to DI and my company's product already (partially) supports the DI standard! I am just making the points that: - there are scenarios where the diagrams are not needed (so it should not be required that all tools compliant to UML abstract syntax must also exchange DI) - as a general principle compliance points in an OMG standard should only relate to content in that standard. That is why, for example, Super does not *contain* the L0 compliance level - but refers to the fact that it is a related compliance point (to be) defined in another specification (in this case Infra) - since the DI specification already contains mappings of UML 2 Diagrams to the DI metamodel, then this reinforces that this represents a natural document to define compliance points related to this. It may well make sense to have different levels of DI compliance aligning with the compliance levels L0 to L3. Once defined, the Super spec may refer to these compliance levels in the same way it refers to L0 in the Infra spec. Once the DI FTF has agreed this in principle I suggest this be addressed through a new issue for Super. Regards Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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 Date: Tue, 24 Aug 2004 01:40:05 +0100 From: Guus Ramackers Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Pete Rivett CC: Thomas Weigert , Philippe.Desfray@softeam.fr, Marko Boger , Edwin Seidewitz , uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org, ocl2-ftf@omg.org, uml2di-ftf@omg.org Subject: Re: Compliance points - Diagram Interchange. I second the point that users would like to see UML diagrams interchanged, alongside the underlying model information. However, apart from the arguments Pete raises below, I don't think it is a good idea to add DI compliance to the UML 2.0 spec at this stage before we have experience that UML specific diagrams can be interchanged effectively by different vendors. The DI submission refrained from detailed formal mappings to UML, leaving this to subsequent version. We have experienced difficulties with XMI interchange between tools on the 1.x stack in the past, and must make sure that no such difficulties exist before defining UML diagram compliance as part of UML 2.x. To: "Thomas Weigert" Cc: "Edwin Seidewitz" , "Marko Boger" , mu2i-ftf@omg.org, ocl2-ftf@omg.org, "Pete Rivett" , Philippe.Desfray@softeam.fr, uml2-superstructure-ftf@omg.org, uml2di-ftf@omg.org Subject: RE: Compliance points - Diagram Interchange. X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Mon, 23 Aug 2004 20:51:15 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/23/2004 18:51:18, Serialize complete at 08/23/2004 18:51:18 Thomas, I agree with both you an Pete, and don't see any conflict between your views. Diagram exchange will be important for exporting from one tool into another. However, as Pete points out, it isn't required for MDA which is translating and instance of the metamodel into some other model. Both are important, but I think there may be less controversy associated with metamodel interchange. Diagram interchange could result in competitive marketing issues while metamodel interchange allows vendors to complement each other with additional mappings. In addition, there is a lot of variability in notation, more than in the metamodel (as the notation has to include the variability in the metamodel too). So its probably safer to keep diagram and metamodel interchange separate, and focus on the easier one, and the one most valuable for MDA first. In time, we may see the real value proposition for UML2 is in MDA so we're interested in doing whatever we can to make it work. From: "Thomas Weigert" To: "Jim Amsden" , "Thomas Weigert" Cc: "Edwin Seidewitz" , "Marko Boger" , , , "Pete Rivett" , , , Subject: RE: Compliance points - Diagram Interchange. Date: Mon, 23 Aug 2004 21:12:31 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) But that is precisely the reason why we have compliance points.... Nobody has to satisfy a compliance point, but the user would be helped by knowing which tool supports interchange of UML diagrams and which tool does not. Initially, there will be few or no tools that will satisfy the diagram interchange compliance point. But eventually there may be some. I truly don't understand why one would not want to have that information. What is more important for MDA is besides the point (as we learned from the discussion on the L0 compliance point, which has precious little to do with MDA). What matters is what helps the users. Th. To: "Thomas Weigert" Cc: "Edwin Seidewitz" , "Marko Boger" , mu2i-ftf@omg.org, ocl2-ftf@omg.org, "Pete Rivett" , Philippe.Desfray@softeam.fr, "Thomas Weigert" , uml2-superstructure-ftf@omg.org, uml2di-ftf@omg.org Subject: RE: Compliance points - Diagram Interchange. X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Tue, 24 Aug 2004 09:05:29 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/24/2004 07:05:38, Serialize complete at 08/24/2004 07:05:38 Thomas, Don't get me wrong, I would like to have diagram interchange compliance too. I'm just saying we don't need to couple it with metamodel interchange, and its a slightly lower priority for me. I can clearly see how that might not be true for others. Date: Tue, 24 Aug 2004 20:26:14 +0100 From: Guus Ramackers Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Thomas Weigert CC: Jim Amsden , Edwin Seidewitz , Marko Boger , mu2i-ftf@omg.org, ocl2-ftf@omg.org, Pete Rivett , Philippe.Desfray@softeam.fr, uml2-superstructure-ftf@omg.org, uml2di-ftf@omg.org Subject: Re: Compliance points - Diagram Interchange. Thomas, According to our development group, the current DI specification w.r.t. to UML diagrams (please see appendix A of the DI spec) is inadequate to define a standard interchange format for vendors. It is not that a DI compatible XMI file can be produced, it's just that every vendor will have their own interpretation (or mapping). So the issue is whether this will help users at this point, or whether we need to wait for DI version 2 to attempt to do this in a vendor neutral fashion. In submitter discussions, it has been pointed out that a more formal UML 2.0 mapping is needed, and the response was that this would have to wait until a DI 2.0 version. UML 1.x didn't do users much favour when it came to XMI interchange, and it is important that we don't raise expectations that cannot be fulfilled w.r.t diagram interchange. I don't think there is any disagreement on where we want to go, just on when and how. Thanks, Guus To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: Compliance points resolution X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Sun, 8 Aug 2004 21:18:51 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/08/2004 21:19:11 Here is the new resolution for compliance points based on the new package merge proposal. The content of the individual compliance levels has not changed from the original spec (except to reflect some of the latest updates to the spec as a result of FTF work), but the definition of compliance has changed as has the mechanism for how the compliance levels are produced using package merge. It is all based on the long discussions we held starting with the London meeting and ending with the Anaheim meeting. Please review and provide me your feedback. I would like to propose this for ballot 23. Cheers...Bran Compliance.section.addin.pdf From: "Thomas Weigert" To: "Branislav Selic" , Cc: Subject: RE: Compliance points resolution Date: Sun, 8 Aug 2004 21:50:48 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, without carefully reading through this document, I have two initial comments: 1. Figure 2 does not correspond to Table 1 (but it should) 2. There have been packages moved between compliance levels. Unless there are really good arguments to do so, we should not make such changes. But I have a more fundamental concern: This whole business about compliance levels is confusing for both vendors and users and serves no purpose than to give something to argue about. Can we just jettison that notion? Thanks, Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Sunday, August 08, 2004 8:19 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: Compliance points resolution Here is the new resolution for compliance points based on the new package merge proposal. The content of the individual compliance levels has not changed from the original spec (except to reflect some of the latest updates to the spec as a result of FTF work), but the definition of compliance has changed as has the mechanism for how the compliance levels are produced using package merge. It is all based on the long discussions we held starting with the London meeting and ending with the Anaheim meeting. Please review and provide me your feedback. I would like to propose this for ballot 23. Cheers...Bran From: "Thomas Weigert" To: "Branislav Selic" , "Thomas Weigert" Cc: , Subject: RE: Compliance points resolution Date: Mon, 9 Aug 2004 07:18:22 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Thanks. I'll spell out the details. Accept the point on that it is not fruitful to open another discussion if the expectation is that we have this... Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, August 09, 2004 7:20 AM To: Thomas Weigert Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Compliance points resolution Thomas, In reply to your comments: > 1. Figure 2 does not correspond to Table 1 (but it should) You will have to be more precise -- what part is wrong? Please note that Figures 2, 3, and 4 only show the top-level packages that have to be merged into a given level, not all the packages. Those top-level packages do their own merges as shown in the various package diagrams. There is no point in repeating those in the diagrams since they not only duplicate information stated elsewhere and they also become pretty unwieldy if all the package merges and imports are shown in the diagrams. OTOH, the top-level diagrams are needed since they are part of the formal metamodel for a given level. > 2. There have been packages moved between compliance levels. Unless > there are really good arguments to do so, we should not make such changes. I agree that they should not be moved. I was pretty careful to keep the original contents, although I had to guess for a couple of packages because they were erroneously omitted in the original spec. Again, please tell me which ones you think got moved. > But I have a more fundamental concern: This whole business about > compliance levels is confusing for both vendors and users and serves > no purpose than to give something to argue about. Can we just > jettison that notion? Lots of people think that it serves a purpose. Most importantly, the architecture board thinks so and has made the resolution of the "compliance points issue" a condition for adoption. We do not have a choice on this matter, so let's not regress into discussions about usefuleness of it. Regards, Bran To: "Thomas Weigert" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Compliance points resolution X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 9 Aug 2004 08:20:02 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/09/2004 08:20:06, Serialize complete at 08/09/2004 08:20:06 Thomas, In reply to your comments: > 1. Figure 2 does not correspond to Table 1 (but it should) You will have to be more precise -- what part is wrong? Please note that Figures 2, 3, and 4 only show the top-level packages that have to be merged into a given level, not all the packages. Those top-level packages do their own merges as shown in the various package diagrams. There is no point in repeating those in the diagrams since they not only duplicate information stated elsewhere and they also become pretty unwieldy if all the package merges and imports are shown in the diagrams. OTOH, the top-level diagrams are needed since they are part of the formal metamodel for a given level. > 2. There have been packages moved between compliance levels. Unless > there are really good arguments to do so, we should not make such changes. I agree that they should not be moved. I was pretty careful to keep the original contents, although I had to guess for a couple of packages because they were erroneously omitted in the original spec. Again, please tell me which ones you think got moved. > But I have a more fundamental concern: This whole business about > compliance levels is confusing for both vendors and users and serves > no purpose than to give something to argue about. Can we just > jettison that notion? Lots of people think that it serves a purpose. Most importantly, the architecture board thinks so and has made the resolution of the "compliance points issue" a condition for adoption. We do not have a choice on this matter, so let's not regress into discussions about usefuleness of it. Regards, Bran Reply-To: From: "Conrad Bock" To: , Subject: RE: Compliance points resolution Date: Wed, 11 Aug 2004 14:56:53 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Pardon me, this was supposed to be under the subject of compliance. Bran, Presumably this would need to be updated for packaging in 7319 (it seems to be partially). I figure: Basic Level should include BasicActions, and FundamentalActivities. (The description of Basic Level includes BasicActions, but it isn't in Figure 2, and Table 2 shows it in Intermediate. Table 1 has FundamentalActivities already, but it isn't in Figure 2). Intermediate Level should include StructuredActions. (Table 3 has StructuredActions in Complete, but it should be at the same level as StructuredActivities. It isn't in Figure 3). There's a typo in Figure 3: InvocationActions => IntermediateActions. Conrad To: uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org, ocl2-ftf@omg.org Subject: Compliance points resolution proposal X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 17 Aug 2004 18:05:06 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/17/2004 18:05:08 After yet more cycles of the proposed resolution between Anders and Pete and myself, attached, please find a copy of the proposed resolution to the compliance point issue (6248). Since this is a gating issue, I would like to have a definitive FTF position on this specific resolution before the OMG meeting in Montreal next week. This likely means having a special vote just on this resolution outside the usual weekly cycle. Regards, Bran Compliance.section.addin.040817.pdf Subject: RE: Compliance points resolution proposal Date: Tue, 17 Aug 2004 20:16:00 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance points resolution proposal Thread-Index: AcSEqmh05OxFf7v9RuSMfaR/rML3fgADDMNQ From: "Pete Rivett" To: "Branislav Selic" , , , X-Virus-Scanned: by amavisd-new at sentraliant.com Great stuff, Bran. One minor editorial comment: on p5, 2 lines before the start of 1.4, there is a remaining use of 'capability level' which has now been replaced elsewhere by 'increment' (a definite improvement IMHO). It also occurs to me that it would help consistency/comparability of vendor claims if we included a couple of sample 'support statements' here. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 17, 2004 11:05 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Compliance points resolution proposal After yet more cycles of the proposed resolution between Anders and Pete and myself, attached, please find a copy of the proposed resolution to the compliance point issue (6248). Since this is a gating issue, I would like to have a definitive FTF position on this specific resolution before the OMG meeting in Montreal next week. This likely means having a special vote just on this resolution outside the usual weekly cycle. Regards, Bran Subject: RE: Compliance points resolution proposal Date: Tue, 17 Aug 2004 20:16:00 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance points resolution proposal Thread-Index: AcSEqmh05OxFf7v9RuSMfaR/rML3fgADDMNQ From: "Pete Rivett" To: "Branislav Selic" , , , X-Virus-Scanned: by amavisd-new at sentraliant.com Great stuff, Bran. One minor editorial comment: on p5, 2 lines before the start of 1.4, there is a remaining use of 'capability level' which has now been replaced elsewhere by 'increment' (a definite improvement IMHO). It also occurs to me that it would help consistency/comparability of vendor claims if we included a couple of sample 'support statements' here. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 17, 2004 11:05 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Compliance points resolution proposal After yet more cycles of the proposed resolution between Anders and Pete and myself, attached, please find a copy of the proposed resolution to the compliance point issue (6248). Since this is a gating issue, I would like to have a definitive FTF position on this specific resolution before the OMG meeting in Montreal next week. This likely means having a special vote just on this resolution outside the usual weekly cycle. Regards, Bran Subject: RE: Compliance points resolution proposal Date: Tue, 17 Aug 2004 20:16:00 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance points resolution proposal Thread-Index: AcSEqmh05OxFf7v9RuSMfaR/rML3fgADDMNQ From: "Pete Rivett" To: "Branislav Selic" , , , X-Virus-Scanned: by amavisd-new at sentraliant.com Great stuff, Bran. One minor editorial comment: on p5, 2 lines before the start of 1.4, there is a remaining use of 'capability level' which has now been replaced elsewhere by 'increment' (a definite improvement IMHO). It also occurs to me that it would help consistency/comparability of vendor claims if we included a couple of sample 'support statements' here. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 17, 2004 11:05 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Compliance points resolution proposal After yet more cycles of the proposed resolution between Anders and Pete and myself, attached, please find a copy of the proposed resolution to the compliance point issue (6248). Since this is a gating issue, I would like to have a definitive FTF position on this specific resolution before the OMG meeting in Montreal next week. This likely means having a special vote just on this resolution outside the usual weekly cycle. Regards, Bran From: "Thomas Weigert" To: "Branislav Selic" , , , Subject: RE: Compliance points resolution proposal Date: Wed, 18 Aug 2004 12:47:03 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, I have one suggestion: Can we put Kernel into L0? L0 otherwise would be very confusing to UML users. L0 would be the merge of the relevant part of the infrastructure, which is almost the same, but not exactly the same, as the Kernel from superstructure. It would be much clearer if we put Kernel into L0 so that there is no replication of the model in a slightly different form at L1. Also, I think it is wrong to say that the infrastructure, at any level, is the UML. The infrastructure is merely the common plumbing for a number of languages, the UML being one of them. It is not, and never was intended, to be UML, not even in the minimalist L0 incarnation. Moving Kernel into L0 would make that clear. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 17, 2004 5:05 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Compliance points resolution proposal After yet more cycles of the proposed resolution between Anders and Pete and myself, attached, please find a copy of the proposed resolution to the compliance point issue (6248). Since this is a gating issue, I would like to have a definitive FTF position on this specific resolution before the OMG meeting in Montreal next week. This likely means having a special vote just on this resolution outside the usual weekly cycle. Regards, Bran Subject: RE: Compliance points resolution proposal Date: Wed, 18 Aug 2004 11:13:50 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance points resolution proposal Thread-Index: AcSFTOFQ7gSB4y7NQziJn0cb2Ma8jQAAHlHQ From: "Karl Frank" To: "Thomas Weigert" , "Branislav Selic" , , , X-OriginalArrivalTime: 18 Aug 2004 18:13:49.0366 (UTC) FILETIME=[1C1B0560:01C4854F] I made this suggestion a week ago. Bran's response then was: Kernel by itself is not very useful (e.g., it does not even have dependencies or interfaces). I doubt if it would have many adherents. Strangely enough, as I explained in my response to Pete, the proposed Basic by itself is much more meaningful. So, in my view, we either get rid of L0 altogether or leave it the way it is. Bran Basic package as Level 0 UML 2 will enable vendors to produce a UML product to support Eclips EMF and Microsoft's Visual Studio 2005 MDF, which both incorporate modeling support which does not go beyond binary references (as simple associations) to include the n-ary Association Classifier. Kernel does include that n-ary Association whihc inherits both Relationship and Classifier, which makes Kernel way beyond the Java EMF and the .NET MDF framework support for modeling, and which therefore motivates, in my opinion, the L0 proposal for compliance. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Wednesday, August 18, 2004 1:47 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: RE: Compliance points resolution proposal Bran, I have one suggestion: Can we put Kernel into L0? L0 otherwise would be very confusing to UML users. L0 would be the merge of the relevant part of the infrastructure, which is almost the same, but not exactly the same, as the Kernel from superstructure. It would be much clearer if we put Kernel into L0 so that there is no replication of the model in a slightly different form at L1. Also, I think it is wrong to say that the infrastructure, at any level, is the UML. The infrastructure is merely the common plumbing for a number of languages, the UML being one of them. It is not, and never was intended, to be UML, not even in the minimalist L0 incarnation. Moving Kernel into L0 would make that clear. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 17, 2004 5:05 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Compliance points resolution proposal After yet more cycles of the proposed resolution between Anders and Pete and myself, attached, please find a copy of the proposed resolution to the compliance point issue (6248). Since this is a gating issue, I would like to have a definitive FTF position on this specific resolution before the OMG meeting in Montreal next week. This likely means having a special vote just on this resolution outside the usual weekly cycle. Regards, Bran From: "Thomas Weigert" To: "Karl Frank" , "Branislav Selic" , , , Subject: RE: Compliance points resolution proposal Date: Wed, 18 Aug 2004 13:19:20 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) But really, L0 is not UML. Let's not create something that is not really UML but call it UML just because EMF supports this subset. EMF is not the same as UML. What was the intention of being the most basic UML was the Kernel that merges all the infrastructure together and adds a few things that the infrastructure omitted as they were trying to be a modeling language framework, not a basic version of UML. I am ok with having a layer that has just the infrastructure, but I am not ok with calling it UML. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Wednesday, August 18, 2004 1:14 PM To: Thomas Weigert; Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: RE: Compliance points resolution proposal I made this suggestion a week ago. Bran's response then was: Kernel by itself is not very useful (e.g., it does not even have dependencies or interfaces). I doubt if it would have many adherents. Strangely enough, as I explained in my response to Pete, the proposed Basic by itself is much more meaningful. So, in my view, we either get rid of L0 altogether or leave it the way it is. Bran Basic package as Level 0 UML 2 will enable vendors to produce a UML product to support Eclips EMF and Microsoft's Visual Studio 2005 MDF, which both incorporate modeling support which does not go beyond binary references (as simple associations) to include the n-ary Association Classifier. Kernel does include that n-ary Association whihc inherits both Relationship and Classifier, which makes Kernel way beyond the Java EMF and the .NET MDF framework support for modeling, and which therefore motivates, in my opinion, the L0 proposal for compliance. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Wednesday, August 18, 2004 1:47 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: RE: Compliance points resolution proposal Bran, I have one suggestion: Can we put Kernel into L0? L0 otherwise would be very confusing to UML users. L0 would be the merge of the relevant part of the infrastructure, which is almost the same, but not exactly the same, as the Kernel from superstructure. It would be much clearer if we put Kernel into L0 so that there is no replication of the model in a slightly different form at L1. Also, I think it is wrong to say that the infrastructure, at any level, is the UML. The infrastructure is merely the common plumbing for a number of languages, the UML being one of them. It is not, and never was intended, to be UML, not even in the minimalist L0 incarnation. Moving Kernel into L0 would make that clear. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 17, 2004 5:05 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Compliance points resolution proposal After yet more cycles of the proposed resolution between Anders and Pete and myself, attached, please find a copy of the proposed resolution to the compliance point issue (6248). Since this is a gating issue, I would like to have a definitive FTF position on this specific resolution before the OMG meeting in Montreal next week. This likely means having a special vote just on this resolution outside the usual weekly cycle. Regards, Bran To: "Thomas Weigert" Cc: "Branislav Selic" , "Karl Frank" , mu2i-ftf@omg.org, ocl2-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Compliance points resolution proposal X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Wed, 18 Aug 2004 14:32:39 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/18/2004 12:32:41, Serialize complete at 08/18/2004 12:32:41 Thomas, Karl, The purpose of L0 was not necessarily to "define UML" but was rather intended to create the low bar for interoperability and interchange. L0 compliant tools can AT LEAST interchange simple structural models consistent with EMOF. This is a big step forward from where we are today. By having L0, we minimize the barriers for tool vendors to support this minimal level of interchange. I don't expect a lot of tools to only implement L0, or for anyone to consider L0 as defining UML. Its just there to establish minimal compliance and interchange expectations. "Thomas Weigert" 08/18/2004 02:19 PM To "Karl Frank" , "Branislav Selic" , , , cc Subject RE: Compliance points resolution proposal But really, L0 is not UML. Let's not create something that is not really UML but call it UML just because EMF supports this subset. EMF is not the same as UML. What was the intention of being the most basic UML was the Kernel that merges all the infrastructure together and adds a few things that the infrastructure omitted as they were trying to be a modeling language framework, not a basic version of UML. I am ok with having a layer that has just the infrastructure, but I am not ok with calling it UML. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Wednesday, August 18, 2004 1:14 PM To: Thomas Weigert; Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: RE: Compliance points resolution proposal I made this suggestion a week ago. Bran's response then was: Kernel by itself is not very useful (e.g., it does not even have dependencies or interfaces). I doubt if it would have many adherents. Strangely enough, as I explained in my response to Pete, the proposed Basic by itself is much more meaningful. So, in my view, we either get rid of L0 altogether or leave it the way it is. Bran Basic package as Level 0 UML 2 will enable vendors to produce a UML product to support Eclips EMF and Microsoft's Visual Studio 2005 MDF, which both incorporate modeling support which does not go beyond binary references (as simple associations) to include the n-ary Association Classifier. Kernel does include that n-ary Association whihc inherits both Relationship and Classifier, which makes Kernel way beyond the Java EMF and the .NET MDF framework support for modeling, and which therefore motivates, in my opinion, the L0 proposal for compliance. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Wednesday, August 18, 2004 1:47 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: RE: Compliance points resolution proposal Bran, I have one suggestion: Can we put Kernel into L0? L0 otherwise would be very confusing to UML users. L0 would be the merge of the relevant part of the infrastructure, which is almost the same, but not exactly the same, as the Kernel from superstructure. It would be much clearer if we put Kernel into L0 so that there is no replication of the model in a slightly different form at L1. Also, I think it is wrong to say that the infrastructure, at any level, is the UML. The infrastructure is merely the common plumbing for a number of languages, the UML being one of them. It is not, and never was intended, to be UML, not even in the minimalist L0 incarnation. Moving Kernel into L0 would make that clear. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 17, 2004 5:05 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Compliance points resolution proposal After yet more cycles of the proposed resolution between Anders and Pete and myself, attached, please find a copy of the proposed resolution to the compliance point issue (6248). Since this is a gating issue, I would like to have a definitive FTF position on this specific resolution before the OMG meeting in Montreal next week. This likely means having a special vote just on this resolution outside the usual weekly cycle. Regards, Bran To: "Thomas Weigert" Cc: "Branislav Selic" , "Karl Frank" , mu2i-ftf@omg.org, ocl2-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Compliance points resolution proposal X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Wed, 18 Aug 2004 14:32:39 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/18/2004 12:32:41, Serialize complete at 08/18/2004 12:32:41 Thomas, Karl, The purpose of L0 was not necessarily to "define UML" but was rather intended to create the low bar for interoperability and interchange. L0 compliant tools can AT LEAST interchange simple structural models consistent with EMOF. This is a big step forward from where we are today. By having L0, we minimize the barriers for tool vendors to support this minimal level of interchange. I don't expect a lot of tools to only implement L0, or for anyone to consider L0 as defining UML. Its just there to establish minimal compliance and interchange expectations. "Thomas Weigert" 08/18/2004 02:19 PM To "Karl Frank" , "Branislav Selic" , , , cc Subject RE: Compliance points resolution proposal But really, L0 is not UML. Let's not create something that is not really UML but call it UML just because EMF supports this subset. EMF is not the same as UML. What was the intention of being the most basic UML was the Kernel that merges all the infrastructure together and adds a few things that the infrastructure omitted as they were trying to be a modeling language framework, not a basic version of UML. I am ok with having a layer that has just the infrastructure, but I am not ok with calling it UML. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Wednesday, August 18, 2004 1:14 PM To: Thomas Weigert; Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: RE: Compliance points resolution proposal I made this suggestion a week ago. Bran's response then was: Kernel by itself is not very useful (e.g., it does not even have dependencies or interfaces). I doubt if it would have many adherents. Strangely enough, as I explained in my response to Pete, the proposed Basic by itself is much more meaningful. So, in my view, we either get rid of L0 altogether or leave it the way it is. Bran Basic package as Level 0 UML 2 will enable vendors to produce a UML product to support Eclips EMF and Microsoft's Visual Studio 2005 MDF, which both incorporate modeling support which does not go beyond binary references (as simple associations) to include the n-ary Association Classifier. Kernel does include that n-ary Association whihc inherits both Relationship and Classifier, which makes Kernel way beyond the Java EMF and the .NET MDF framework support for modeling, and which therefore motivates, in my opinion, the L0 proposal for compliance. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Wednesday, August 18, 2004 1:47 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: RE: Compliance points resolution proposal Bran, I have one suggestion: Can we put Kernel into L0? L0 otherwise would be very confusing to UML users. L0 would be the merge of the relevant part of the infrastructure, which is almost the same, but not exactly the same, as the Kernel from superstructure. It would be much clearer if we put Kernel into L0 so that there is no replication of the model in a slightly different form at L1. Also, I think it is wrong to say that the infrastructure, at any level, is the UML. The infrastructure is merely the common plumbing for a number of languages, the UML being one of them. It is not, and never was intended, to be UML, not even in the minimalist L0 incarnation. Moving Kernel into L0 would make that clear. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 17, 2004 5:05 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Compliance points resolution proposal After yet more cycles of the proposed resolution between Anders and Pete and myself, attached, please find a copy of the proposed resolution to the compliance point issue (6248). Since this is a gating issue, I would like to have a definitive FTF position on this specific resolution before the OMG meeting in Montreal next week. This likely means having a special vote just on this resolution outside the usual weekly cycle. Regards, Bran Reply-To: From: "Cris Kobryn" To: "'Thomas Weigert'" , "'Karl Frank'" , "'Branislav Selic'" , , , Subject: RE: Compliance points resolution proposal Date: Wed, 18 Aug 2004 13:56:39 -0700 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcSFUCuvJd9JeENRS6Oz5K4mHb8nuAAFJyCg > But really, L0 is not UML. Let's not create something that is not really > UML but call it UML just because EMF supports this subset. EMF is not the > same as UML. What was the intention of being the most basic UML was the > Kernel that merges all the infrastructure together and adds a few things > that the infrastructure omitted as they were trying to be a modeling > language framework, not a basic version of UML. I am ok with having a > layer that has just the infrastructure, but I am not ok with calling it > UML. Th. I agree with Thomas that this EMF-compatible infrastructural layer should be called something other than UML. To do otherwise will only increase the confusion in the marketplace. -- Cris > -----Original Message----- > From: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Wednesday, August 18, 2004 1:14 PM > To: Thomas Weigert; Branislav Selic; uml2-superstructure- > ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal > > > I made this suggestion a week ago. > > Bran's response then was: > > > > Kernel by itself is not very useful (e.g., it does not even have > dependencies or interfaces). I doubt if it would have many adherents. > Strangely enough, as I explained in my response to Pete, the proposed > Basic by itself is much more meaningful. So, in my view, we either get rid > of L0 altogether or leave it the way it is. > > Bran > > Basic package as Level 0 UML 2 will enable vendors to produce a UML > product to support Eclips EMF and Microsoft's Visual Studio 2005 MDF, > which both incorporate modeling support which does not go beyond binary > references (as simple associations) to include the n-ary Association > Classifier. > > Kernel does include that n-ary Association whihc inherits both > Relationship and Classifier, which makes Kernel way beyond the Java EMF > and the .NET MDF framework support for modeling, and which therefore > motivates, in my opinion, the L0 proposal for compliance. > > - Karl > > ________________________________ > > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > Sent: Wednesday, August 18, 2004 1:47 PM > To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i- > ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal > > > Bran, > > I have one suggestion: Can we put Kernel into L0? L0 otherwise would > be very confusing to UML users. L0 would be the merge of the relevant part > of the infrastructure, which is almost the same, but not exactly the same, > as the Kernel from superstructure. It would be much clearer if we put > Kernel into L0 so that there is no replication of the model in a slightly > different form at L1. > > Also, I think it is wrong to say that the infrastructure, at any > level, is the UML. The infrastructure is merely the common plumbing for a > number of languages, the UML being one of them. It is not, and never was > intended, to be UML, not even in the minimalist L0 incarnation. Moving > Kernel into L0 would make that clear. > > Th. > > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Tuesday, August 17, 2004 5:05 PM > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2- > ftf@omg.org > Subject: Compliance points resolution proposal > > > > After yet more cycles of the proposed resolution between > Anders and Pete and myself, attached, please find a copy of the proposed > resolution to the compliance point issue (6248). > > Since this is a gating issue, I would like to have a > definitive FTF position on this specific resolution before the OMG meeting > in Montreal next week. This likely means having a special vote just on > this resolution outside the usual weekly cycle. > > Regards, > Bran > Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 18 Aug 2004 16:00:29 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: Compliance points resolution proposal I agree with Cris. I agree with Thomas that this EMF-compatible infrastructural layer should be called something other than UML. To do otherwise will only increase the confusion in the marketplace. -- Cris Of course, a UML modeling tool can produce EMF models. It is perfectly acceptable that a UML L1 compliant modeling tool should have a mode of operation that helps the user produce EMF compliant models. Likewise L2 and L 3 tools. (For example, by restricting models identified as intended for EMF to the Level 0 model elements.) And, of course, any drawings or XMI files produced by such a tool will be UML compliant. We have taken care to ensure that. That means that the models stored in any EMF that is fitted to L0 are UML models. The only restriction is that a modeling tool that complies with L0 but not L1 is not a UML modeling tool. Cordially, Joaquin Subject: RE: Compliance points resolution proposal Date: Wed, 18 Aug 2004 18:37:08 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance points resolution proposal Thread-Index: AcSFUCuvJd9JeENRS6Oz5K4mHb8nuAAFJyCgAAnwcsA= From: "Karl Frank" To: , "Thomas Weigert" , "Branislav Selic" , , , X-OriginalArrivalTime: 19 Aug 2004 01:37:10.0828 (UTC) FILETIME=[0BCFFEC0:01C4858D] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7J1p9lj018951 I disagree. To divide OMG open standards modeling into UML plus something else is to shoot UML in the foot in the coming competition for new converts to modeling. The point is not EMF, but maximizing the use and hence importance of UML in the marketplace, a marketplace in which Microsoft is entering with a competing modeling technology, with a simple starter approach, much simpler than Level 1 (Kernel). - Karl -----Original Message----- From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] Sent: Wednesday, August 18, 2004 4:57 PM To: 'Thomas Weigert'; Karl Frank; 'Branislav Selic'; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: RE: Compliance points resolution proposal > But really, L0 is not UML. Let's not create something that is not > really UML but call it UML just because EMF supports this subset. EMF > is not the same as UML. What was the intention of being the most basic > UML was the Kernel that merges all the infrastructure together and > adds a few things that the infrastructure omitted as they were trying > to be a modeling language framework, not a basic version of UML. I am > ok with having a layer that has just the infrastructure, but I am not > ok with calling it UML. Th. I agree with Thomas that this EMF-compatible infrastructural layer should be called something other than UML. To do otherwise will only increase the confusion in the marketplace. -- Cris > -----Original Message----- > From: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Wednesday, August 18, 2004 1:14 PM > To: Thomas Weigert; Branislav Selic; uml2-superstructure- > ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal > > > I made this suggestion a week ago. > > Bran's response then was: > > > > Kernel by itself is not very useful (e.g., it does not even have > dependencies or interfaces). I doubt if it would have many adherents. > Strangely enough, as I explained in my response to Pete, the proposed > Basic by itself is much more meaningful. So, in my view, we either get > rid of L0 altogether or leave it the way it is. > > Bran > > Basic package as Level 0 UML 2 will enable vendors to produce a UML > product to support Eclips EMF and Microsoft's Visual Studio 2005 MDF, > which both incorporate modeling support which does not go beyond > binary references (as simple associations) to include the n-ary > Association Classifier. > > Kernel does include that n-ary Association whihc inherits both > Relationship and Classifier, which makes Kernel way beyond the Java > EMF and the .NET MDF framework support for modeling, and which > therefore motivates, in my opinion, the L0 proposal for compliance. > > - Karl > > ________________________________ > > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > Sent: Wednesday, August 18, 2004 1:47 PM > To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i- > ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal > > > Bran, > > I have one suggestion: Can we put Kernel into L0? L0 otherwise would > be very confusing to UML users. L0 would be the merge of the relevant > part of the infrastructure, which is almost the same, but not exactly > the same, as the Kernel from superstructure. It would be much clearer > if we put Kernel into L0 so that there is no replication of the model > in a slightly different form at L1. > > Also, I think it is wrong to say that the infrastructure, at any > level, is the UML. The infrastructure is merely the common plumbing > for a number of languages, the UML being one of them. It is not, and > never was intended, to be UML, not even in the minimalist L0 > incarnation. Moving Kernel into L0 would make that clear. > > Th. > > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Tuesday, August 17, 2004 5:05 PM > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2- > ftf@omg.org > Subject: Compliance points resolution proposal > > > > After yet more cycles of the proposed resolution between Anders and > Pete and myself, attached, please find a copy of the proposed > resolution to the compliance point issue (6248). > > Since this is a gating issue, I would like to have a definitive FTF > position on this specific resolution before the OMG meeting in > Montreal next week. This likely means having a special vote just on > this resolution outside the usual weekly cycle. > > Regards, > Bran > To: "Karl Frank" Cc: "Branislav Selic" , cris.kobryn@telelogic.com, mu2i-ftf@omg.org, ocl2-ftf@omg.org, "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: Compliance points resolution proposal X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Wed, 18 Aug 2004 22:23:14 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/18/2004 20:23:15, Serialize complete at 08/18/2004 20:23:15 I hate to repeat myself, but it seem like these discussions on compliance are missing the point. It's not what's in one spec vs. another. Its not whether we call it MOF or UML or something else. Its not about promoting EMF. Its not even about what we can get by the AB. Its about establishing a minimum compliance level that will not be a barrier to adoption by most of not all UML tool vendors that ensures we do better than we did with UML 1.x and at least be able to interchange simple structural models. Kernel is too much and can't stand alone without pulling in even more. Even Constructs is too much as evidenced by the compromises in Operation and Package. We have done a lot of work to align MOF and UML. L0 provides a way to leverage that work, and a starting point upon which we can grow. Many tool vendors may choose to implement Kernel and more. Great. I sure hope they do, and know IBM Rational will. But lets be sure tools can at least interchange L0 if nothing else. Doing so requires a compliance level that establishes minimum expectation. If we want to call this something else besides UML L0 or put it in a different spec, then fine. Putting it in MOF is a problem because of the other MOF capabilities (reflection, identity, etc.) that vendors may not want to implement. As many have said, InfrastructureLibrary isn't a language. So UML seem like what we've got. In any case, this just doesn't seem nearly as important as effectively addressing an interoperability challenge we know we have. "Karl Frank" 08/18/2004 09:37 PM To , "Thomas Weigert" , "Branislav Selic" , , , cc Subject RE: Compliance points resolution proposal I disagree. To divide OMG open standards modeling into UML plus something else is to shoot UML in the foot in the coming competition for new converts to modeling. The point is not EMF, but maximizing the use and hence importance of UML in the marketplace, a marketplace in which Microsoft is entering with a competing modeling technology, with a simple starter approach, much simpler than Level 1 (Kernel). - Karl -----Original Message----- From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] Sent: Wednesday, August 18, 2004 4:57 PM To: 'Thomas Weigert'; Karl Frank; 'Branislav Selic'; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: RE: Compliance points resolution proposal > But really, L0 is not UML. Let's not create something that is not > really UML but call it UML just because EMF supports this subset. EMF > is not the same as UML. What was the intention of being the most basic > UML was the Kernel that merges all the infrastructure together and > adds a few things that the infrastructure omitted as they were trying > to be a modeling language framework, not a basic version of UML. I am > ok with having a layer that has just the infrastructure, but I am not > ok with calling it UML. Th. I agree with Thomas that this EMF-compatible infrastructural layer should be called something other than UML. To do otherwise will only increase the confusion in the marketplace. -- Cris > -----Original Message----- > From: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Wednesday, August 18, 2004 1:14 PM > To: Thomas Weigert; Branislav Selic; uml2-superstructure- > ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal > > > I made this suggestion a week ago. > > Bran's response then was: > > > > Kernel by itself is not very useful (e.g., it does not even have > dependencies or interfaces). I doubt if it would have many adherents. > Strangely enough, as I explained in my response to Pete, the proposed > Basic by itself is much more meaningful. So, in my view, we either get > rid of L0 altogether or leave it the way it is. > > Bran > > Basic package as Level 0 UML 2 will enable vendors to produce a UML > product to support Eclips EMF and Microsoft's Visual Studio 2005 MDF, > which both incorporate modeling support which does not go beyond > binary references (as simple associations) to include the n-ary > Association Classifier. > > Kernel does include that n-ary Association whihc inherits both > Relationship and Classifier, which makes Kernel way beyond the Java > EMF and the .NET MDF framework support for modeling, and which > therefore motivates, in my opinion, the L0 proposal for compliance. > > - Karl > > ________________________________ > > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > Sent: Wednesday, August 18, 2004 1:47 PM > To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i- > ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal > > > Bran, > > I have one suggestion: Can we put Kernel into L0? L0 otherwise would > be very confusing to UML users. L0 would be the merge of the relevant > part of the infrastructure, which is almost the same, but not exactly > the same, as the Kernel from superstructure. It would be much clearer > if we put Kernel into L0 so that there is no replication of the model > in a slightly different form at L1. > > Also, I think it is wrong to say that the infrastructure, at any > level, is the UML. The infrastructure is merely the common plumbing > for a number of languages, the UML being one of them. It is not, and > never was intended, to be UML, not even in the minimalist L0 > incarnation. Moving Kernel into L0 would make that clear. > > Th. > > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Tuesday, August 17, 2004 5:05 PM > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2- > ftf@omg.org > Subject: Compliance points resolution proposal > > > > After yet more cycles of the proposed resolution between Anders and > Pete and myself, attached, please find a copy of the proposed > resolution to the compliance point issue (6248). > > Since this is a gating issue, I would like to have a definitive FTF > position on this specific resolution before the OMG meeting in > Montreal next week. This likely means having a special vote just on > this resolution outside the usual weekly cycle. > > Regards, > Bran > To: "Karl Frank" Cc: "Branislav Selic" , cris.kobryn@telelogic.com, mu2i-ftf@omg.org, ocl2-ftf@omg.org, "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: Compliance points resolution proposal X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Wed, 18 Aug 2004 22:23:14 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/18/2004 20:23:15, Serialize complete at 08/18/2004 20:23:15 I hate to repeat myself, but it seem like these discussions on compliance are missing the point. It's not what's in one spec vs. another. Its not whether we call it MOF or UML or something else. Its not about promoting EMF. Its not even about what we can get by the AB. Its about establishing a minimum compliance level that will not be a barrier to adoption by most of not all UML tool vendors that ensures we do better than we did with UML 1.x and at least be able to interchange simple structural models. Kernel is too much and can't stand alone without pulling in even more. Even Constructs is too much as evidenced by the compromises in Operation and Package. We have done a lot of work to align MOF and UML. L0 provides a way to leverage that work, and a starting point upon which we can grow. Many tool vendors may choose to implement Kernel and more. Great. I sure hope they do, and know IBM Rational will. But lets be sure tools can at least interchange L0 if nothing else. Doing so requires a compliance level that establishes minimum expectation. If we want to call this something else besides UML L0 or put it in a different spec, then fine. Putting it in MOF is a problem because of the other MOF capabilities (reflection, identity, etc.) that vendors may not want to implement. As many have said, InfrastructureLibrary isn't a language. So UML seem like what we've got. In any case, this just doesn't seem nearly as important as effectively addressing an interoperability challenge we know we have. "Karl Frank" 08/18/2004 09:37 PM To , "Thomas Weigert" , "Branislav Selic" , , , cc Subject RE: Compliance points resolution proposal I disagree. To divide OMG open standards modeling into UML plus something else is to shoot UML in the foot in the coming competition for new converts to modeling. The point is not EMF, but maximizing the use and hence importance of UML in the marketplace, a marketplace in which Microsoft is entering with a competing modeling technology, with a simple starter approach, much simpler than Level 1 (Kernel). - Karl -----Original Message----- From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] Sent: Wednesday, August 18, 2004 4:57 PM To: 'Thomas Weigert'; Karl Frank; 'Branislav Selic'; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: RE: Compliance points resolution proposal > But really, L0 is not UML. Let's not create something that is not > really UML but call it UML just because EMF supports this subset. EMF > is not the same as UML. What was the intention of being the most basic > UML was the Kernel that merges all the infrastructure together and > adds a few things that the infrastructure omitted as they were trying > to be a modeling language framework, not a basic version of UML. I am > ok with having a layer that has just the infrastructure, but I am not > ok with calling it UML. Th. I agree with Thomas that this EMF-compatible infrastructural layer should be called something other than UML. To do otherwise will only increase the confusion in the marketplace. -- Cris > -----Original Message----- > From: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Wednesday, August 18, 2004 1:14 PM > To: Thomas Weigert; Branislav Selic; uml2-superstructure- > ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal > > > I made this suggestion a week ago. > > Bran's response then was: > > > > Kernel by itself is not very useful (e.g., it does not even have > dependencies or interfaces). I doubt if it would have many adherents. > Strangely enough, as I explained in my response to Pete, the proposed > Basic by itself is much more meaningful. So, in my view, we either get > rid of L0 altogether or leave it the way it is. > > Bran > > Basic package as Level 0 UML 2 will enable vendors to produce a UML > product to support Eclips EMF and Microsoft's Visual Studio 2005 MDF, > which both incorporate modeling support which does not go beyond > binary references (as simple associations) to include the n-ary > Association Classifier. > > Kernel does include that n-ary Association whihc inherits both > Relationship and Classifier, which makes Kernel way beyond the Java > EMF and the .NET MDF framework support for modeling, and which > therefore motivates, in my opinion, the L0 proposal for compliance. > > - Karl > > ________________________________ > > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > Sent: Wednesday, August 18, 2004 1:47 PM > To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i- > ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal > > > Bran, > > I have one suggestion: Can we put Kernel into L0? L0 otherwise would > be very confusing to UML users. L0 would be the merge of the relevant > part of the infrastructure, which is almost the same, but not exactly > the same, as the Kernel from superstructure. It would be much clearer > if we put Kernel into L0 so that there is no replication of the model > in a slightly different form at L1. > > Also, I think it is wrong to say that the infrastructure, at any > level, is the UML. The infrastructure is merely the common plumbing > for a number of languages, the UML being one of them. It is not, and > never was intended, to be UML, not even in the minimalist L0 > incarnation. Moving Kernel into L0 would make that clear. > > Th. > > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Tuesday, August 17, 2004 5:05 PM > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2- > ftf@omg.org > Subject: Compliance points resolution proposal > > > > After yet more cycles of the proposed resolution between Anders and > Pete and myself, attached, please find a copy of the proposed > resolution to the compliance point issue (6248). > > Since this is a gating issue, I would like to have a definitive FTF > position on this specific resolution before the OMG meeting in > Montreal next week. This likely means having a special vote just on > this resolution outside the usual weekly cycle. > > Regards, > Bran > From: "Thomas Weigert" To: "Jim Amsden" , "Karl Frank" Cc: "Branislav Selic" , , , , "Thomas Weigert" , Subject: RE: Compliance points resolution proposal Date: Wed, 18 Aug 2004 21:51:31 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Jim, due to the late hour, I won't harp on this. However, you seem to have missed 4 years of work on UML. We clearly worked towards the following goal: 1. Develop a language to serve as the foundation to define a number of specification languages, such as UML, SPEM, CWM, etc ---> (part of) Infrastructure 2. Develop an extension to (1) to provide additional language definition elements ---> all of infrastructure 3. Develop a new revision of UML on top of the infrastructure ---> superstructure There was never any intention to consider (1) or (2) to be UML. These were just definitional frameworks to define modeling languages, for example, UML. However, UML itself is defined in the superstructure. What you call L0 has nothing to do with UML. It is a language to define UML with. I would not expect any tool to support that L0 (i.e., the infrastructure), as it is not meant to be user visible. Now maybe this strategy has changed over the recent months. However, I have completely missed that change in the discussion, if it in fact occurred. I apologize for this negligence. Th. -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, August 18, 2004 9:23 PM To: Karl Frank Cc: Branislav Selic; cris.kobryn@telelogic.com; mu2i-ftf@omg.org; ocl2-ftf@omg.org; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Compliance points resolution proposal I hate to repeat myself, but it seem like these discussions on compliance are missing the point. It's not what's in one spec vs. another. Its not whether we call it MOF or UML or something else. Its not about promoting EMF. Its not even about what we can get by the AB. Its about establishing a minimum compliance level that will not be a barrier to adoption by most of not all UML tool vendors that ensures we do better than we did with UML 1.x and at least be able to interchange simple structural models. Kernel is too much and can't stand alone without pulling in even more. Even Constructs is too much as evidenced by the compromises in Operation and Package. We have done a lot of work to align MOF and UML. L0 provides a way to leverage that work, and a starting point upon which we can grow. Many tool vendors may choose to implement Kernel and more. Great. I sure hope they do, and know IBM Rational will. But lets be sure tools can at least interchange L0 if nothing else. Doing so requires a compliance level that establishes minimum expectation. If we want to call this something else besides UML L0 or put it in a different spec, then fine. Putting it in MOF is a problem because of the other MOF capabilities (reflection, identity, etc.) that vendors may not want to implement. As many have said, InfrastructureLibrary isn't a language. So UML seem like what we've got. In any case, this just doesn't seem nearly as important as effectively addressing an interoperability challenge we know we have. "Karl Frank" 08/18/2004 09:37 PM To , "Thomas Weigert" , "Branislav Selic" , , , cc Subject RE: Compliance points resolution proposal I disagree. To divide OMG open standards modeling into UML plus something else is to shoot UML in the foot in the coming competition for new converts to modeling. The point is not EMF, but maximizing the use and hence importance of UML in the marketplace, a marketplace in which Microsoft is entering with a competing modeling technology, with a simple starter approach, much simpler than Level 1 (Kernel). - Karl -----Original Message----- From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] Sent: Wednesday, August 18, 2004 4:57 PM To: 'Thomas Weigert'; Karl Frank; 'Branislav Selic'; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: RE: Compliance points resolution proposal > But really, L0 is not UML. Let's not create something that is not > really UML but call it UML just because EMF supports this subset. EMF > is not the same as UML. What was the intention of being the most basic > UML was the Kernel that merges all the infrastructure together and > adds a few things that the infrastructure omitted as they were trying > to be a modeling language framework, not a basic version of UML. I am > ok with having a layer that has just the infrastructure, but I am not > ok with calling it UML. Th. I agree with Thomas that this EMF-compatible infrastructural layer should be called something other than UML. To do otherwise will only increase the confusion in the marketplace. -- Cris > -----Original Message----- > From: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Wednesday, August 18, 2004 1:14 PM > To: Thomas Weigert; Branislav Selic; uml2-superstructure- > ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal > > > I made this suggestion a week ago. > > Bran's response then was: > > > > Kernel by itself is not very useful (e.g., it does not even have > dependencies or interfaces). I doubt if it would have many adherents. > Strangely enough, as I explained in my response to Pete, the proposed > Basic by itself is much more meaningful. So, in my view, we either get > rid of L0 altogether or leave it the way it is. > > Bran > > Basic package as Level 0 UML 2 will enable vendors to produce a UML > product to support Eclips EMF and Microsoft's Visual Studio 2005 MDF, > which both incorporate modeling support which does not go beyond > binary references (as simple associations) to include the n-ary > Association Classifier. > > Kernel does include that n-ary Association whihc inherits both > Relationship and Classifier, which makes Kernel way beyond the Java > EMF and the .NET MDF framework support for modeling, and which > therefore motivates, in my opinion, the L0 proposal for compliance. > > - Karl > > ________________________________ > > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > Sent: Wednesday, August 18, 2004 1:47 PM > To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i- > ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal > > > Bran, > > I have one suggestion: Can we put Kernel into L0? L0 otherwise would > be very confusing to UML users. L0 would be the merge of the relevant > part of the infrastructure, which is almost the same, but not exactly > the same, as the Kernel from superstructure. It would be much clearer > if we put Kernel into L0 so that there is no replication of the model > in a slightly different form at L1. > > Also, I think it is wrong to say that the infrastructure, at any > level, is the UML. The infrastructure is merely the common plumbing > for a number of languages, the UML being one of them. It is not, and > never was intended, to be UML, not even in the minimalist L0 > incarnation. Moving Kernel into L0 would make that clear. > > Th. > > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Tuesday, August 17, 2004 5:05 PM > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2- > ftf@omg.org > Subject: Compliance points resolution proposal > > > > After yet more cycles of the proposed resolution between Anders and > Pete and myself, attached, please find a copy of the proposed > resolution to the compliance point issue (6248). > > Since this is a gating issue, I would like to have a definitive FTF > position on this specific resolution before the OMG meeting in > Montreal next week. This likely means having a special vote just on > this resolution outside the usual weekly cycle. > > Regards, > Bran > To: "Thomas Weigert" Cc: cris.kobryn@telelogic.com, "Jim Amsden" , "Karl Frank" , mu2i-ftf@omg.org, ocl2-ftf@omg.org, "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: Compliance points resolution proposal X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 18 Aug 2004 23:04:40 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/18/2004 23:04:41, Serialize complete at 08/18/2004 23:04:41 As I said, the time for this discussion was in February and March, when the issues were front and centre. I do not think it is appropriate, or fair, to raise these issues now, when we are in a crunch. Bran "Thomas Weigert" wrote on 08/18/2004 10:51:31 PM: > Jim, > > due to the late hour, I won't harp on this. However, you seem to > have missed 4 years of work on UML. We clearly worked towards the > following goal: > > 1. Develop a language to serve as the foundation to define a number > of specification languages, such as UML, SPEM, CWM, etc ---> (part > of) Infrastructure > > 2. Develop an extension to (1) to provide additional language > definition elements ---> all of infrastructure > > 3. Develop a new revision of UML on top of the infrastructure ---> > superstructure > > There was never any intention to consider (1) or (2) to be UML. > These were just definitional frameworks to define modeling > languages, for example, UML. However, UML itself is defined in the > superstructure. > > What you call L0 has nothing to do with UML. It is a language to > define UML with. I would not expect any tool to support that L0 (i. > e., the infrastructure), as it is not meant to be user visible. > > Now maybe this strategy has changed over the recent months. However, > I have completely missed that change in the discussion, if it in > fact occurred. I apologize for this negligence. > > Th. > -----Original Message----- > From: Jim Amsden [mailto:jamsden@us.ibm.com] > Sent: Wednesday, August 18, 2004 9:23 PM > To: Karl Frank > Cc: Branislav Selic; cris.kobryn@telelogic.com; mu2i-ftf@omg.org; > ocl2-ftf@omg.org; Thomas Weigert; uml2-superstructure-ftf@omg.org > Subject: RE: Compliance points resolution proposal > > I hate to repeat myself, but it seem like these discussions on > compliance are missing the point. It's not what's in one spec vs. > another. Its not whether we call it MOF or UML or something else. > Its not about promoting EMF. Its not even about what we can get by > the AB. Its about establishing a minimum compliance level that will > not be a barrier to adoption by most of not all UML tool vendors > that ensures we do better than we did with UML 1.x and at least be > able to interchange simple structural models. > > Kernel is too much and can't stand alone without pulling in even > more. Even Constructs is too much as evidenced by the compromises in > Operation and Package. We have done a lot of work to align MOF and > UML. L0 provides a way to leverage that work, and a starting point > upon which we can grow. Many tool vendors may choose to implement > Kernel and more. Great. I sure hope they do, and know IBM Rational > will. But lets be sure tools can at least interchange L0 if nothing > else. Doing so requires a compliance level that establishes minimum > expectation. > > If we want to call this something else besides UML L0 or put it in a > different spec, then fine. Putting it in MOF is a problem because of > the other MOF capabilities (reflection, identity, etc.) that vendors > may not want to implement. As many have said, InfrastructureLibrary > isn't a language. So UML seem like what we've got. In any case, this > just doesn't seem nearly as important as effectively addressing an > interoperability challenge we know we have. > > > > "Karl Frank" > 08/18/2004 09:37 PM > > To > > , "Thomas Weigert" weigert@motorola.com>, "Branislav Selic" , superstructure-ftf@omg.org>, , > > cc > > Subject > > RE: Compliance points resolution proposal > > > > > I disagree. > > To divide OMG open standards modeling into UML plus something else is to > shoot UML in the foot in the coming competition for new converts to > modeling. > > The point is not EMF, but maximizing the use and hence importance of UML > in the marketplace, a marketplace in which Microsoft is entering with a > competing modeling technology, with a simple starter approach, much > simpler than Level 1 (Kernel). > > - Karl > > -----Original Message----- > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > Sent: Wednesday, August 18, 2004 4:57 PM > To: 'Thomas Weigert'; Karl Frank; 'Branislav Selic'; > uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal > > > But really, L0 is not UML. Let's not create something that is not > > really UML but call it UML just because EMF supports this subset. EMF > > is not the same as UML. What was the intention of being the most basic > > > UML was the Kernel that merges all the infrastructure together and > > adds a few things that the infrastructure omitted as they were trying > > to be a modeling language framework, not a basic version of UML. I am > > ok with having a layer that has just the infrastructure, but I am not > > ok with calling it UML. Th. > > I agree with Thomas that this EMF-compatible infrastructural layer > should be called something other than UML. To do otherwise will only > increase the confusion in the marketplace. > > -- Cris > > > > > -----Original Message----- > > From: Karl Frank [mailto:Karl.Frank@borland.com] > > Sent: Wednesday, August 18, 2004 1:14 PM > > To: Thomas Weigert; Branislav Selic; uml2-superstructure- > > ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > > Subject: RE: Compliance points resolution proposal > > > > > > I made this suggestion a week ago. > > > > Bran's response then was: > > > > > > > > Kernel by itself is not very useful (e.g., it > does not even have > > > dependencies or interfaces). I doubt if it would have many adherents. > > Strangely enough, as I explained in my response to Pete, the proposed > > Basic by itself is much more meaningful. So, in my view, we either get > > > rid of L0 altogether or leave it the way it is. > > > > Bran > > > > Basic package as Level 0 UML 2 will enable > vendors to produce a > UML > > product to support Eclips EMF and Microsoft's Visual Studio 2005 MDF, > > which both incorporate modeling support which does not go beyond > > binary references (as simple associations) to include the n-ary > > Association Classifier. > > > > Kernel does include that n-ary Association whihc > inherits both > > Relationship and Classifier, which makes Kernel way beyond the Java > > EMF and the .NET MDF framework support for modeling, and which > > therefore motivates, in my opinion, the L0 proposal for compliance. > > > > - Karl > > > > ________________________________ > > > > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > > Sent: Wednesday, August 18, 2004 1:47 PM > > To: Branislav Selic; uml2-superstructure-ftf@omg. > org; mu2i- > > ftf@omg.org; ocl2-ftf@omg.org > > Subject: RE: Compliance points resolution proposal > > > > > > Bran, > > > > I have one suggestion: Can we put Kernel into L0? > L0 otherwise > would > > be very confusing to UML users. L0 would be the merge of the relevant > > part of the infrastructure, which is almost the same, but not exactly > > the same, as the Kernel from superstructure. It would be much clearer > > if we put Kernel into L0 so that there is no replication of the model > > in a slightly different form at L1. > > > > Also, I think it is wrong to say that the > infrastructure, at any > > > level, is the UML. The infrastructure is merely the common plumbing > > for a number of languages, the UML being one of them. It is not, and > > never was intended, to be UML, not even in the minimalist L0 > > incarnation. Moving Kernel into L0 would make that clear. > > > > Th. > > > > -----Original Message----- > > From: Branislav Selic [mailto: > bselic@ca.ibm.com] > > Sent: Tuesday, August 17, 2004 5:05 PM > > To: uml2-superstructure-ftf@omg. > org; mu2i-ftf@omg.org; > ocl2- > > ftf@omg.org > > Subject: Compliance points > resolution proposal > > > > > > > > After yet more cycles of the > proposed resolution between > Anders and > > Pete and myself, attached, please find a copy of the proposed > > resolution to the compliance point issue (6248). > > > > Since this is a gating issue, I > would like to have a > definitive FTF > > position on this specific resolution before the OMG meeting in > > Montreal next week. This likely means having a special vote just on > > this resolution outside the usual weekly cycle. > > > > Regards, > > Bran > > > > > > > To: "Thomas Weigert" Cc: cris.kobryn@telelogic.com, "Jim Amsden" , "Karl Frank" , mu2i-ftf@omg.org, ocl2-ftf@omg.org, "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: Compliance points resolution proposal X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 18 Aug 2004 23:04:40 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/18/2004 23:04:41, Serialize complete at 08/18/2004 23:04:41 As I said, the time for this discussion was in February and March, when the issues were front and centre. I do not think it is appropriate, or fair, to raise these issues now, when we are in a crunch. Bran "Thomas Weigert" wrote on 08/18/2004 10:51:31 PM: > Jim, > > due to the late hour, I won't harp on this. However, you seem to > have missed 4 years of work on UML. We clearly worked towards the > following goal: > > 1. Develop a language to serve as the foundation to define a number > of specification languages, such as UML, SPEM, CWM, etc ---> (part > of) Infrastructure > > 2. Develop an extension to (1) to provide additional language > definition elements ---> all of infrastructure > > 3. Develop a new revision of UML on top of the infrastructure ---> > superstructure > > There was never any intention to consider (1) or (2) to be UML. > These were just definitional frameworks to define modeling > languages, for example, UML. However, UML itself is defined in the > superstructure. > > What you call L0 has nothing to do with UML. It is a language to > define UML with. I would not expect any tool to support that L0 (i. > e., the infrastructure), as it is not meant to be user visible. > > Now maybe this strategy has changed over the recent months. However, > I have completely missed that change in the discussion, if it in > fact occurred. I apologize for this negligence. > > Th. > -----Original Message----- > From: Jim Amsden [mailto:jamsden@us.ibm.com] > Sent: Wednesday, August 18, 2004 9:23 PM > To: Karl Frank > Cc: Branislav Selic; cris.kobryn@telelogic.com; mu2i-ftf@omg.org; > ocl2-ftf@omg.org; Thomas Weigert; uml2-superstructure-ftf@omg.org > Subject: RE: Compliance points resolution proposal > > I hate to repeat myself, but it seem like these discussions on > compliance are missing the point. It's not what's in one spec vs. > another. Its not whether we call it MOF or UML or something else. > Its not about promoting EMF. Its not even about what we can get by > the AB. Its about establishing a minimum compliance level that will > not be a barrier to adoption by most of not all UML tool vendors > that ensures we do better than we did with UML 1.x and at least be > able to interchange simple structural models. > > Kernel is too much and can't stand alone without pulling in even > more. Even Constructs is too much as evidenced by the compromises in > Operation and Package. We have done a lot of work to align MOF and > UML. L0 provides a way to leverage that work, and a starting point > upon which we can grow. Many tool vendors may choose to implement > Kernel and more. Great. I sure hope they do, and know IBM Rational > will. But lets be sure tools can at least interchange L0 if nothing > else. Doing so requires a compliance level that establishes minimum > expectation. > > If we want to call this something else besides UML L0 or put it in a > different spec, then fine. Putting it in MOF is a problem because of > the other MOF capabilities (reflection, identity, etc.) that vendors > may not want to implement. As many have said, InfrastructureLibrary > isn't a language. So UML seem like what we've got. In any case, this > just doesn't seem nearly as important as effectively addressing an > interoperability challenge we know we have. > > > > "Karl Frank" > 08/18/2004 09:37 PM > > To > > , "Thomas Weigert" weigert@motorola.com>, "Branislav Selic" , superstructure-ftf@omg.org>, , > > cc > > Subject > > RE: Compliance points resolution proposal > > > > > I disagree. > > To divide OMG open standards modeling into UML plus something else is to > shoot UML in the foot in the coming competition for new converts to > modeling. > > The point is not EMF, but maximizing the use and hence importance of UML > in the marketplace, a marketplace in which Microsoft is entering with a > competing modeling technology, with a simple starter approach, much > simpler than Level 1 (Kernel). > > - Karl > > -----Original Message----- > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > Sent: Wednesday, August 18, 2004 4:57 PM > To: 'Thomas Weigert'; Karl Frank; 'Branislav Selic'; > uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal > > > But really, L0 is not UML. Let's not create something that is not > > really UML but call it UML just because EMF supports this subset. EMF > > is not the same as UML. What was the intention of being the most basic > > > UML was the Kernel that merges all the infrastructure together and > > adds a few things that the infrastructure omitted as they were trying > > to be a modeling language framework, not a basic version of UML. I am > > ok with having a layer that has just the infrastructure, but I am not > > ok with calling it UML. Th. > > I agree with Thomas that this EMF-compatible infrastructural layer > should be called something other than UML. To do otherwise will only > increase the confusion in the marketplace. > > -- Cris > > > > > -----Original Message----- > > From: Karl Frank [mailto:Karl.Frank@borland.com] > > Sent: Wednesday, August 18, 2004 1:14 PM > > To: Thomas Weigert; Branislav Selic; uml2-superstructure- > > ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > > Subject: RE: Compliance points resolution proposal > > > > > > I made this suggestion a week ago. > > > > Bran's response then was: > > > > > > > > Kernel by itself is not very useful (e.g., it > does not even have > > > dependencies or interfaces). I doubt if it would have many adherents. > > Strangely enough, as I explained in my response to Pete, the proposed > > Basic by itself is much more meaningful. So, in my view, we either get > > > rid of L0 altogether or leave it the way it is. > > > > Bran > > > > Basic package as Level 0 UML 2 will enable > vendors to produce a > UML > > product to support Eclips EMF and Microsoft's Visual Studio 2005 MDF, > > which both incorporate modeling support which does not go beyond > > binary references (as simple associations) to include the n-ary > > Association Classifier. > > > > Kernel does include that n-ary Association whihc > inherits both > > Relationship and Classifier, which makes Kernel way beyond the Java > > EMF and the .NET MDF framework support for modeling, and which > > therefore motivates, in my opinion, the L0 proposal for compliance. > > > > - Karl > > > > ________________________________ > > > > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > > Sent: Wednesday, August 18, 2004 1:47 PM > > To: Branislav Selic; uml2-superstructure-ftf@omg. > org; mu2i- > > ftf@omg.org; ocl2-ftf@omg.org > > Subject: RE: Compliance points resolution proposal > > > > > > Bran, > > > > I have one suggestion: Can we put Kernel into L0? > L0 otherwise > would > > be very confusing to UML users. L0 would be the merge of the relevant > > part of the infrastructure, which is almost the same, but not exactly > > the same, as the Kernel from superstructure. It would be much clearer > > if we put Kernel into L0 so that there is no replication of the model > > in a slightly different form at L1. > > > > Also, I think it is wrong to say that the > infrastructure, at any > > > level, is the UML. The infrastructure is merely the common plumbing > > for a number of languages, the UML being one of them. It is not, and > > never was intended, to be UML, not even in the minimalist L0 > > incarnation. Moving Kernel into L0 would make that clear. > > > > Th. > > > > -----Original Message----- > > From: Branislav Selic [mailto: > bselic@ca.ibm.com] > > Sent: Tuesday, August 17, 2004 5:05 PM > > To: uml2-superstructure-ftf@omg. > org; mu2i-ftf@omg.org; > ocl2- > > ftf@omg.org > > Subject: Compliance points > resolution proposal > > > > > > > > After yet more cycles of the > proposed resolution between > Anders and > > Pete and myself, attached, please find a copy of the proposed > > resolution to the compliance point issue (6248). > > > > Since this is a gating issue, I > would like to have a > definitive FTF > > position on this specific resolution before the OMG meeting in > > Montreal next week. This likely means having a special vote just on > > this resolution outside the usual weekly cycle. > > > > Regards, > > Bran > > > > > > > Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 18 Aug 2004 20:07:23 -0700 To: uml2-superstructure-ftf@omg.org From: Joaquin Miller Subject: RE: Compliance points resolution proposal This is job one: effectively addressing an interoperability challenge we know we have These are important, also: maximizing the use and hence importance of UML in the marketplace a minimum compliance level that will not be a barrier to adoption by most, if not all, UML tool vendors Because, if we do job one, then increasing market uptake increases the value of the interoperability we provide. Other crafts have a long way to go before they achieve full interoperability of their design software. But at least they can read and understand each others drawings. We are making progress, but we have a long hike to catch up with that. Finally, this is equally as important as maximizing vendor adoption and market uptake: a language to serve as the foundation to define a number of specification languages From: "Thomas Weigert" To: "Branislav Selic" , "Thomas Weigert" Cc: , "Jim Amsden" , "Karl Frank" , , , "Thomas Weigert" , Subject: RE: Compliance points resolution proposal Date: Wed, 18 Aug 2004 22:09:49 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) As I said, I'll shut up due to the late time I realized this. I just needed to vent my surprise. So sorry... Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, August 18, 2004 10:05 PM To: Thomas Weigert Cc: cris.kobryn@telelogic.com; Jim Amsden; Karl Frank; mu2i-ftf@omg.org; ocl2-ftf@omg.org; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Compliance points resolution proposal As I said, the time for this discussion was in February and March, when the issues were front and centre. I do not think it is appropriate, or fair, to raise these issues now, when we are in a crunch. Bran "Thomas Weigert" wrote on 08/18/2004 10:51:31 PM: > Jim, > > due to the late hour, I won't harp on this. However, you seem to > have missed 4 years of work on UML. We clearly worked towards the > following goal: > > 1. Develop a language to serve as the foundation to define a number > of specification languages, such as UML, SPEM, CWM, etc ---> (part > of) Infrastructure > > 2. Develop an extension to (1) to provide additional language > definition elements ---> all of infrastructure > > 3. Develop a new revision of UML on top of the infrastructure ---> > superstructure > > There was never any intention to consider (1) or (2) to be UML. > These were just definitional frameworks to define modeling > languages, for example, UML. However, UML itself is defined in the > superstructure. > > What you call L0 has nothing to do with UML. It is a language to > define UML with. I would not expect any tool to support that L0 (i. > e., the infrastructure), as it is not meant to be user visible. > > Now maybe this strategy has changed over the recent months. However, > I have completely missed that change in the discussion, if it in > fact occurred. I apologize for this negligence. > > Th. > -----Original Message----- > From: Jim Amsden [mailto:jamsden@us.ibm.com] > Sent: Wednesday, August 18, 2004 9:23 PM > To: Karl Frank > Cc: Branislav Selic; cris.kobryn@telelogic.com; mu2i-ftf@omg.org; > ocl2-ftf@omg.org; Thomas Weigert; uml2-superstructure-ftf@omg.org > Subject: RE: Compliance points resolution proposal > > I hate to repeat myself, but it seem like these discussions on > compliance are missing the point. It's not what's in one spec vs. > another. Its not whether we call it MOF or UML or something else. > Its not about promoting EMF. Its not even about what we can get by > the AB. Its about establishing a minimum compliance level that will > not be a barrier to adoption by most of not all UML tool vendors > that ensures we do better than we did with UML 1.x and at least be > able to interchange simple structural models. > > Kernel is too much and can't stand alone without pulling in even > more. Even Constructs is too much as evidenced by the compromises in > Operation and Package. We have done a lot of work to align MOF and > UML. L0 provides a way to leverage that work, and a starting point > upon which we can grow. Many tool vendors may choose to implement > Kernel and more. Great. I sure hope they do, and know IBM Rational > will. But lets be sure tools can at least interchange L0 if nothing > else. Doing so requires a compliance level that establishes minimum > expectation. > > If we want to call this something else besides UML L0 or put it in a > different spec, then fine. Putting it in MOF is a problem because of > the other MOF capabilities (reflection, identity, etc.) that vendors > may not want to implement. As many have said, InfrastructureLibrary > isn't a language. So UML seem like what we've got. In any case, this > just doesn't seem nearly as important as effectively addressing an > interoperability challenge we know we have. > > > > "Karl Frank" > 08/18/2004 09:37 PM > > To > > , "Thomas Weigert" weigert@motorola.com>, "Branislav Selic" , superstructure-ftf@omg.org>, , > > cc > > Subject > > RE: Compliance points resolution proposal > > > > > I disagree. > > To divide OMG open standards modeling into UML plus something else is to > shoot UML in the foot in the coming competition for new converts to > modeling. > > The point is not EMF, but maximizing the use and hence importance of UML > in the marketplace, a marketplace in which Microsoft is entering with a > competing modeling technology, with a simple starter approach, much > simpler than Level 1 (Kernel). > > - Karl > > -----Original Message----- > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > Sent: Wednesday, August 18, 2004 4:57 PM > To: 'Thomas Weigert'; Karl Frank; 'Branislav Selic'; > uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal > > > But really, L0 is not UML. Let's not create something that is not > > really UML but call it UML just because EMF supports this subset. EMF > > is not the same as UML. What was the intention of being the most basic > > > UML was the Kernel that merges all the infrastructure together and > > adds a few things that the infrastructure omitted as they were trying > > to be a modeling language framework, not a basic version of UML. I am > > ok with having a layer that has just the infrastructure, but I am not > > ok with calling it UML. Th. > > I agree with Thomas that this EMF-compatible infrastructural layer > should be called something other than UML. To do otherwise will only > increase the confusion in the marketplace. > > -- Cris > > > > > -----Original Message----- > > From: Karl Frank [mailto:Karl.Frank@borland.com] > > Sent: Wednesday, August 18, 2004 1:14 PM > > To: Thomas Weigert; Branislav Selic; uml2-superstructure- > > ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > > Subject: RE: Compliance points resolution proposal > > > > > > I made this suggestion a week ago. > > > > Bran's response then was: > > > > > > > > Kernel by itself is not very useful (e.g., it > does not even have > > > dependencies or interfaces). I doubt if it would have many adherents. > > Strangely enough, as I explained in my response to Pete, the proposed > > Basic by itself is much more meaningful. So, in my view, we either get > > > rid of L0 altogether or leave it the way it is. > > > > Bran > > > > Basic package as Level 0 UML 2 will enable > vendors to produce a > UML > > product to support Eclips EMF and Microsoft's Visual Studio 2005 MDF, > > which both incorporate modeling support which does not go beyond > > binary references (as simple associations) to include the n-ary > > Association Classifier. > > > > Kernel does include that n-ary Association whihc > inherits both > > Relationship and Classifier, which makes Kernel way beyond the Java > > EMF and the .NET MDF framework support for modeling, and which > > therefore motivates, in my opinion, the L0 proposal for compliance. > > > > - Karl > > > > ________________________________ > > > > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > > Sent: Wednesday, August 18, 2004 1:47 PM > > To: Branislav Selic; uml2-superstructure-ftf@omg. > org; mu2i- > > ftf@omg.org; ocl2-ftf@omg.org > > Subject: RE: Compliance points resolution proposal > > > > > > Bran, > > > > I have one suggestion: Can we put Kernel into L0? > L0 otherwise > would > > be very confusing to UML users. L0 would be the merge of the relevant > > part of the infrastructure, which is almost the same, but not exactly > > the same, as the Kernel from superstructure. It would be much clearer > > if we put Kernel into L0 so that there is no replication of the model > > in a slightly different form at L1. > > > > Also, I think it is wrong to say that the > infrastructure, at any > > > level, is the UML. The infrastructure is merely the common plumbing > > for a number of languages, the UML being one of them. It is not, and > > never was intended, to be UML, not even in the minimalist L0 > > incarnation. Moving Kernel into L0 would make that clear. > > > > Th. > > > > -----Original Message----- > > From: Branislav Selic [mailto: > bselic@ca.ibm.com] > > Sent: Tuesday, August 17, 2004 5:05 PM > > To: uml2-superstructure-ftf@omg. > org; mu2i-ftf@omg.org; > ocl2- > > ftf@omg.org > > Subject: Compliance points > resolution proposal > > > > > > > > After yet more cycles of the > proposed resolution between > Anders and > > Pete and myself, attached, please find a copy of the proposed > > resolution to the compliance point issue (6248). > > > > Since this is a gating issue, I > would like to have a > definitive FTF > > position on this specific resolution before the OMG meeting in > > Montreal next week. This likely means having a special vote just on > > this resolution outside the usual weekly cycle. > > > > Regards, > > Bran > > > > > > > Reply-To: From: "Cris Kobryn" To: "'Branislav Selic'" , "'Thomas Weigert'" Cc: , "'Jim Amsden'" , "'Karl Frank'" , , , "'Thomas Weigert'" , Subject: RE: Compliance points resolution proposal Date: Wed, 18 Aug 2004 23:26:26 -0700 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcSFmV0AFDArAUNKTLaUImkH86XPAAAAs8tA > As I said, the time for this discussion was in February and March, when > the issues were front and centre. I do not think it is appropriate, or > fair, to raise these issues now, when we are in a crunch. We shouldn't dismiss Thomas's technical and process concerns so quickly. I have raised similar concerns about making radical changes to compliance many times during physical meetings and telecons over the last year, including the February OMG meeting in Anaheim when the "issues were front and centre." So neither Thomas nor I are raising new issues "in a crunch." We are simply trying to help solve tough, old problems (in this case, compliance) that some of us have been wrestling since '97. I suggest we stop beating up on each other with process rhetoric, and focus on solving the technical problems related to compliance that are holding us up. Towards that end, I plan to send out my action item from today's Super FTF telecon (a "compliance support statement" example) later tonight. Thanks, Cris I am extremely concerned that I strongly recommend that we all tone down the process rhetoric, and collaborate on solving the technical However, We shouldn't dismiss Thomas's comments so casually, and need to keep in mind that Re the time for this discuss raising regarding compliance are similar to those that I raised about compliance not only during > "Thomas Weigert" wrote on 08/18/2004 > 10:51:31 PM: > > > Jim, > > > > due to the late hour, I won't harp on this. However, you seem to > > have missed 4 years of work on UML. We clearly worked towards the > > following goal: > > > > 1. Develop a language to serve as the foundation to define a number > > of specification languages, such as UML, SPEM, CWM, etc ---> (part > > of) Infrastructure > > > > 2. Develop an extension to (1) to provide additional language > > definition elements ---> all of infrastructure > > > > 3. Develop a new revision of UML on top of the infrastructure ---> > > superstructure > > > > There was never any intention to consider (1) or (2) to be UML. > > These were just definitional frameworks to define modeling > > languages, for example, UML. However, UML itself is defined in the > > superstructure. > > > > What you call L0 has nothing to do with UML. It is a language to > > define UML with. I would not expect any tool to support that L0 (i. > > e., the infrastructure), as it is not meant to be user visible. > > > > Now maybe this strategy has changed over the recent months. However, > > I have completely missed that change in the discussion, if it in > > fact occurred. I apologize for this negligence. > > > > Th. > > -----Original Message----- > > From: Jim Amsden [mailto:jamsden@us.ibm.com] > > Sent: Wednesday, August 18, 2004 9:23 PM > > To: Karl Frank > > Cc: Branislav Selic; cris.kobryn@telelogic.com; mu2i-ftf@omg.org; > > ocl2-ftf@omg.org; Thomas Weigert; uml2-superstructure-ftf@omg.org > > Subject: RE: Compliance points resolution proposal > > > > > I hate to repeat myself, but it seem like these discussions on > > compliance are missing the point. It's not what's in one spec vs. > > another. Its not whether we call it MOF or UML or something else. > > Its not about promoting EMF. Its not even about what we can get by > > the AB. Its about establishing a minimum compliance level that will > > not be a barrier to adoption by most of not all UML tool vendors > > that ensures we do better than we did with UML 1.x and at least be > > able to interchange simple structural models. > > > > Kernel is too much and can't stand alone without pulling in even > > more. Even Constructs is too much as evidenced by the compromises in > > Operation and Package. We have done a lot of work to align MOF and > > UML. L0 provides a way to leverage that work, and a starting point > > upon which we can grow. Many tool vendors may choose to implement > > Kernel and more. Great. I sure hope they do, and know IBM Rational > > will. But lets be sure tools can at least interchange L0 if nothing > > else. Doing so requires a compliance level that establishes minimum > > expectation. > > > > If we want to call this something else besides UML L0 or put it in a > > different spec, then fine. Putting it in MOF is a problem because of > > the other MOF capabilities (reflection, identity, etc.) that vendors > > may not want to implement. As many have said, InfrastructureLibrary > > isn't a language. So UML seem like what we've got. In any case, this > > just doesn't seem nearly as important as effectively addressing an > > interoperability challenge we know we have. > > > > > > > > > "Karl Frank" > > 08/18/2004 09:37 PM > > > > To > > > > , "Thomas Weigert" > weigert@motorola.com>, "Branislav Selic" , > superstructure-ftf@omg.org>, , > > > > cc > > > > Subject > > > > RE: Compliance points resolution proposal > > > > > > > > > > I disagree. > > > > To divide OMG open standards modeling into UML plus something else is to > > shoot UML in the foot in the coming competition for new converts to > > modeling. > > > > The point is not EMF, but maximizing the use and hence importance of UML > > in the marketplace, a marketplace in which Microsoft is entering with a > > competing modeling technology, with a simple starter approach, much > > simpler than Level 1 (Kernel). > > > > - Karl > > > > -----Original Message----- > > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > > Sent: Wednesday, August 18, 2004 4:57 PM > > To: 'Thomas Weigert'; Karl Frank; 'Branislav Selic'; > > uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > > Subject: RE: Compliance points resolution proposal > > > > > But really, L0 is not UML. Let's not create something that is not > > > really UML but call it UML just because EMF supports this subset. EMF > > > is not the same as UML. What was the intention of being the most basic > > > > > UML was the Kernel that merges all the infrastructure together and > > > adds a few things that the infrastructure omitted as they were trying > > > to be a modeling language framework, not a basic version of UML. I am > > > ok with having a layer that has just the infrastructure, but I am not > > > ok with calling it UML. Th. > > > > I agree with Thomas that this EMF-compatible infrastructural layer > > should be called something other than UML. To do otherwise will only > > increase the confusion in the marketplace. > > > > -- Cris > > > > > > > > > -----Original Message----- > > > From: Karl Frank [mailto:Karl.Frank@borland.com] > > > Sent: Wednesday, August 18, 2004 1:14 PM > > > To: Thomas Weigert; Branislav Selic; uml2- > superstructure- > > > ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > > > Subject: RE: Compliance points resolution proposal > > > > > > > > > I made this suggestion a week ago. > > > > > > Bran's response then was: > > > > > > > > > > > > Kernel by itself is not very useful (e.g., it > > does not even have > > > > > dependencies or interfaces). I doubt if it would have many adherents. > > > Strangely enough, as I explained in my response to Pete, the proposed > > > Basic by itself is much more meaningful. So, in my view, we either get > > > > > rid of L0 altogether or leave it the way it is. > > > > > > Bran > > > > > > Basic package as Level 0 UML 2 will enable > > vendors to produce a > > UML > > > product to support Eclips EMF and Microsoft's Visual Studio 2005 MDF, > > > which both incorporate modeling support which does not go beyond > > > binary references (as simple associations) to include the n-ary > > > Association Classifier. > > > > > > Kernel does include that n-ary Association whihc > > inherits both > > > Relationship and Classifier, which makes Kernel way beyond the Java > > > EMF and the .NET MDF framework support for modeling, and which > > > therefore motivates, in my opinion, the L0 proposal for compliance. > > > > > > - Karl > > > > > > ________________________________ > > > > > > From: Thomas Weigert > [mailto:thomas.weigert@motorola.com] > > > Sent: Wednesday, August 18, 2004 1:47 PM > > > To: Branislav Selic; uml2-superstructure-ftf@omg. > > org; mu2i- > > > ftf@omg.org; ocl2-ftf@omg.org > > > Subject: RE: Compliance points resolution proposal > > > > > > > > > Bran, > > > > > > I have one suggestion: Can we put Kernel into L0? > > L0 otherwise > > would > > > be very confusing to UML users. L0 would be the merge of the relevant > > > part of the infrastructure, which is almost the same, but not exactly > > > the same, as the Kernel from superstructure. It would be much clearer > > > if we put Kernel into L0 so that there is no replication of the model > > > in a slightly different form at L1. > > > > > > Also, I think it is wrong to say that the > > infrastructure, at any > > > > > level, is the UML. The infrastructure is merely the common plumbing > > > for a number of languages, the UML being one of them. It is not, and > > > never was intended, to be UML, not even in the minimalist L0 > > > incarnation. Moving Kernel into L0 would make that clear. > > > > > > Th. > > > > > > -----Original Message----- > > > From: Branislav Selic [mailto: > > bselic@ca.ibm.com] > > > Sent: Tuesday, August 17, 2004 5:05 > PM > > > To: uml2-superstructure-ftf@omg. > > org; mu2i-ftf@omg.org; > > ocl2- > > > ftf@omg.org > > > Subject: Compliance points > > resolution proposal > > > > > > > > > > > > After yet more cycles of the > > proposed resolution between > > Anders and > > > Pete and myself, attached, please find a copy of the proposed > > > resolution to the compliance point issue (6248). > > > > > > Since this is a gating issue, I > > would like to have a > > definitive FTF > > > position on this specific resolution before the OMG meeting in > > > Montreal next week. This likely means having a special vote just on > > > this resolution outside the usual weekly cycle. > > > > > > Regards, > > > Bran > > > > > > > > > > > > > Reply-To: From: "Cris Kobryn" To: "'Branislav Selic'" , , , Subject: RE: Compliance points resolution proposal - "Feature Support Statement" example Date: Wed, 18 Aug 2004 23:56:25 -0700 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcSEqCcvfZFXRFtuQ/qxSd1BzF4AAgBEP/yg FTFers, Attached is an example of a "Feature Support Statement" (formerly known as a"Compliance Support Statement") that Anders and I were asked to generate during today's FTF telecon. Thanks to Bran and Pete for providing review feedback to improve the example prior to sending it out to the mailing list. -- Cris > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Tuesday, August 17, 2004 3:05 PM > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > Subject: Compliance points resolution proposal > > > After yet more cycles of the proposed resolution between Anders and Pete > and myself, attached, please find a copy of the proposed resolution to the > compliance point issue (6248). > > Since this is a gating issue, I would like to have a definitive FTF > position on this specific resolution before the OMG meeting in Montreal > next week. This likely means having a special vote just on this resolution > outside the usual weekly cycle. > > Regards, > Bran Compliance-Feature-Support-Example-040818R4.doc Feature Support Statement Example for Revised UML 2 Compliance Section The following is an example that shows how vendors and profile authors who need to specify partial feature support within a compliance level can do so efficiently via informal "Feature Support Statements" that complement a formal compliance summary. The following paragraph should replace the second full paragraph on p. 127 of the latest "Compliance" draft (see Bran.s 8/17/04 email, Subject = .Compliance points resolution proposal., Attachment = .Compliance.section.addin.040817.pdf.), which begins "Naturally, it is important that ..." Begin Replacement Text ------------------------------------------------------------------------------ It is recognized that some tool vendors and profile authors may need to efficiently define partial feature support within a compliance level. For this reason, in addition to providing a compliance statement that summarizes the formal compliance support for a particular tool or profile, those who need to define partial feature support within a compliance level should use informal Feature Support Statements. Feature Support Statements for a compliance level allow one to define feature support at either the Language Unit or Package level. They also allow one to define feature support types that complement the "Abstract Syntax" and "Concrete Syntax" compliance types. Special feature support types include, but are not limited to, the following: Action Semantics, Dynamic (Run-time) Semantics, Presentation Options, and Semantic Variation Points. ------------------------------------------------------------------------------ End Replacement Text The following example should follow section 1.4 Compliance Level Contents, since it is uses the package breakdown described in section 1.4. Begin Example ------------------------------------------------------------------------------ Figure N shows an example of a Compliance Summary, and Figure N+1 shows an example of an L2 Feature Support Statement for a UML implementation that complies with Level 0 and Level 1, but only selectively supports features within Level 2: Table N: Compliance Summary Example Compliance Summary Level Compliance Level 0 Abstract Syntax Level 1 Abstract Syntax, Concrete Syntax Level 2 See L2 Feature Support Statement Table N+1: Feature Support Statement Example L2 Feature Support Statement Language Unit Packages Support Actions Actions::StructuredActionsActions::IntermediateActions Abstract Syntax, Action Semantics,Dynamic Semantics Activities Activities::IntermediateActivities Abstract Syntax,Concrete Syntax Activities::StructuredActivities None Components Components::BasicComponents None Deployments Deployments::Artifacts Abstract Syntax and Concrete Syntax including (Deployment, .) Deployments::Nodes Abstract Syntax andConcrete Syntax excluding(Device, .) General Behavior CommonBehaviors::Communications Abstract Syntax,Concrete Syntax, Semantic Variation Points (Operation/Resolution, .) CommonBehaviors::SimpleTime None Interactions Interactions::Fragments Abstract Syntax,Concrete Syntax, Presentation Options (CombinedFragment/CoRegion Area, .) Profiles AuxilliaryConstructs::Profiles Abstract Syntax,Concrete Syntax Structures CompositeStructures::InvocationActions None CompositeStructures::PortsCompositeStructures::StructuredClasses Abstract Syntax,Concrete Syntax State Machines StateMachines::BehaviorStateMachines Abstract Syntax,Concrete Syntax, Action Semantics,Dynamic Semantics ------------------------------------------------------------------------------ End Example To: Cc: mu2i-ftf@omg.org, ocl2-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Compliance points resolution proposal - "Feature Support Statement" example X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 19 Aug 2004 08:23:01 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/19/2004 08:23:07, Serialize complete at 08/19/2004 08:23:07 Thanks Cris and Anders. Both the text and the example look very good to me. My only nit here is the use of the term "Dynamic semantics" in some of the table entries. I suggest adding a parenthesized phrase such as "(see addendum)" or possibly an asterisk next to it would be useful, since there is great variability in this area. This would be some kind of pointer to a more detailed statement for those who are interested about which semantic variation choices were made. I don't think we need to provide a concrete example. Regards, Bran "Cris Kobryn" 08/19/2004 02:56 AM Please respond to cris.kobryn To Branislav Selic/Ottawa/IBM@IBMCA, , , cc Subject RE: Compliance points resolution proposal - "Feature Support Statement" example FTFers, Attached is an example of a "Feature Support Statement" (formerly known as a"Compliance Support Statement") that Anders and I were asked to generate during today's FTF telecon. Thanks to Bran and Pete for providing review feedback to improve the example prior to sending it out to the mailing list. -- Cris > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Tuesday, August 17, 2004 3:05 PM > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > Subject: Compliance points resolution proposal > > > After yet more cycles of the proposed resolution between Anders and Pete > and myself, attached, please find a copy of the proposed resolution to the > compliance point issue (6248). > > Since this is a gating issue, I would like to have a definitive FTF > position on this specific resolution before the OMG meeting in Montreal > next week. This likely means having a special vote just on this resolution > outside the usual weekly cycle. > > Regards, > Bran [attachment "Compliance-Feature-Support-Example-040818R4.doc" deleted by Branislav Selic/Ottawa/IBM] Subject: RE: Compliance points resolution proposal - "Feature Support Statement" example Date: Thu, 19 Aug 2004 08:36:48 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance points resolution proposal - "Feature Support Statement" example Thread-Index: AcSEqCcvfZFXRFtuQ/qxSd1BzF4AAgBEP/ygAAsgYJA= From: "Pete Rivett" To: , "Branislav Selic" , , , X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7JCh3lj023375 I'm not sure the Compliance Summary needs to list levels *beneath* that which compliance is claimed - since compliance at level N automatically implies/requires support at Level N-1 (start of section 1.3 of the new section states: "Compliance to a given level entails full realization of all language units that are defined for that compliance level (note that this implies compliance with all levels below it)." So, the example is not actually valid: it is not possible to have Concrete Syntax compliance at Level 1 but not at Level 0. With respect to the feature support table I think we (or a vendor claiming support)needs to have more definition of the terms than, for example, 'Action Semantics' or 'Dynamic Semantics': since the spec does not already define what it means to support dynamic semantics for a package - which is one of the reasons it is not included in the formal compliance levels. And 'Action Semantics' is even less clear (how does it differ from Dynamic Semantics for the Actions package(s)?). Not sure it's necessary to have entries where no support is claimed, but I'm not that bothered. I think the section should include very specific examples of support for presentation options and semantic variation points: I think for these the table approach may become awkward which is why I originally suggested a semi-structured English approach. Maybe we could have a table followed by semi-structured text for the latter? Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > Sent: Thursday, August 19, 2004 1:56 AM > To: 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > mu2i-ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal - "Feature > Support Statement" example > > FTFers, > > Attached is an example of a "Feature Support Statement" > (formerly known as > a"Compliance Support Statement") that Anders and I were asked > to generate > during today's FTF telecon. > > Thanks to Bran and Pete for providing review feedback to > improve the example > prior to sending it out to the mailing list. > > -- Cris > > > > -----Original Message----- > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > Sent: Tuesday, August 17, 2004 3:05 PM > > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; > ocl2-ftf@omg.org > > Subject: Compliance points resolution proposal > > > > > > After yet more cycles of the proposed resolution between > Anders and Pete > > and myself, attached, please find a copy of the proposed > resolution to the > > compliance point issue (6248). > > > > Since this is a gating issue, I would like to have a definitive FTF > > position on this specific resolution before the OMG meeting > in Montreal > > next week. This likely means having a special vote just on > this resolution > > outside the usual weekly cycle. > > > > Regards, > > Bran > > Subject: RE: Compliance points resolution proposal - "Feature Support Statement" example Date: Thu, 19 Aug 2004 08:36:48 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance points resolution proposal - "Feature Support Statement" example Thread-Index: AcSEqCcvfZFXRFtuQ/qxSd1BzF4AAgBEP/ygAAsgYJA= From: "Pete Rivett" To: , "Branislav Selic" , , , X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7JCh3lj023376 I'm not sure the Compliance Summary needs to list levels *beneath* that which compliance is claimed - since compliance at level N automatically implies/requires support at Level N-1 (start of section 1.3 of the new section states: "Compliance to a given level entails full realization of all language units that are defined for that compliance level (note that this implies compliance with all levels below it)." So, the example is not actually valid: it is not possible to have Concrete Syntax compliance at Level 1 but not at Level 0. With respect to the feature support table I think we (or a vendor claiming support)needs to have more definition of the terms than, for example, 'Action Semantics' or 'Dynamic Semantics': since the spec does not already define what it means to support dynamic semantics for a package - which is one of the reasons it is not included in the formal compliance levels. And 'Action Semantics' is even less clear (how does it differ from Dynamic Semantics for the Actions package(s)?). Not sure it's necessary to have entries where no support is claimed, but I'm not that bothered. I think the section should include very specific examples of support for presentation options and semantic variation points: I think for these the table approach may become awkward which is why I originally suggested a semi-structured English approach. Maybe we could have a table followed by semi-structured text for the latter? Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > Sent: Thursday, August 19, 2004 1:56 AM > To: 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > mu2i-ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal - "Feature > Support Statement" example > > FTFers, > > Attached is an example of a "Feature Support Statement" > (formerly known as > a"Compliance Support Statement") that Anders and I were asked > to generate > during today's FTF telecon. > > Thanks to Bran and Pete for providing review feedback to > improve the example > prior to sending it out to the mailing list. > > -- Cris > > > > -----Original Message----- > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > Sent: Tuesday, August 17, 2004 3:05 PM > > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; > ocl2-ftf@omg.org > > Subject: Compliance points resolution proposal > > > > > > After yet more cycles of the proposed resolution between > Anders and Pete > > and myself, attached, please find a copy of the proposed > resolution to the > > compliance point issue (6248). > > > > Since this is a gating issue, I would like to have a definitive FTF > > position on this specific resolution before the OMG meeting > in Montreal > > next week. This likely means having a special vote just on > this resolution > > outside the usual weekly cycle. > > > > Regards, > > Bran > > Subject: RE: Compliance points resolution proposal - "Feature Support Statement" example Date: Thu, 19 Aug 2004 08:36:48 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance points resolution proposal - "Feature Support Statement" example Thread-Index: AcSEqCcvfZFXRFtuQ/qxSd1BzF4AAgBEP/ygAAsgYJA= From: "Pete Rivett" To: , "Branislav Selic" , , , X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7JCh3lj023377 I'm not sure the Compliance Summary needs to list levels *beneath* that which compliance is claimed - since compliance at level N automatically implies/requires support at Level N-1 (start of section 1.3 of the new section states: "Compliance to a given level entails full realization of all language units that are defined for that compliance level (note that this implies compliance with all levels below it)." So, the example is not actually valid: it is not possible to have Concrete Syntax compliance at Level 1 but not at Level 0. With respect to the feature support table I think we (or a vendor claiming support)needs to have more definition of the terms than, for example, 'Action Semantics' or 'Dynamic Semantics': since the spec does not already define what it means to support dynamic semantics for a package - which is one of the reasons it is not included in the formal compliance levels. And 'Action Semantics' is even less clear (how does it differ from Dynamic Semantics for the Actions package(s)?). Not sure it's necessary to have entries where no support is claimed, but I'm not that bothered. I think the section should include very specific examples of support for presentation options and semantic variation points: I think for these the table approach may become awkward which is why I originally suggested a semi-structured English approach. Maybe we could have a table followed by semi-structured text for the latter? Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > Sent: Thursday, August 19, 2004 1:56 AM > To: 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > mu2i-ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal - "Feature > Support Statement" example > > FTFers, > > Attached is an example of a "Feature Support Statement" > (formerly known as > a"Compliance Support Statement") that Anders and I were asked > to generate > during today's FTF telecon. > > Thanks to Bran and Pete for providing review feedback to > improve the example > prior to sending it out to the mailing list. > > -- Cris > > > > -----Original Message----- > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > Sent: Tuesday, August 17, 2004 3:05 PM > > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; > ocl2-ftf@omg.org > > Subject: Compliance points resolution proposal > > > > > > After yet more cycles of the proposed resolution between > Anders and Pete > > and myself, attached, please find a copy of the proposed > resolution to the > > compliance point issue (6248). > > > > Since this is a gating issue, I would like to have a definitive FTF > > position on this specific resolution before the OMG meeting > in Montreal > > next week. This likely means having a special vote just on > this resolution > > outside the usual weekly cycle. > > > > Regards, > > Bran > > To: "Pete Rivett" Cc: cris.kobryn@telelogic.com, mu2i-ftf@omg.org, ocl2-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Compliance points resolution proposal - "Feature Support Statement" example X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 19 Aug 2004 08:53:29 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/19/2004 08:53:31, Serialize complete at 08/19/2004 08:53:31 Good eye, Pete. I missed some of the details you've identified. > I'm not sure the Compliance Summary needs to list levels *beneath* that > which compliance is claimed - since compliance at level N automatically > implies/requires support at Level N-1 (start of section 1.3 of the new > section states: "Compliance to a given level entails full realization of > all language units that are defined for that compliance level (note that > this implies compliance with all levels below it)." > So, the example is not actually valid: it is not possible to have > Concrete Syntax compliance at Level 1 but not at Level 0. Missed that. I agree with Pete. > With respect to the feature support table I think we (or a vendor > claiming support)needs to have more definition of the terms than, for > example, 'Action Semantics' or 'Dynamic Semantics': since the spec does > not already define what it means to support dynamic semantics for a > package - which is one of the reasons it is not included in the formal > compliance levels. And 'Action Semantics' is even less clear (how does > it differ from Dynamic Semantics for the Actions package(s)?). I missed the Action Semantics part as well. There is no such beast. Presumably, this is part of the dynamic semantics support. You and I seem to agree that the dynamic semantics (and likely presentation options) should have an additional statement. Given the great degree of variability, it seems that this part would be more compact if it was in text form; e.g.: Dynamic semantics supported: - Events in the event pool are dispatched in FIFO order - Messages are assumed to be delivered in sending order Presentation options supported: - Action-oriented style of transition representation ... Regards, Bran To: "Pete Rivett" Cc: cris.kobryn@telelogic.com, mu2i-ftf@omg.org, ocl2-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Compliance points resolution proposal - "Feature Support Statement" example X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 19 Aug 2004 08:53:29 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/19/2004 08:53:31, Serialize complete at 08/19/2004 08:53:31 Good eye, Pete. I missed some of the details you've identified. > I'm not sure the Compliance Summary needs to list levels *beneath* that > which compliance is claimed - since compliance at level N automatically > implies/requires support at Level N-1 (start of section 1.3 of the new > section states: "Compliance to a given level entails full realization of > all language units that are defined for that compliance level (note that > this implies compliance with all levels below it)." > So, the example is not actually valid: it is not possible to have > Concrete Syntax compliance at Level 1 but not at Level 0. Missed that. I agree with Pete. > With respect to the feature support table I think we (or a vendor > claiming support)needs to have more definition of the terms than, for > example, 'Action Semantics' or 'Dynamic Semantics': since the spec does > not already define what it means to support dynamic semantics for a > package - which is one of the reasons it is not included in the formal > compliance levels. And 'Action Semantics' is even less clear (how does > it differ from Dynamic Semantics for the Actions package(s)?). I missed the Action Semantics part as well. There is no such beast. Presumably, this is part of the dynamic semantics support. You and I seem to agree that the dynamic semantics (and likely presentation options) should have an additional statement. Given the great degree of variability, it seems that this part would be more compact if it was in text form; e.g.: Dynamic semantics supported: - Events in the event pool are dispatched in FIFO order - Messages are assumed to be delivered in sending order Presentation options supported: - Action-oriented style of transition representation ... Regards, Bran To: "Pete Rivett" Cc: cris.kobryn@telelogic.com, mu2i-ftf@omg.org, ocl2-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Compliance points resolution proposal - "Feature Support Statement" example X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 19 Aug 2004 08:53:29 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/19/2004 08:53:31, Serialize complete at 08/19/2004 08:53:31 Good eye, Pete. I missed some of the details you've identified. > I'm not sure the Compliance Summary needs to list levels *beneath* that > which compliance is claimed - since compliance at level N automatically > implies/requires support at Level N-1 (start of section 1.3 of the new > section states: "Compliance to a given level entails full realization of > all language units that are defined for that compliance level (note that > this implies compliance with all levels below it)." > So, the example is not actually valid: it is not possible to have > Concrete Syntax compliance at Level 1 but not at Level 0. Missed that. I agree with Pete. > With respect to the feature support table I think we (or a vendor > claiming support)needs to have more definition of the terms than, for > example, 'Action Semantics' or 'Dynamic Semantics': since the spec does > not already define what it means to support dynamic semantics for a > package - which is one of the reasons it is not included in the formal > compliance levels. And 'Action Semantics' is even less clear (how does > it differ from Dynamic Semantics for the Actions package(s)?). I missed the Action Semantics part as well. There is no such beast. Presumably, this is part of the dynamic semantics support. You and I seem to agree that the dynamic semantics (and likely presentation options) should have an additional statement. Given the great degree of variability, it seems that this part would be more compact if it was in text form; e.g.: Dynamic semantics supported: - Events in the event pool are dispatched in FIFO order - Messages are assumed to be delivered in sending order Presentation options supported: - Action-oriented style of transition representation ... Regards, Bran Subject: RE: Compliance points resolution proposal - "Feature Support Statement" example Date: Thu, 19 Aug 2004 15:24:01 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance points resolution proposal - "Feature Support Statement" example Thread-Index: AcSEqCcvfZFXRFtuQ/qxSd1BzF4AAgBEP/ygAAsgYJAAAm3eYA== From: "Anders Ek" To: "Pete Rivett" , "Cris Kobryn" , "Branislav Selic" , , , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7JDdGlj024598 I think Pete's last sentence in this email is a very good suggestion: To have a table as a summary + a semistructured text to sort out details in e.g. the support for dynamic semantics. This will both give us the nice overview that a table provides and a possibility to give fairly long descriptions of lower-level details. Regards Anders > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: den 19 augusti 2004 14:37 > To: Cris Kobryn; Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i- > ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal - "Feature Support > Statement" example > > I'm not sure the Compliance Summary needs to list levels *beneath* that > which compliance is claimed - since compliance at level N automatically > implies/requires support at Level N-1 (start of section 1.3 of the new > section states: "Compliance to a given level entails full realization of > all language units that are defined for that compliance level (note that > this implies compliance with all levels below it)." > So, the example is not actually valid: it is not possible to have > Concrete Syntax compliance at Level 1 but not at Level 0. > > With respect to the feature support table I think we (or a vendor > claiming support)needs to have more definition of the terms than, for > example, 'Action Semantics' or 'Dynamic Semantics': since the spec does > not already define what it means to support dynamic semantics for a > package - which is one of the reasons it is not included in the formal > compliance levels. And 'Action Semantics' is even less clear (how does > it differ from Dynamic Semantics for the Actions package(s)?). > > Not sure it's necessary to have entries where no support is claimed, but > I'm not that bothered. > > I think the section should include very specific examples of support for > presentation options and semantic variation points: I think for these > the table approach may become awkward which is why I originally > suggested a semi-structured English approach. Maybe we could have a > table followed by semi-structured text for the latter? > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > Chief Scientist, 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: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > > Sent: Thursday, August 19, 2004 1:56 AM > > To: 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > > mu2i-ftf@omg.org; ocl2-ftf@omg.org > > Subject: RE: Compliance points resolution proposal - "Feature > > Support Statement" example > > > > FTFers, > > > > Attached is an example of a "Feature Support Statement" > > (formerly known as > > a"Compliance Support Statement") that Anders and I were asked > > to generate > > during today's FTF telecon. > > > > Thanks to Bran and Pete for providing review feedback to > > improve the example > > prior to sending it out to the mailing list. > > > > -- Cris > > > > > > > -----Original Message----- > > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > > Sent: Tuesday, August 17, 2004 3:05 PM > > > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; > > ocl2-ftf@omg.org > > > Subject: Compliance points resolution proposal > > > > > > > > > After yet more cycles of the proposed resolution between > > Anders and Pete > > > and myself, attached, please find a copy of the proposed > > resolution to the > > > compliance point issue (6248). > > > > > > Since this is a gating issue, I would like to have a definitive FTF > > > position on this specific resolution before the OMG meeting > > in Montreal > > > next week. This likely means having a special vote just on > > this resolution > > > outside the usual weekly cycle. > > > > > > Regards, > > > Bran > > > > Date: Thu, 19 Aug 2004 09:59:04 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard SGBU/MSO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: Anders Ek Cc: Pete Rivett , Cris Kobryn , Branislav Selic , uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org, ocl2-ftf@omg.org Subject: Re: Compliance points resolution proposal - "Feature Support Statement" example +1 I agree. Jishnu. Anders Ek wrote: I think Pete's last sentence in this email is a very good suggestion: To have a table as a summary + a semistructured text to sort out details in e.g. the support for dynamic semantics. This will both give us the nice overview that a table provides and a possibility to give fairly long descriptions of lower-level details. Regards Anders -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: den 19 augusti 2004 14:37 To: Cris Kobryn; Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i- ftf@omg.org; ocl2-ftf@omg.org Subject: RE: Compliance points resolution proposal - "Feature Support Statement" example I'm not sure the Compliance Summary needs to list levels *beneath* that which compliance is claimed - since compliance at level N automatically implies/requires support at Level N-1 (start of section 1.3 of the new section states: "Compliance to a given level entails full realization of all language units that are defined for that compliance level (note that this implies compliance with all levels below it)." So, the example is not actually valid: it is not possible to have Concrete Syntax compliance at Level 1 but not at Level 0. With respect to the feature support table I think we (or a vendor claiming support)needs to have more definition of the terms than, for example, 'Action Semantics' or 'Dynamic Semantics': since the spec does not already define what it means to support dynamic semantics for a package - which is one of the reasons it is not included in the formal compliance levels. And 'Action Semantics' is even less clear (how does it differ from Dynamic Semantics for the Actions package(s)?). Not sure it's necessary to have entries where no support is claimed, but I'm not that bothered. I think the section should include very specific examples of support for presentation options and semantic variation points: I think for these the table approach may become awkward which is why I originally suggested a semi-structured English approach. Maybe we could have a table followed by semi-structured text for the latter? Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Cris Kobryn [mailto:cris.kobryn@telelogic.com] Sent: Thursday, August 19, 2004 1:56 AM To: 'Branislav Selic'; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: RE: Compliance points resolution proposal - "Feature Support Statement" example FTFers, Attached is an example of a "Feature Support Statement" (formerly known as a"Compliance Support Statement") that Anders and I were asked to generate during today's FTF telecon. Thanks to Bran and Pete for providing review feedback to improve the example prior to sending it out to the mailing list. -- Cris -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 17, 2004 3:05 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Compliance points resolution proposal After yet more cycles of the proposed resolution between Anders and Pete and myself, attached, please find a copy of the proposed resolution to the compliance point issue (6248). Since this is a gating issue, I would like to have a definitive FTF position on this specific resolution before the OMG meeting in Montreal next week. This likely means having a special vote just on this resolution outside the usual weekly cycle. Regards, Bran -- Jishnu Mukerji Senior Systems Architect 1001 Frontier Road, Suite 300 Technology Office Bridgewater NJ 08807, USA Management Software Organization Tel: +1 908 243 8924 Hewlett-Packard Company Fax: +1 908 243 8850 mailto: jishnu@hp.com Reply-To: From: "Cris Kobryn" To: "'Pete Rivett'" , , "'Branislav Selic'" , , , Subject: RE: Compliance points resolution proposal - "Feature Support Statement" example Date: Thu, 19 Aug 2004 10:03:08 -0700 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcSEqCcvfZFXRFtuQ/qxSd1BzF4AAgBEP/ygAAsgYJAAB81RcA== > I'm not sure the Compliance Summary needs to list levels *beneath* that > which compliance is claimed - since compliance at level N automatically > implies/requires support at Level N-1 (start of section 1.3 of the new > section states: "Compliance to a given level entails full realization of > all language units that are defined for that compliance level (note that > this implies compliance with all levels below it)." > So, the example is not actually valid: it is not possible to have > Concrete Syntax compliance at Level 1 but not at Level 0. Although I am inclined to agree with your intention here, I disagree that what you are saying is clearly explained by the current spec draft. The sentence you cite is insufficient, since the section that defines the "two distinct types of compliance" (section 1.3, par. 3) does not explain what the individual or combined (i.e., "both") usage of the distinct types implies for lower levels. I further note that Concrete Syntax compliance no longer addresses Diagram Interchange compliance, which Bran's 8/8/04 email proposal included (although the 8/8/04 draft referred to it as "UML Design Interchange specification"). What happened here? Was this a publicly discussed consensus decision on a mailing list, or has the OMG formally dropped the UML 2 DI specification? If UML 2 DI is still part of the UML 2 FAS quartet, we need to address DI compliance in some sort of straightforward manner. What to do? I am inclined to your support your point if we: 1) include Diagram Interchange compliance; 2) explain clearly what the implications of using "Abstract Syntax", "Concrete Syntax", "Diagram Interchange" and combinations of them are for lower levels. > > With respect to the feature support table I think we (or a vendor > claiming support)needs to have more definition of the terms than, for > example, 'Action Semantics' or 'Dynamic Semantics': since the spec does > not already define what it means to support dynamic semantics for a > package - which is one of the reasons it is not included in the formal > compliance levels. And 'Action Semantics' is even less clear (how does > it differ from Dynamic Semantics for the Actions package(s)?). I agree, and also think we can whack "Action Semantics". > Not sure it's necessary to have entries where no support is claimed, but > I'm not that bothered. Good. > I think the section should include very specific examples of support for > presentation options and semantic variation points: I think for these > the table approach may become awkward which is why I originally > suggested a semi-structured English approach. Maybe we could have a > table followed by semi-structured text for the latter? There should always be the option to elaborate on anything, and if we want to add semi-structured text to further explain the example, I am fine with that! Thanks, Cris > > -----Original Message----- > > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > > Sent: Thursday, August 19, 2004 1:56 AM > > To: 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > > mu2i-ftf@omg.org; ocl2-ftf@omg.org > > Subject: RE: Compliance points resolution proposal - "Feature > > Support Statement" example > > > > FTFers, > > > > Attached is an example of a "Feature Support Statement" > > (formerly known as > > a"Compliance Support Statement") that Anders and I were asked > > to generate > > during today's FTF telecon. > > > > Thanks to Bran and Pete for providing review feedback to > > improve the example > > prior to sending it out to the mailing list. > > > > -- Cris > > > > > > > -----Original Message----- > > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > > Sent: Tuesday, August 17, 2004 3:05 PM > > > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; > > ocl2-ftf@omg.org > > > Subject: Compliance points resolution proposal > > > > > > > > > After yet more cycles of the proposed resolution between > > Anders and Pete > > > and myself, attached, please find a copy of the proposed > > resolution to the > > > compliance point issue (6248). > > > > > > Since this is a gating issue, I would like to have a definitive FTF > > > position on this specific resolution before the OMG meeting > > in Montreal > > > next week. This likely means having a special vote just on > > this resolution > > > outside the usual weekly cycle. > > > > > > Regards, > > > Bran > > > > Reply-To: From: "Cris Kobryn" To: "'Branislav Selic'" , "'Pete Rivett'" Cc: , , , Subject: RE: Compliance points resolution proposal - "Feature Support Statement" example Date: Thu, 19 Aug 2004 10:38:42 -0700 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcSF65NmELQNM1RRSJ+t0mK5AwAF3AAJk8sw > > I'm not sure the Compliance Summary needs to list levels *beneath* that > > which compliance is claimed - since compliance at level N automatically > > implies/requires support at Level N-1 (start of section 1.3 of the new > > section states: "Compliance to a given level entails full realization of > > all language units that are defined for that compliance level (note that > > this implies compliance with all levels below it)." > > So, the example is not actually valid: it is not possible to have > > Concrete Syntax compliance at Level 1 but not at Level 0. > > Missed that. I agree with Pete. I am also ok with this, as long as we address the issues I raised in my previous email: 1) *somehow* address Diagram Interchange compliance; 2) explain clearly what the implications of using "Abstract Syntax", "Concrete Syntax", "Diagram Interchange" and combinations of them are for lower levels. > > With respect to the feature support table I think we (or a vendor > > claiming support)needs to have more definition of the terms than, for > > example, 'Action Semantics' or 'Dynamic Semantics': since the spec does > > not already define what it means to support dynamic semantics for a > > package - which is one of the reasons it is not included in the formal > > compliance levels. And 'Action Semantics' is even less clear (how does > > it differ from Dynamic Semantics for the Actions package(s)?). > > I missed the Action Semantics part as well. There is no such beast. > Presumably, this is part of the dynamic semantics support. I concur that this should be terminated with extreme prejudice. > You and I seem to agree that the dynamic semantics > (and likely presentation options) > should have an additional statement. Given the great degree of > variability, it seems that this part would be more compact if it was in > text form; e.g.: I don't see how this is inherently more compact, but recognize the need here, as elsewhere, for "semi-structured" text elaboration. So let's keep the table entry in the example for consistency, but add the statements for completeness. -- Cris To: Cc: cris.kobryn@telelogic.com, mu2i-ftf@omg.org, ocl2-ftf@omg.org, "'Pete Rivett'" , uml2-superstructure-ftf@omg.org Subject: RE: Compliance points resolution proposal - "Feature Support Statement" example X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 19 Aug 2004 13:59:09 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/19/2004 14:03:27, Serialize complete at 08/19/2004 14:03:27 Cris, > > I'm not sure the Compliance Summary needs to list levels *beneath* that > > which compliance is claimed - since compliance at level N automatically > > implies/requires support at Level N-1 (start of section 1.3 of the new > > section states: "Compliance to a given level entails full realization of > > all language units that are defined for that compliance level (note that > > this implies compliance with all levels below it)." > > So, the example is not actually valid: it is not possible to have > > Concrete Syntax compliance at Level 1 but not at Level 0. > > Although I am inclined to agree with your intention here, I disagree that > what you are saying is clearly explained by the current spec draft. The > sentence you cite is insufficient, since the section that defines the "two > distinct types of compliance" (section 1.3, par. 3) does not explain what > the individual or combined (i.e., "both") usage of the distinct types > implies for lower levels. It seemed to me that saying that compliance to a given level implies compliance with all levels below it would take care of that case. But, that is easily rectified. I will add the clarification. Note that since the two types of compliance are independent of each other there are no coupling effects brought that ocme into play when they are combined. > I further note that Concrete Syntax compliance no longer addresses Diagram > Interchange compliance, which Bran's 8/8/04 email proposal included > (although the 8/8/04 draft referred to it as "UML Design Interchange > specification"). What happened here? Was this a publicly discussed consensus > decision on a mailing list, or has the OMG formally dropped the UML 2 DI > specification? If UML 2 DI is still part of the UML 2 FAS quartet, we need > to address DI compliance in some sort of straightforward manner. There was a public discussion on this point and the conclusion was to remove reference to DI compliance. This is because it was pointed out that DI elements have a pointer to model elements and are, therefore, it is not separable as an independent compliance type. Note that the other two compliance types are independent of each other. As for DI compliance, it is appropriate to declare that in the DI spec itself, rather than in the Superstructure (note that the coupling between these two specs is strictly one way: the DI depends on the superstructure but not the other way around). Unfortunately, that FTF is working at a different pace and it will likely require further delays before they are finished. > What to do? I am inclined to your support your point if we: 1) include > Diagram Interchange compliance; 2) explain clearly what the implications of > using "Abstract Syntax", "Concrete Syntax", "Diagram Interchange" and > combinations of them are for lower levels. I am afraid that, with time running out, we no longer have the luxury to ponder these "what if" scenarios. We have to make a decision and the mechanism by which this is done in such circumstances is by voting. Therefore, I will be issuing the special compliance point ballot tomorrow morning with what I think represents the majority opinion of what this text should look like. I will do my best to incorporate all the feedback that was provided. If people feel that they can contribute to this, please forward me your suggestions. Cheers...Bran To: Cc: cris.kobryn@telelogic.com, mu2i-ftf@omg.org, ocl2-ftf@omg.org, "'Pete Rivett'" , uml2-superstructure-ftf@omg.org Subject: RE: Compliance points resolution proposal - "Feature Support Statement" example X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 19 Aug 2004 13:59:09 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/19/2004 14:03:27, Serialize complete at 08/19/2004 14:03:27 Cris, > > I'm not sure the Compliance Summary needs to list levels *beneath* that > > which compliance is claimed - since compliance at level N automatically > > implies/requires support at Level N-1 (start of section 1.3 of the new > > section states: "Compliance to a given level entails full realization of > > all language units that are defined for that compliance level (note that > > this implies compliance with all levels below it)." > > So, the example is not actually valid: it is not possible to have > > Concrete Syntax compliance at Level 1 but not at Level 0. > > Although I am inclined to agree with your intention here, I disagree that > what you are saying is clearly explained by the current spec draft. The > sentence you cite is insufficient, since the section that defines the "two > distinct types of compliance" (section 1.3, par. 3) does not explain what > the individual or combined (i.e., "both") usage of the distinct types > implies for lower levels. It seemed to me that saying that compliance to a given level implies compliance with all levels below it would take care of that case. But, that is easily rectified. I will add the clarification. Note that since the two types of compliance are independent of each other there are no coupling effects brought that ocme into play when they are combined. > I further note that Concrete Syntax compliance no longer addresses Diagram > Interchange compliance, which Bran's 8/8/04 email proposal included > (although the 8/8/04 draft referred to it as "UML Design Interchange > specification"). What happened here? Was this a publicly discussed consensus > decision on a mailing list, or has the OMG formally dropped the UML 2 DI > specification? If UML 2 DI is still part of the UML 2 FAS quartet, we need > to address DI compliance in some sort of straightforward manner. There was a public discussion on this point and the conclusion was to remove reference to DI compliance. This is because it was pointed out that DI elements have a pointer to model elements and are, therefore, it is not separable as an independent compliance type. Note that the other two compliance types are independent of each other. As for DI compliance, it is appropriate to declare that in the DI spec itself, rather than in the Superstructure (note that the coupling between these two specs is strictly one way: the DI depends on the superstructure but not the other way around). Unfortunately, that FTF is working at a different pace and it will likely require further delays before they are finished. > What to do? I am inclined to your support your point if we: 1) include > Diagram Interchange compliance; 2) explain clearly what the implications of > using "Abstract Syntax", "Concrete Syntax", "Diagram Interchange" and > combinations of them are for lower levels. I am afraid that, with time running out, we no longer have the luxury to ponder these "what if" scenarios. We have to make a decision and the mechanism by which this is done in such circumstances is by voting. Therefore, I will be issuing the special compliance point ballot tomorrow morning with what I think represents the majority opinion of what this text should look like. I will do my best to incorporate all the feedback that was provided. If people feel that they can contribute to this, please forward me your suggestions. Cheers...Bran To: Cc: cris.kobryn@telelogic.com, mu2i-ftf@omg.org, ocl2-ftf@omg.org, "'Pete Rivett'" , uml2-superstructure-ftf@omg.org Subject: RE: Compliance points resolution proposal - "Feature Support Statement" example X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 19 Aug 2004 13:59:09 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/19/2004 14:03:27, Serialize complete at 08/19/2004 14:03:27 Cris, > > I'm not sure the Compliance Summary needs to list levels *beneath* that > > which compliance is claimed - since compliance at level N automatically > > implies/requires support at Level N-1 (start of section 1.3 of the new > > section states: "Compliance to a given level entails full realization of > > all language units that are defined for that compliance level (note that > > this implies compliance with all levels below it)." > > So, the example is not actually valid: it is not possible to have > > Concrete Syntax compliance at Level 1 but not at Level 0. > > Although I am inclined to agree with your intention here, I disagree that > what you are saying is clearly explained by the current spec draft. The > sentence you cite is insufficient, since the section that defines the "two > distinct types of compliance" (section 1.3, par. 3) does not explain what > the individual or combined (i.e., "both") usage of the distinct types > implies for lower levels. It seemed to me that saying that compliance to a given level implies compliance with all levels below it would take care of that case. But, that is easily rectified. I will add the clarification. Note that since the two types of compliance are independent of each other there are no coupling effects brought that ocme into play when they are combined. > I further note that Concrete Syntax compliance no longer addresses Diagram > Interchange compliance, which Bran's 8/8/04 email proposal included > (although the 8/8/04 draft referred to it as "UML Design Interchange > specification"). What happened here? Was this a publicly discussed consensus > decision on a mailing list, or has the OMG formally dropped the UML 2 DI > specification? If UML 2 DI is still part of the UML 2 FAS quartet, we need > to address DI compliance in some sort of straightforward manner. There was a public discussion on this point and the conclusion was to remove reference to DI compliance. This is because it was pointed out that DI elements have a pointer to model elements and are, therefore, it is not separable as an independent compliance type. Note that the other two compliance types are independent of each other. As for DI compliance, it is appropriate to declare that in the DI spec itself, rather than in the Superstructure (note that the coupling between these two specs is strictly one way: the DI depends on the superstructure but not the other way around). Unfortunately, that FTF is working at a different pace and it will likely require further delays before they are finished. > What to do? I am inclined to your support your point if we: 1) include > Diagram Interchange compliance; 2) explain clearly what the implications of > using "Abstract Syntax", "Concrete Syntax", "Diagram Interchange" and > combinations of them are for lower levels. I am afraid that, with time running out, we no longer have the luxury to ponder these "what if" scenarios. We have to make a decision and the mechanism by which this is done in such circumstances is by voting. Therefore, I will be issuing the special compliance point ballot tomorrow morning with what I think represents the majority opinion of what this text should look like. I will do my best to incorporate all the feedback that was provided. If people feel that they can contribute to this, please forward me your suggestions. Cheers...Bran Subject: RE: Compliance points resolution proposal - "Feature Support Statement" example Date: Thu, 19 Aug 2004 13:42:39 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance points resolution proposal - "Feature Support Statement" example Thread-Index: AcSEqCcvfZFXRFtuQ/qxSd1BzF4AAgBEP/ygAAsgYJAAB81RcAAJoS3g From: "Karl Frank" To: , "Pete Rivett" , "Branislav Selic" , , , X-OriginalArrivalTime: 19 Aug 2004 20:42:41.0163 (UTC) FILETIME=[1248D5B0:01C4862D] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7JKuZlj002480 Cris: Please do not propose adding DI compliance to the definition of UML 2 compliance. Diagram Interchange is a separate spec with separate technology issues surrounding its implementation. - Karl -----Original Message----- From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] Sent: Thursday, August 19, 2004 1:03 PM To: 'Pete Rivett'; cris.kobryn@telelogic.com; 'Branislav Selic'; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: RE: Compliance points resolution proposal - "Feature Support Statement" example > I'm not sure the Compliance Summary needs to list levels *beneath* > that which compliance is claimed - since compliance at level N > automatically implies/requires support at Level N-1 (start of section > 1.3 of the new section states: "Compliance to a given level entails > full realization of all language units that are defined for that > compliance level (note that this implies compliance with all levels below it)." > So, the example is not actually valid: it is not possible to have > Concrete Syntax compliance at Level 1 but not at Level 0. Although I am inclined to agree with your intention here, I disagree that what you are saying is clearly explained by the current spec draft. The sentence you cite is insufficient, since the section that defines the "two distinct types of compliance" (section 1.3, par. 3) does not explain what the individual or combined (i.e., "both") usage of the distinct types implies for lower levels. I further note that Concrete Syntax compliance no longer addresses Diagram Interchange compliance, which Bran's 8/8/04 email proposal included (although the 8/8/04 draft referred to it as "UML Design Interchange specification"). What happened here? Was this a publicly discussed consensus decision on a mailing list, or has the OMG formally dropped the UML 2 DI specification? If UML 2 DI is still part of the UML 2 FAS quartet, we need to address DI compliance in some sort of straightforward manner. What to do? I am inclined to your support your point if we: 1) include Diagram Interchange compliance; 2) explain clearly what the implications of using "Abstract Syntax", "Concrete Syntax", "Diagram Interchange" and combinations of them are for lower levels. > > With respect to the feature support table I think we (or a vendor > claiming support)needs to have more definition of the terms than, for > example, 'Action Semantics' or 'Dynamic Semantics': since the spec > does not already define what it means to support dynamic semantics for > a package - which is one of the reasons it is not included in the > formal compliance levels. And 'Action Semantics' is even less clear > (how does it differ from Dynamic Semantics for the Actions package(s)?). I agree, and also think we can whack "Action Semantics". > Not sure it's necessary to have entries where no support is claimed, > but I'm not that bothered. Good. > I think the section should include very specific examples of support > for presentation options and semantic variation points: I think for > these the table approach may become awkward which is why I originally > suggested a semi-structured English approach. Maybe we could have a > table followed by semi-structured text for the latter? There should always be the option to elaborate on anything, and if we want to add semi-structured text to further explain the example, I am fine with that! Thanks, Cris > > -----Original Message----- > > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > > Sent: Thursday, August 19, 2004 1:56 AM > > To: 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > > mu2i-ftf@omg.org; ocl2-ftf@omg.org > > Subject: RE: Compliance points resolution proposal - "Feature > > Support Statement" example > > > > FTFers, > > > > Attached is an example of a "Feature Support Statement" > > (formerly known as > > a"Compliance Support Statement") that Anders and I were asked to > > generate during today's FTF telecon. > > > > Thanks to Bran and Pete for providing review feedback to improve the > > example prior to sending it out to the mailing list. > > > > -- Cris > > > > > > > -----Original Message----- > > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > > Sent: Tuesday, August 17, 2004 3:05 PM > > > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; > > ocl2-ftf@omg.org > > > Subject: Compliance points resolution proposal > > > > > > > > > After yet more cycles of the proposed resolution between > > Anders and Pete > > > and myself, attached, please find a copy of the proposed > > resolution to the > > > compliance point issue (6248). > > > > > > Since this is a gating issue, I would like to have a definitive > > > FTF position on this specific resolution before the OMG meeting > > in Montreal > > > next week. This likely means having a special vote just on > > this resolution > > > outside the usual weekly cycle. > > > > > > Regards, > > > Bran > > > > Reply-To: From: "Cris Kobryn" To: "'Karl Frank'" , , "'Pete Rivett'" , "'Branislav Selic'" , , , Cc: "'Marko Boger'" , Subject: RE: Compliance points resolution proposal - "Feature Support Statement" example Date: Thu, 19 Aug 2004 17:01:39 -0700 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcSEqCcvfZFXRFtuQ/qxSd1BzF4AAgBEP/ygAAsgYJAAB81RcAAJoS3gAAXy/OA= > Please do not propose adding DI compliance to the definition of UML 2 > compliance. We first need to explain why Diagram Interchange (DI) was abruptly dropped from the 8/8/04 compliance draft with no public explanation that I have read or heard. When and how was this decided? Please point me to public email or minutes, since I must have missed this... > Diagram Interchange is a separate spec with separate technology issues > surrounding its implementation. I disagree. Although DI has separate technical issues, it also has strongly related technology issues. In particular, DI's primary reason for existence is to exchange UML 2 diagrams between tools. Isn't this something UML 2 users will expect from a modeling tool standard? So are we as a standards body saying that Diagram Interchange is relevant or irrelevant for UML 2 Superstructure compliance? If it is the former, we need to explain its relevance; if it is the latter, let's explain why it is irrelevant and retire it. One way or the other, let's be clear! Thanks, Cris > -----Original Message----- > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > Sent: Thursday, August 19, 2004 1:03 PM > To: 'Pete Rivett'; cris.kobryn@telelogic.com; 'Branislav Selic'; > uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org > Subject: RE: Compliance points resolution proposal - "Feature Support > Statement" example > > > I'm not sure the Compliance Summary needs to list levels *beneath* > > that which compliance is claimed - since compliance at level N > > automatically implies/requires support at Level N-1 (start of section > > 1.3 of the new section states: "Compliance to a given level entails > > full realization of all language units that are defined for that > > compliance level (note that this implies compliance with all levels > below it)." > > So, the example is not actually valid: it is not possible to have > > Concrete Syntax compliance at Level 1 but not at Level 0. > > Although I am inclined to agree with your intention here, I disagree > that what you are saying is clearly explained by the current spec draft. > The sentence you cite is insufficient, since the section that defines > the "two distinct types of compliance" (section 1.3, par. 3) does not > explain what the individual or combined (i.e., "both") usage of the > distinct types implies for lower levels. > > I further note that Concrete Syntax compliance no longer addresses > Diagram Interchange compliance, which Bran's 8/8/04 email proposal > included (although the 8/8/04 draft referred to it as "UML Design > Interchange specification"). What happened here? Was this a publicly > discussed consensus decision on a mailing list, or has the OMG formally > dropped the UML 2 DI specification? If UML 2 DI is still part of the UML > 2 FAS quartet, we need to address DI compliance in some sort of > straightforward manner. > > What to do? I am inclined to your support your point if we: 1) include > Diagram Interchange compliance; 2) explain clearly what the implications > of using "Abstract Syntax", "Concrete Syntax", "Diagram Interchange" and > combinations of them are for lower levels. > > > > > With respect to the feature support table I think we (or a vendor > > claiming support)needs to have more definition of the terms than, for > > example, 'Action Semantics' or 'Dynamic Semantics': since the spec > > does not already define what it means to support dynamic semantics for > > > a package - which is one of the reasons it is not included in the > > formal compliance levels. And 'Action Semantics' is even less clear > > (how does it differ from Dynamic Semantics for the Actions > package(s)?). > > I agree, and also think we can whack "Action Semantics". > > > Not sure it's necessary to have entries where no support is claimed, > > but I'm not that bothered. > > Good. > > > I think the section should include very specific examples of support > > for presentation options and semantic variation points: I think for > > these the table approach may become awkward which is why I originally > > suggested a semi-structured English approach. Maybe we could have a > > table followed by semi-structured text for the latter? > > There should always be the option to elaborate on anything, and if we > want to add semi-structured text to further explain the example, I am > fine with that! > > Thanks, > > Cris > > > > > > > -----Original Message----- > > > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > > > Sent: Thursday, August 19, 2004 1:56 AM > > > To: 'Branislav Selic'; uml2-superstructure-ftf@omg.org; > > > mu2i-ftf@omg.org; ocl2-ftf@omg.org > > > Subject: RE: Compliance points resolution proposal - "Feature > > > Support Statement" example > > > > > > FTFers, > > > > > > Attached is an example of a "Feature Support Statement" > > > (formerly known as > > > a"Compliance Support Statement") that Anders and I were asked to > > > generate during today's FTF telecon. > > > > > > Thanks to Bran and Pete for providing review feedback to improve the > > > > example prior to sending it out to the mailing list. > > > > > > -- Cris > > > > > > > > > > -----Original Message----- > > > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > > > Sent: Tuesday, August 17, 2004 3:05 PM > > > > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; > > > ocl2-ftf@omg.org > > > > Subject: Compliance points resolution proposal > > > > > > > > > > > > After yet more cycles of the proposed resolution between > > > Anders and Pete > > > > and myself, attached, please find a copy of the proposed > > > resolution to the > > > > compliance point issue (6248). > > > > > > > > Since this is a gating issue, I would like to have a definitive > > > > FTF position on this specific resolution before the OMG meeting > > > in Montreal > > > > next week. This likely means having a special vote just on > > > this resolution > > > > outside the usual weekly cycle. > > > > > > > > Regards, > > > > Bran > > > > > > > > > > > To: uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org Subject: Compliance section reissue X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 12 Aug 2004 12:06:45 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/12/2004 12:06:51 Based on Cris' feedback, I have clarified and strengthened the portions of the text that describe the meaning of compliance and compliance levels. The very first paragraph has been modified and section 1.3 that talks about the meaning and forms of compliance has been rewritten. Hopefully this is no longer ambiguous. Thanks, Bran Compliance.section.addin2.pdf Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Date: Fri, 13 Aug 2004 09:03:07 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance section reissue - let's avoid naoming confusion re Basic Thread-Index: AcSAh8u6cPkKNbkxS8Gu1WRkemqWUgAIT88g From: "Pete Rivett" To: "Branislav Selic" Cc: X-Virus-Scanned: by amavisd-new at sentraliant.com Sorry these are late in the day for this draft - but in my defense I have made the 1st 2 substantive points several times before. Substantive comments: 1. I think it's daft to have a Level called 'Basic' which is nothing to do with the package called Basic! Especially when we do have a level virtually identical to the package Basic which is called something else - Core. 2. it seems odd to have Core (equivalent to EMOF) as a compliance level for Superstructure since it represents nothing at all in Superstructure - the most 'primitive' level in Superstructure is Kernel: it seems we should have that as the lowest compliance level. MOF and Infra will have their own compliance levels for which the levels proposed as Core would more naturally fit. (For completeness Core must be included in section 1.4 - though that would show up how little relationship it has to Superstructure!). 3. Section 1.3: last para: the reference to UML Design Interchange should be to UML 2 Diagram Interchange. There is a technical problem I think with the definition of concrete syntax compliance with reference to the DI standard - since the DI metamodel has a mandatory reference from a graphic element to a model element (via an intermediate Bridge class). hence it is not possible to exchange notation only using DI without also having a model to refer to. So as far as I see, as stated stated the concrete syntax compliance definition does not meet the declared aim. 4. Following on from our lengthy discussion about reuse of the same namespace we still do need to have a name for formally referring to "the uml that merges in packages to form the Intermediate level of compliance": this will, for example, form the basis for naming the XML Schema for validating model interchanges for compliance at that level. 5. Why use 'uml' and not the more expected 'UML' - by convention all package names have an initial capital letter at least Editorial/minor comments: In 1.2 it would be better to have a better summary explanation of the capabilities provided by level L2 than 'adds some additional capabilities'. NB there is a typo 'Intermeideiate' First sentence of document states that "This means that a tool at a given level of compliance is able to interchange models with a tool at the same or higher level of compliance" - however the chapter later states that tools could be compliant at concrete syntax level only without the model interchange capability. Section 1.1 has "The modeling concepts of UML are grouped into capability sets, or, simply, capabilities.". I really don't think we need need 2 quite different terms referring to the same thing - especially given that different parts of the chapter use different ones (e.g. 1.3 uses capability whereas 1.4 uses capability set). I flailed around for a while to try to discover how the 2 concepts were related until I found the sentence in 1.1 saying they were the same thing! Given that compliance points are defined purely in terms of specific packages, I think we need a bit more justification for the concept of capabilities at all in terms of the compliance discussion: is it merely so that instead of claiming compliance to anything, vendors can claim they 'support' some capabilities? First para of 1.3 has "underlying concepts in lower levels that are required by that capability.": I think the concept of a concept 'requiring' other concepts should be made less fuzzy since that's not something defined in the specification. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 12, 2004 5:07 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Compliance section reissue Based on Cris' feedback, I have clarified and strengthened the portions of the text that describe the meaning of compliance and compliance levels. The very first paragraph has been modified and section 1.3 that talks about the meaning and forms of compliance has been rewritten. Hopefully this is no longer ambiguous. Thanks, Bran To: "Pete Rivett" Cc: "Branislav Selic" , uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Fri, 13 Aug 2004 09:25:47 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/13/2004 07:25:50, Serialize complete at 08/13/2004 07:25:50 Pete, Great points. Comments below. "Pete Rivett" wrote on 08/13/2004 09:03:07 AM: > Sorry these are late in the day for this draft - but in my defense I have made the > 1st 2 substantive points several times before. > > Substantive comments: > > 1. I think it's daft to have a Level called 'Basic' which is nothing to do with > the package called Basic! > Especially when we do have a level virtually identical to the package Basic which > is called something else - Core. > How about essential? > > 2. it seems odd to have Core (equivalent to EMOF) as a compliance level for > Superstructure since it represents nothing at all in Superstructure - the most > 'primitive' level in Superstructure is Kernel: it seems we should have that as the > lowest compliance level. MOF and Infra will have their own compliance levels for > which the levels proposed as Core would more naturally fit. (For completeness Core > must be included in section 1.4 - though that would show up how little relationship > it has to Superstructure!). > The point of Core does not necessarily have to have anything to do with EMOF. Rather it is a very minimal set of modeling capabilities that have been proven to be effective in building structural models. The intent is to encourage tool vendors to at least be able to reliably interchange at this level if nothing else. It is also intended to keep the barriers to entry low. Kernerl (and maybe even Constructs) may have too many features to play this role effectively. > 3. Section 1.3: last para: the reference to UML Design Interchange should be to UML > 2 Diagram Interchange. > There is a technical problem I think with the definition of concrete syntax > compliance with reference to the DI standard - since the DI metamodel has a > mandatory reference from a graphic element to a model element (via an intermediate > Bridge class). hence it is not possible to exchange notation only using DI without > also having a model to refer to. So as far as I see, as stated stated the concrete > syntax compliance definition does not meet the declared aim. > Ok. So could we somehow talk about notation compliance without mentioning diagram interchange? > 4. Following on from our lengthy discussion about reuse of the same namespace we > still do need to have a name for formally referring to "the uml that merges in > packages to form the Intermediate level of compliance": this will, for example, > form the basis for naming the XML Schema for validating model interchanges for > compliance at that level. > That name is the compliance level name. In the Rose model, its captured as the model that contains the empty org.omg.uml package, and the diagram that specifies the capabilities (packages) merged into it. This will result in a file that can be named based on the compliance level. > 5. Why use 'uml' and not the more expected 'UML' - by convention all package names > have an initial capital letter at least > This is not a convention that is used anywhere else so I avoided it, mostly out of habit, but also to reduce confusion with class names. > Editorial/minor comments: > > In 1.2 it would be better to have a better summary explanation of the capabilities > provided by level L2 than 'adds some additional capabilities'. NB there is a typo > 'Intermeideiate' > > First sentence of document states that "This means that a tool at a given level of > compliance is able to interchange models with a tool at the same or higher level of > compliance" - however the chapter later states that tools could be compliant at > concrete syntax level only without the model interchange capability. > This needs to be clarified. A tool for a higher level of compliance can always import XMI files from a tool at a lower level of compliance. The spec is silent about what happens in the other direction, but a reasonable convention (based on XML conventions) would be to at least ignore unsupported model elements, and at best, not discard them in import and save. Of course this could result in imports that loose significant model semantics, but its the best we can do. > Section 1.1 has "The modeling concepts of UML are grouped into capability sets, or, > simply, capabilities.". I really don't think we need need 2 quite different terms > referring to the same thing - especially given that different parts of the chapter > use different ones (e.g. 1.3 uses capability whereas 1.4 uses capability set). I > flailed around for a while to try to discover how the 2 concepts were related until > I found the sentence in 1.1 saying they were the same thing! > Given that compliance points are defined purely in terms of specific packages, I > think we need a bit more justification for the concept of capabilities at all in > terms of the compliance discussion: is it merely so that instead of claiming > compliance to anything, vendors can claim they 'support' some capabilities? > Capabilities are intended to focus on collection of model elements that are of interest to modelers. A capability is just a concept for naming a set of package that taken together provide some modeling functions. Capability set was intended to describe the capabilities included in a particular compliance level. So capability is a set of packages, compliance level is a set of capabilities. > First para of 1.3 has "underlying concepts in lower levels that are required by > that capability.": I think the concept of a concept 'requiring' other concepts > should be made less fuzzy since that's not something defined in the specification. > The requiring concept is modeled using either import or merge depending on how the required concept is used. > Pete Rivett (mailto:pete.rivett@adaptive.com) > Chief Scientist, 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: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Thursday, August 12, 2004 5:07 PM > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: Compliance section reissue > > Based on Cris' feedback, I have clarified and strengthened the portions of the text > that describe the meaning of compliance and compliance levels. > > The very first paragraph has been modified and section 1.3 that talks about the > meaning and forms of compliance has been rewritten. > > Hopefully this is no longer ambiguous. > > Thanks, > Bran Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Date: Fri, 13 Aug 2004 06:50:43 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance section reissue - let's avoid naoming confusion re Basic Thread-Index: AcSAh8u6cPkKNbkxS8Gu1WRkemqWUgAIT88gACSoprA= From: "Karl Frank" To: "Pete Rivett" , "Branislav Selic" Cc: X-OriginalArrivalTime: 13 Aug 2004 13:50:45.0745 (UTC) FILETIME=[8844D610:01C4813C] to voice support for making the changes Pete suggest. Hear! Hear! A specific way to satisfy his request wrt both 1 and 2: In place of the proposal that "level 0" be defined by reference to the Infrastructure Basic, I propose level 0 of UML superstructure compliance should be defined by reference to the Superstructure Kernel package, which is a proper UML 2 modeling capability but a subset of the current proposed level 1. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, August 13, 2004 9:03 AM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Sorry these are late in the day for this draft - but in my defense I have made the 1st 2 substantive points several times before. Substantive comments: 1. I think it's daft to have a Level called 'Basic' which is nothing to do with the package called Basic! Especially when we do have a level virtually identical to the package Basic which is called something else - Core. 2. it seems odd to have Core (equivalent to EMOF) as a compliance level for Superstructure since it represents nothing at all in Superstructure - the most 'primitive' level in Superstructure is Kernel: it seems we should have that as the lowest compliance level. MOF and Infra will have their own compliance levels for which the levels proposed as Core would more naturally fit. (For completeness Core must be included in section 1.4 - though that would show up how little relationship it has to Superstructure!). 3. Section 1.3: last para: the reference to UML Design Interchange should be to UML 2 Diagram Interchange. There is a technical problem I think with the definition of concrete syntax compliance with reference to the DI standard - since the DI metamodel has a mandatory reference from a graphic element to a model element (via an intermediate Bridge class). hence it is not possible to exchange notation only using DI without also having a model to refer to. So as far as I see, as stated stated the concrete syntax compliance definition does not meet the declared aim. 4. Following on from our lengthy discussion about reuse of the same namespace we still do need to have a name for formally referring to "the uml that merges in packages to form the Intermediate level of compliance": this will, for example, form the basis for naming the XML Schema for validating model interchanges for compliance at that level. 5. Why use 'uml' and not the more expected 'UML' - by convention all package names have an initial capital letter at least Editorial/minor comments: In 1.2 it would be better to have a better summary explanation of the capabilities provided by level L2 than 'adds some additional capabilities'. NB there is a typo 'Intermeideiate' First sentence of document states that "This means that a tool at a given level of compliance is able to interchange models with a tool at the same or higher level of compliance" - however the chapter later states that tools could be compliant at concrete syntax level only without the model interchange capability. Section 1.1 has "The modeling concepts of UML are grouped into capability sets, or, simply, capabilities.". I really don't think we need need 2 quite different terms referring to the same thing - especially given that different parts of the chapter use different ones (e.g. 1.3 uses capability whereas 1.4 uses capability set). I flailed around for a while to try to discover how the 2 concepts were related until I found the sentence in 1.1 saying they were the same thing! Given that compliance points are defined purely in terms of specific packages, I think we need a bit more justification for the concept of capabilities at all in terms of the compliance discussion: is it merely so that instead of claiming compliance to anything, vendors can claim they 'support' some capabilities? First para of 1.3 has "underlying concepts in lower levels that are required by that capability.": I think the concept of a concept 'requiring' other concepts should be made less fuzzy since that's not something defined in the specification. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 12, 2004 5:07 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Compliance section reissue Based on Cris' feedback, I have clarified and strengthened the portions of the text that describe the meaning of compliance and compliance levels. The very first paragraph has been modified and section 1.3 that talks about the meaning and forms of compliance has been rewritten. Hopefully this is no longer ambiguous. Thanks, Bran To: "Pete Rivett" Cc: uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 13 Aug 2004 10:05:04 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/13/2004 10:05:06, Serialize complete at 08/13/2004 10:05:06 Pete, Thanks for the input. Some feedback: > 1. I think it's daft to have a Level called 'Basic' which is > nothing to do with the package called Basic! > Especially when we do have a level virtually identical to the > package Basic which is called something else - Core. The names Basic, Intermediate, and Complete were intended for users who generally don't give a hoot about how the metamodel packages are named. However, it can be confusing. So, rather than try and come up with descriptive names, I suggest that we just use semantic free names: "Level 0" through "Level 3". > 2. it seems odd to have Core (equivalent to EMOF) as a compliance > level for Superstructure since it represents nothing at all in > Superstructure - the most 'primitive' level in Superstructure is > Kernel: it seems we should have that as the lowest compliance level. > MOF and Infra will have their own compliance levels for which the > levels proposed as Core would more naturally fit. (For completeness > Core must be included in section 1.4 - though that would show up how > little relationship it has to Superstructure!). The idea of Core is really the ability to support structural modeling Java programmers, which Craig Larman tells me, are the dominant users of UML (Craig is the author of one of the two best selling books on UML.) Kernel has way too much stuff for the Java people who only want class modeling. The next class of Java people go beyond Kernel and want things like Interactions and so on. How serious an impediment is the presence of L0, Pete? > 3. Section 1.3: last para: the reference to UML Design Interchange > should be to UML 2 Diagram Interchange. Thanks. > There is a technical problem I think with the definition of concrete > syntax compliance with reference to the DI standard - since the DI > metamodel has a mandatory reference from a graphic element to a > model element (via an intermediate Bridge class). hence it is not > possible to exchange notation only using DI without also having a > model to refer to. So as far as I see, as stated stated the concrete > syntax compliance definition does not meet the declared aim. Anders has pointed out that the definition of compliance does not say anything about Notation, but only about interchange. This too will have to be factored into the definition. > 4. Following on from our lengthy discussion about reuse of the same > namespace we still do need to have a name for formally referring to > "the uml that merges in packages to form the Intermediate level of > compliance": this will, for example, form the basis for naming the > XML Schema for validating model interchanges for compliance at that level. Do you have suggestions? > 5. Why use 'uml' and not the more expected 'UML' - by convention all > package names have an initial capital letter at least OK. > Editorial/minor comments: > > In 1.2 it would be better to have a better summary explanation of > the capabilities provided by level L2 than 'adds some additional > capabilities'. NB there is a typo 'Intermeideiate' It would be, but there is no consistent criterion across the different capabilities that can be cited. OTOH, including a list is pointless since the tables already do that. (Also, I decided against giving a textual description for each package since their contents are described in the appropriate chapters -- I want to avoid creating a maintenance problem when the contents of those packages change over time.) > First sentence of document states that "This means that a tool at a > given level of compliance is able to interchange models with a tool > at the same or higher level of compliance" - however the chapter > later states that tools could be compliant at concrete syntax level > only without the model interchange capability. Fair enough. > Section 1.1 has "The modeling concepts of UML are grouped into > capability sets, or, simply, capabilities.". I really don't think we > need need 2 quite different terms referring to the same thing - > especially given that different parts of the chapter use different > ones (e.g. 1.3 uses capability whereas 1.4 uses capability set). I > flailed around for a while to try to discover how the 2 concepts > were related until I found the sentence in 1.1 saying they were the > same thing! Agreed. In fact, I am wondering if I should change the term "capability" to "language unit" which is what the 2U folks called it. It is far less loaded. > Given that compliance points are defined purely in terms of specific > packages, I think we need a bit more justification for the concept > of capabilities at all in terms of the compliance discussion: is it > merely so that instead of claiming compliance to anything, vendors > can claim they 'support' some capabilities? I agree. I will add more justification here (something that Anders is concerned with as well). It is more than just so that vendors can claim support -- although this IS important because customers need to know -- capabiliteis are also a convenient and natural grouping that is already present in the metamodel. > First para of 1.3 has "underlying concepts in lower levels that are > required by that capability.": I think the concept of a concept > 'requiring' other concepts should be made less fuzzy since that's > not something defined in the specification. OK. Based on this feedback and separate feedback I got from Anders, it is clear that this resolution proposal has to be modified and that, therefore, it cannot go on this ballot. However, in order to meet the deadline, I am hoping to provide a supplementary ballot next week so that we can close on the resolution before the Montreal meeting. If necessary, I can organize a call-in voting session. Regards, Bran To: "Karl Frank" Cc: "Pete Rivett" , uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 13 Aug 2004 10:18:24 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/13/2004 10:18:27, Serialize complete at 08/13/2004 10:18:27 Kernel by itself is not very useful (e.g., it does not even have dependencies or interfaces). I doubt if it would have many adherents. Strangely enough, as I explained in my response to Pete, the proposed Basic by itself is much more meaningful. So, in my view, we either get rid of L0 altogether or leave it the way it is. Bran "Karl Frank" 08/13/2004 09:50 AM To "Pete Rivett" , Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic to voice support for making the changes Pete suggest. Hear! Hear! A specific way to satisfy his request wrt both 1 and 2: In place of the proposal that "level 0" be defined by reference to the Infrastructure Basic, I propose level 0 of UML superstructure compliance should be defined by reference to the Superstructure Kernel package, which is a proper UML 2 modeling capability but a subset of the current proposed level 1. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, August 13, 2004 9:03 AM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Sorry these are late in the day for this draft - but in my defense I have made the 1st 2 substantive points several times before. Substantive comments: 1. I think it's daft to have a Level called 'Basic' which is nothing to do with the package called Basic! Especially when we do have a level virtually identical to the package Basic which is called something else - Core. 2. it seems odd to have Core (equivalent to EMOF) as a compliance level for Superstructure since it represents nothing at all in Superstructure - the most 'primitive' level in Superstructure is Kernel: it seems we should have that as the lowest compliance level. MOF and Infra will have their own compliance levels for which the levels proposed as Core would more naturally fit. (For completeness Core must be included in section 1.4 - though that would show up how little relationship it has to Superstructure!). 3. Section 1.3: last para: the reference to UML Design Interchange should be to UML 2 Diagram Interchange. There is a technical problem I think with the definition of concrete syntax compliance with reference to the DI standard - since the DI metamodel has a mandatory reference from a graphic element to a model element (via an intermediate Bridge class). hence it is not possible to exchange notation only using DI without also having a model to refer to. So as far as I see, as stated stated the concrete syntax compliance definition does not meet the declared aim. 4. Following on from our lengthy discussion about reuse of the same namespace we still do need to have a name for formally referring to "the uml that merges in packages to form the Intermediate level of compliance": this will, for example, form the basis for naming the XML Schema for validating model interchanges for compliance at that level. 5. Why use 'uml' and not the more expected 'UML' - by convention all package names have an initial capital letter at least Editorial/minor comments: In 1.2 it would be better to have a better summary explanation of the capabilities provided by level L2 than 'adds some additional capabilities'. NB there is a typo 'Intermeideiate' First sentence of document states that "This means that a tool at a given level of compliance is able to interchange models with a tool at the same or higher level of compliance" - however the chapter later states that tools could be compliant at concrete syntax level only without the model interchange capability. Section 1.1 has "The modeling concepts of UML are grouped into capability sets, or, simply, capabilities.". I really don't think we need need 2 quite different terms referring to the same thing - especially given that different parts of the chapter use different ones (e.g. 1.3 uses capability whereas 1.4 uses capability set). I flailed around for a while to try to discover how the 2 concepts were related until I found the sentence in 1.1 saying they were the same thing! Given that compliance points are defined purely in terms of specific packages, I think we need a bit more justification for the concept of capabilities at all in terms of the compliance discussion: is it merely so that instead of claiming compliance to anything, vendors can claim they 'support' some capabilities? First para of 1.3 has "underlying concepts in lower levels that are required by that capability.": I think the concept of a concept 'requiring' other concepts should be made less fuzzy since that's not something defined in the specification. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 12, 2004 5:07 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Compliance section reissue Based on Cris' feedback, I have clarified and strengthened the portions of the text that describe the meaning of compliance and compliance levels. The very first paragraph has been modified and section 1.3 that talks about the meaning and forms of compliance has been rewritten. Hopefully this is no longer ambiguous. Thanks, Bran Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Date: Fri, 13 Aug 2004 10:57:10 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance section reissue - let's avoid naoming confusion re Basic Thread-Index: AcSBQBP0Eak4rI5gRqCAjNgla/I8awAAQvJA From: "Pete Rivett" To: "Branislav Selic" Cc: X-Virus-Scanned: by amavisd-new at sentraliant.com See below. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, August 13, 2004 3:05 PM To: Pete Rivett Cc: uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Pete, Thanks for the input. Some feedback: > 1. I think it's daft to have a Level called 'Basic' which is > nothing to do with the package called Basic! > Especially when we do have a level virtually identical to the > package Basic which is called something else - Core. The names Basic, Intermediate, and Complete were intended for users who generally don't give a hoot about how the metamodel packages are named. However, it can be confusing. So, rather than try and come up with descriptive names, I suggest that we just use semantic free names: "Level 0" through "Level 3". [Pete Rivett] OK by me > 2. it seems odd to have Core (equivalent to EMOF) as a compliance > level for Superstructure since it represents nothing at all in > Superstructure - the most 'primitive' level in Superstructure is > Kernel: it seems we should have that as the lowest compliance level. > MOF and Infra will have their own compliance levels for which the > levels proposed as Core would more naturally fit. (For completeness > Core must be included in section 1.4 - though that would show up how > little relationship it has to Superstructure!). The idea of Core is really the ability to support structural modeling Java programmers, which Craig Larman tells me, are the dominant users of UML (Craig is the author of one of the two best selling books on UML.) Kernel has way too much stuff for the Java people who only want class modeling. The next class of Java people go beyond Kernel and want things like Interactions and so on. [Pete Rivett] I thought we had given up on the idea (promoted particularly by Thomas as far as I recall) of trying to identify communities of users and aligning compliance levels to them. And why only Java and not other (even more popular) programming languages - surely we want to increase the uptake of UML! Moreover it seems to me that Basic does not even meet this aim - e.g. it allows multiple inheritance on Classes (which Java does not) and has no metaclass for Interface, one of the most important Java constructs (nor even a means of stereotyping Class with ). How serious an impediment is the presence of L0, Pete? [Pete Rivett] The above notwithstanding I'm not over-concerned about having something defined at this level of capability (my comment only said that "it's odd") - if a case can be made that there is a significant community of users and vendors who would find this valuable. However I do think it's important to define Core/Level 0 formally in terms of Superstructure - after all this is a Superstructure compliance level [BTW this is also likely to be a more general AB concern]. For example Figure 1 includes Basic which is not even in Superstructure, and section 1.4 ignores L0. In terms of real usefulness maybe Constructs would be a better Level 0 - Basic is missing some pretty important elements such as Comment and Constraint (surely Java programmers would/should wish to annotate their models and specify pre/post-conditions on Operations). And Imports. You say the 'nest class' of UML user will want Interactions etc: however I argue that the 'next class' beyond basic will be those creating metamodels - which as well as the UML FTF itself will include other OMG submission/revision teams and people using MOF products. [Pete Rivett] BTW having Basic as a Superstructure compliance level makes it even more important to remove structural metamodel inconsistencies between Basic and Kernel - such as that of Parameter Direction that we discussed yesterday on the Infra call > 3. Section 1.3: last para: the reference to UML Design Interchange > should be to UML 2 Diagram Interchange. Thanks. > There is a technical problem I think with the definition of concrete > syntax compliance with reference to the DI standard - since the DI > metamodel has a mandatory reference from a graphic element to a > model element (via an intermediate Bridge class). hence it is not > possible to exchange notation only using DI without also having a > model to refer to. So as far as I see, as stated stated the concrete > syntax compliance definition does not meet the declared aim. Anders has pointed out that the definition of compliance does not say anything about Notation, but only about interchange. This too will have to be factored into the definition. [Pete Rivett] Agreed. But my point is that it's not possible to interchange diagrams without models - so we either drop that aim or remove the need to support DI here and just have notation relevant. Another question is whether, for concrete syntax compliance, the tool must enforce the notation rules (explicit or implied from the metamodel - e.g. that one cannot nest a Package in a Class). > 4. Following on from our lengthy discussion about reuse of the same > namespace we still do need to have a name for formally referring to > "the uml that merges in packages to form the Intermediate level of > compliance": this will, for example, form the basis for naming the > XML Schema for validating model interchanges for compliance at that level. Do you have suggestions? [Pete Rivett] I'm happy in principle with Jim's reply (though have not seen the actual package names): we just need to include those package names from the Rose model in the specification itself. > 5. Why use 'uml' and not the more expected 'UML' - by convention all > package names have an initial capital letter at least OK. > Editorial/minor comments: > > In 1.2 it would be better to have a better summary explanation of > the capabilities provided by level L2 than 'adds some additional > capabilities'. NB there is a typo 'Intermeideiate' It would be, but there is no consistent criterion across the different capabilities that can be cited. OTOH, including a list is pointless since the tables already do that. (Also, I decided against giving a textual description for each package since their contents are described in the appropriate chapters -- I want to avoid creating a maintenance problem when the contents of those packages change over time.) [Pete Rivett] Reasonable > First sentence of document states that "This means that a tool at a > given level of compliance is able to interchange models with a tool > at the same or higher level of compliance" - however the chapter > later states that tools could be compliant at concrete syntax level > only without the model interchange capability. Fair enough. > Section 1.1 has "The modeling concepts of UML are grouped into > capability sets, or, simply, capabilities.". I really don't think we > need need 2 quite different terms referring to the same thing - > especially given that different parts of the chapter use different > ones (e.g. 1.3 uses capability whereas 1.4 uses capability set). I > flailed around for a while to try to discover how the 2 concepts > were related until I found the sentence in 1.1 saying they were the > same thing! Agreed. In fact, I am wondering if I should change the term "capability" to "language unit" which is what the 2U folks called it. It is far less loaded. [Pete Rivett] Makes sense to me > Given that compliance points are defined purely in terms of specific > packages, I think we need a bit more justification for the concept > of capabilities at all in terms of the compliance discussion: is it > merely so that instead of claiming compliance to anything, vendors > can claim they 'support' some capabilities? I agree. I will add more justification here (something that Anders is concerned with as well). It is more than just so that vendors can claim support -- although this IS important because customers need to know -- capabiliteis are also a convenient and natural grouping that is already present in the metamodel. > First para of 1.3 has "underlying concepts in lower levels that are > required by that capability.": I think the concept of a concept > 'requiring' other concepts should be made less fuzzy since that's > not something defined in the specification. OK. Based on this feedback and separate feedback I got from Anders, it is clear that this resolution proposal has to be modified and that, therefore, it cannot go on this ballot. However, in order to meet the deadline, I am hoping to provide a supplementary ballot next week so that we can close on the resolution before the Montreal meeting. If necessary, I can organize a call-in voting session. [Pete Rivett] OK Regards, Bran To: "Pete Rivett" Cc: uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 13 Aug 2004 11:16:46 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/13/2004 11:16:48, Serialize complete at 08/13/2004 11:16:48 A short comment on one particular point: > Another question is whether, for concrete syntax compliance, the tool must enforce the notation rules (explicit or implied from the metamodel - e.g. that one cannot nest a Package in a Class). Demanding compliance to implicit rules makes no sense. The only thing we can ask for is support for what is explicit in the notation -- at least until we have a fully formalized concrete syntax specification for UML 2. (BTW, it is actually possible to graphically nest a Package in a Component, which is a kind of a Class.) Bran Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Date: Fri, 13 Aug 2004 12:02:37 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance section reissue - let's avoid naoming confusion re Basic Thread-Index: AcSBSt5jAG81M68lQdeuqtbl0oxACgAAI6dw From: "Pete Rivett" To: "Branislav Selic" Cc: X-Virus-Scanned: by amavisd-new at sentraliant.com Hah, caught me out with my bad example! I share your concern in general about implicit rules one can only guess at, but in this case I deliberately used 'implied' which is different from 'implicit': I think it's possible to logically imply rules about notation from: Explicit rules about the metamodel The notation section that describes how the notation is represented by a metamodel instance. The simple rule for the implication is that if, by applying notation descriptions that are explicit in the specification, a specific diagram would map to a metamodel instance that is invalid according to constraints in the metamodel, then the diagram is invalid. And we could require that for a tool to be concrete syntax compliant then it should permit no such invalid diagrams to be saved. I'm not a strong advocate for such an additional requirement but believe it is 'well formed', is not the same as 'implicit', and that the question is worthy of discussion. If we don't have any such requirement then would PowerPoint not be compliant? The example given of a typical tool for concrete syntax compliance is Visio. Visio, with a UML-specific stencil, does have the ability to enforce at least the majority of notational constraints as defined above. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, August 13, 2004 4:17 PM To: Pete Rivett Cc: uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic A short comment on one particular point: > Another question is whether, for concrete syntax compliance, the tool must enforce the notation rules (explicit or implied from the metamodel - e.g. that one cannot nest a Package in a Class). Demanding compliance to implicit rules makes no sense. The only thing we can ask for is support for what is explicit in the notation -- at least until we have a fully formalized concrete syntax specification for UML 2. (BTW, it is actually possible to graphically nest a Package in a Component, which is a kind of a Class.) Bran Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Date: Fri, 13 Aug 2004 19:40:18 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance section reissue - let's avoid naoming confusion re Basic Thread-Index: AcSBQGvJfEdTFYz4T1CuQY/hWU1bxAAZPMIA From: "Karl Frank" To: "Branislav Selic" Cc: "Pete Rivett" , X-OriginalArrivalTime: 14 Aug 2004 02:40:20.0511 (UTC) FILETIME=[0A92FAF0:01C481A8] Agreed that Kernel and Dependencies are a much better choice than Kernel alone for Level 0. To be blunt, such a very simple version of UML 2 would, contrary to what you argue, be useful cause it would be a competitor to the even more simple metamodel that Microsoft will be advocating, but is (unlike the proposed resolution) a UML 2 Superstructure compliance point. Constructs merges Basic, and your argument is that Infrastructure Basic by itself is more useful than Superstructure Kernel which merges Constructs?. Sounds like the mantra "More is Less" turned around, so "Less is More". Or has the Infra FTF turned these packages around completely? What am I missing here? I also don't get it that Java devleopers are the main users. My perception is that the more mature DoD and such are much heavier users of UML that the Java world, and they do a lot of C++ etc. Finally, the objective of having EMF modelling be possible in compliance with UML 2 is still possible with a compliance point defined by reference to the UML 2 spec, at the expense of having it include just a little more than EMF supports. Just don't ues the part that is not needed? - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, August 13, 2004 10:18 AM To: Karl Frank Cc: Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Kernel by itself is not very useful (e.g., it does not even have dependencies or interfaces). I doubt if it would have many adherents. Strangely enough, as I explained in my response to Pete, the proposed Basic by itself is much more meaningful. So, in my view, we either get rid of L0 altogether or leave it the way it is. Bran "Karl Frank" 08/13/2004 09:50 AM To "Pete Rivett" , Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic to voice support for making the changes Pete suggest. Hear! Hear! A specific way to satisfy his request wrt both 1 and 2: In place of the proposal that "level 0" be defined by reference to the Infrastructure Basic, I propose level 0 of UML superstructure compliance should be defined by reference to the Superstructure Kernel package, which is a proper UML 2 modeling capability but a subset of the current proposed level 1. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, August 13, 2004 9:03 AM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Sorry these are late in the day for this draft - but in my defense I have made the 1st 2 substantive points several times before. Substantive comments: 1. I think it's daft to have a Level called 'Basic' which is nothing to do with the package called Basic! Especially when we do have a level virtually identical to the package Basic which is called something else - Core. 2. it seems odd to have Core (equivalent to EMOF) as a compliance level for Superstructure since it represents nothing at all in Superstructure - the most 'primitive' level in Superstructure is Kernel: it seems we should have that as the lowest compliance level. MOF and Infra will have their own compliance levels for which the levels proposed as Core would more naturally fit. (For completeness Core must be included in section 1.4 - though that would show up how little relationship it has to Superstructure!). 3. Section 1.3: last para: the reference to UML Design Interchange should be to UML 2 Diagram Interchange. There is a technical problem I think with the definition of concrete syntax compliance with reference to the DI standard - since the DI metamodel has a mandatory reference from a graphic element to a model element (via an intermediate Bridge class). hence it is not possible to exchange notation only using DI without also having a model to refer to. So as far as I see, as stated stated the concrete syntax compliance definition does not meet the declared aim. 4. Following on from our lengthy discussion about reuse of the same namespace we still do need to have a name for formally referring to "the uml that merges in packages to form the Intermediate level of compliance": this will, for example, form the basis for naming the XML Schema for validating model interchanges for compliance at that level. 5. Why use 'uml' and not the more expected 'UML' - by convention all package names have an initial capital letter at least Editorial/minor comments: In 1.2 it would be better to have a better summary explanation of the capabilities provided by level L2 than 'adds some additional capabilities'. NB there is a typo 'Intermeideiate' First sentence of document states that "This means that a tool at a given level of compliance is able to interchange models with a tool at the same or higher level of compliance" - however the chapter later states that tools could be compliant at concrete syntax level only without the model interchange capability. Section 1.1 has "The modeling concepts of UML are grouped into capability sets, or, simply, capabilities.". I really don't think we need need 2 quite different terms referring to the same thing - especially given that different parts of the chapter use different ones (e.g. 1.3 uses capability whereas 1.4 uses capability set). I flailed around for a while to try to discover how the 2 concepts were related until I found the sentence in 1.1 saying they were the same thing! Given that compliance points are defined purely in terms of specific packages, I think we need a bit more justification for the concept of capabilities at all in terms of the compliance discussion: is it merely so that instead of claiming compliance to anything, vendors can claim they 'support' some capabilities? First para of 1.3 has "underlying concepts in lower levels that are required by that capability.": I think the concept of a concept 'requiring' other concepts should be made less fuzzy since that's not something defined in the specification. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 12, 2004 5:07 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Compliance section reissue Based on Cris' feedback, I have clarified and strengthened the portions of the text that describe the meaning of compliance and compliance levels. The very first paragraph has been modified and section 1.3 that talks about the meaning and forms of compliance has been rewritten. Hopefully this is no longer ambiguous. Thanks, Bran To: "Karl Frank" Cc: "Branislav Selic" , "Pete Rivett" , uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Sat, 14 Aug 2004 07:13:08 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/14/2004 05:13:11, Serialize complete at 08/14/2004 05:13:11 Karl, Basic is just as much part of UML2 super as it is MOF, so there's no reason Basic alone couldn't be a super compliance point. The primary reason for L0 is to ensure tool vendors can easily claim compliance to something. In the past, the barrier to entry for UML was high. UML2 will make it even higher, even just implementing Kernel completely. As a result, there was little interchange between tools. (Of course there are other reasons for this too - including the informality and interpretation of the spec). What we're hoping for is that by providing UML2 compliance level L0 that only includes Basic, we will be able to AT LEAST get interchange of simple structural models built using modeling concepts that are well understood, easily implemented, and with proven value through common practice. This seems like a good place to start to grow interoperability and interchange from where we are today. L1 adds to that by including behavior resulting a metamodel that is sufficiently computationally complete to be executable and translatable to other platform models. "Karl Frank" 08/13/2004 10:40 PM To "Branislav Selic" cc "Pete Rivett" , Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic Agreed that Kernel and Dependencies are a much better choice than Kernel alone for Level 0. To be blunt, such a very simple version of UML 2 would, contrary to what you argue, be useful cause it would be a competitor to the even more simple metamodel that Microsoft will be advocating, but is (unlike the proposed resolution) a UML 2 Superstructure compliance point. Constructs merges Basic, and your argument is that Infrastructure Basic by itself is more useful than Superstructure Kernel which merges Constructs?. Sounds like the mantra "More is Less" turned around, so "Less is More". Or has the Infra FTF turned these packages around completely? What am I missing here? I also don't get it that Java devleopers are the main users. My perception is that the more mature DoD and such are much heavier users of UML that the Java world, and they do a lot of C++ etc. Finally, the objective of having EMF modelling be possible in compliance with UML 2 is still possible with a compliance point defined by reference to the UML 2 spec, at the expense of having it include just a little more than EMF supports. Just don't ues the part that is not needed? - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, August 13, 2004 10:18 AM To: Karl Frank Cc: Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Kernel by itself is not very useful (e.g., it does not even have dependencies or interfaces). I doubt if it would have many adherents. Strangely enough, as I explained in my response to Pete, the proposed Basic by itself is much more meaningful. So, in my view, we either get rid of L0 altogether or leave it the way it is. Bran "Karl Frank" 08/13/2004 09:50 AM To "Pete Rivett" , Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic to voice support for making the changes Pete suggest. Hear! Hear! A specific way to satisfy his request wrt both 1 and 2: In place of the proposal that "level 0" be defined by reference to the Infrastructure Basic, I propose level 0 of UML superstructure compliance should be defined by reference to the Superstructure Kernel package, which is a proper UML 2 modeling capability but a subset of the current proposed level 1. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, August 13, 2004 9:03 AM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Sorry these are late in the day for this draft - but in my defense I have made the 1st 2 substantive points several times before. Substantive comments: 1. I think it's daft to have a Level called 'Basic' which is nothing to do with the package called Basic! Especially when we do have a level virtually identical to the package Basic which is called something else - Core. 2. it seems odd to have Core (equivalent to EMOF) as a compliance level for Superstructure since it represents nothing at all in Superstructure - the most 'primitive' level in Superstructure is Kernel: it seems we should have that as the lowest compliance level. MOF and Infra will have their own compliance levels for which the levels proposed as Core would more naturally fit. (For completeness Core must be included in section 1.4 - though that would show up how little relationship it has to Superstructure!). 3. Section 1.3: last para: the reference to UML Design Interchange should be to UML 2 Diagram Interchange. There is a technical problem I think with the definition of concrete syntax compliance with reference to the DI standard - since the DI metamodel has a mandatory reference from a graphic element to a model element (via an intermediate Bridge class). hence it is not possible to exchange notation only using DI without also having a model to refer to. So as far as I see, as stated stated the concrete syntax compliance definition does not meet the declared aim. 4. Following on from our lengthy discussion about reuse of the same namespace we still do need to have a name for formally referring to "the uml that merges in packages to form the Intermediate level of compliance": this will, for example, form the basis for naming the XML Schema for validating model interchanges for compliance at that level. 5. Why use 'uml' and not the more expected 'UML' - by convention all package names have an initial capital letter at least Editorial/minor comments: In 1.2 it would be better to have a better summary explanation of the capabilities provided by level L2 than 'adds some additional capabilities'. NB there is a typo 'Intermeideiate' First sentence of document states that "This means that a tool at a given level of compliance is able to interchange models with a tool at the same or higher level of compliance" - however the chapter later states that tools could be compliant at concrete syntax level only without the model interchange capability. Section 1.1 has "The modeling concepts of UML are grouped into capability sets, or, simply, capabilities.". I really don't think we need need 2 quite different terms referring to the same thing - especially given that different parts of the chapter use different ones (e.g. 1.3 uses capability whereas 1.4 uses capability set). I flailed around for a while to try to discover how the 2 concepts were related until I found the sentence in 1.1 saying they were the same thing! Given that compliance points are defined purely in terms of specific packages, I think we need a bit more justification for the concept of capabilities at all in terms of the compliance discussion: is it merely so that instead of claiming compliance to anything, vendors can claim they 'support' some capabilities? First para of 1.3 has "underlying concepts in lower levels that are required by that capability.": I think the concept of a concept 'requiring' other concepts should be made less fuzzy since that's not something defined in the specification. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 12, 2004 5:07 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Compliance section reissue Based on Cris' feedback, I have clarified and strengthened the portions of the text that describe the meaning of compliance and compliance levels. The very first paragraph has been modified and section 1.3 that talks about the meaning and forms of compliance has been rewritten. Hopefully this is no longer ambiguous. Thanks, Bran Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Date: Sat, 14 Aug 2004 06:40:52 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance section reissue - let's avoid naoming confusion re Basic Thread-Index: AcSB77I06rI6gy8SSVGFX0kBWN1EeQAEAglg From: "Karl Frank" To: "Jim Amsden" Cc: "Branislav Selic" , "Pete Rivett" , X-OriginalArrivalTime: 14 Aug 2004 13:40:54.0582 (UTC) FILETIME=[52524560:01C48204] Don't get me wrong. I am an admirer of Basic. It is one of the cleanest best thought out parts of UML 2. For one thing, Basic's definition of Data Type declares that datatypes are identfiable. ;-) The real need is to counter Pete's question: Why should the Superstructure define a compliance level in terms of what is not defined in the superstructure? My answer is that the UML name has better market recognition than MOF, so it will be useful to UML users and vendors to have the Superstructure validate compliance with Basic as a form of UML 2 compliance. In challenging Bran's arguments, I am looking for forthright reasons why the Superstructure should define a compliance level by reference to something that is only included by reference in the Superstructure spec; I guess you Java guys think inclusion by reference is better than inclusion by value, but the reasons given initially were not convincing. I think the forthright reason is the marketing reason I gave above. Now, if I understand rightly, you are arguing that Infrastructure Basic is superior to Superstructure Kernel because Kernel is already too complicated. That is convinging to me, and quite different from arguing that Kernel isn't useful, despite the fact that it merges Constructs which already includes Basic. Kernel + Dependencies, my choice for a simplified UML L 0 may indeed be too complex. Kernel has n-ary associations, it has parameter direction kind. These are reasons for saying a more lightweight UML compliance point will be useful. I suspect an unstated reason for advocating Infrastructure Basic has to do with industry strategy relating to Java. - Karl -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, August 14, 2004 7:13 AM To: Karl Frank Cc: Branislav Selic; Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Karl, Basic is just as much part of UML2 super as it is MOF, so there's no reason Basic alone couldn't be a super compliance point. The primary reason for L0 is to ensure tool vendors can easily claim compliance to something. In the past, the barrier to entry for UML was high. UML2 will make it even higher, even just implementing Kernel completely. As a result, there was little interchange between tools. (Of course there are other reasons for this too - including the informality and interpretation of the spec). What we're hoping for is that by providing UML2 compliance level L0 that only includes Basic, we will be able to AT LEAST get interchange of simple structural models built using modeling concepts that are well understood, easily implemented, and with proven value through common practice. This seems like a good place to start to grow interoperability and interchange from where we are today. L1 adds to that by including behavior resulting a metamodel that is sufficiently computationally complete to be executable and translatable to other platform models. "Karl Frank" 08/13/2004 10:40 PM To "Branislav Selic" cc "Pete Rivett" , Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic Agreed that Kernel and Dependencies are a much better choice than Kernel alone for Level 0. To be blunt, such a very simple version of UML 2 would, contrary to what you argue, be useful cause it would be a competitor to the even more simple metamodel that Microsoft will be advocating, but is (unlike the proposed resolution) a UML 2 Superstructure compliance point. Constructs merges Basic, and your argument is that Infrastructure Basic by itself is more useful than Superstructure Kernel which merges Constructs?. Sounds like the mantra "More is Less" turned around, so "Less is More". Or has the Infra FTF turned these packages around completely? What am I missing here? I also don't get it that Java devleopers are the main users. My perception is that the more mature DoD and such are much heavier users of UML that the Java world, and they do a lot of C++ etc. Finally, the objective of having EMF modelling be possible in compliance with UML 2 is still possible with a compliance point defined by reference to the UML 2 spec, at the expense of having it include just a little more than EMF supports. Just don't ues the part that is not needed? - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, August 13, 2004 10:18 AM To: Karl Frank Cc: Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Kernel by itself is not very useful (e.g., it does not even have dependencies or interfaces). I doubt if it would have many adherents. Strangely enough, as I explained in my response to Pete, the proposed Basic by itself is much more meaningful. So, in my view, we either get rid of L0 altogether or leave it the way it is. Bran "Karl Frank" 08/13/2004 09:50 AM To "Pete Rivett" , Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic to voice support for making the changes Pete suggest. Hear! Hear! A specific way to satisfy his request wrt both 1 and 2: In place of the proposal that "level 0" be defined by reference to the Infrastructure Basic, I propose level 0 of UML superstructure compliance should be defined by reference to the Superstructure Kernel package, which is a proper UML 2 modeling capability but a subset of the current proposed level 1. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, August 13, 2004 9:03 AM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Sorry these are late in the day for this draft - but in my defense I have made the 1st 2 substantive points several times before. Substantive comments: 1. I think it's daft to have a Level called 'Basic' which is nothing to do with the package called Basic! Especially when we do have a level virtually identical to the package Basic which is called something else - Core. 2. it seems odd to have Core (equivalent to EMOF) as a compliance level for Superstructure since it represents nothing at all in Superstructure - the most 'primitive' level in Superstructure is Kernel: it seems we should have that as the lowest compliance level. MOF and Infra will have their own compliance levels for which the levels proposed as Core would more naturally fit. (For completeness Core must be included in section 1.4 - though that would show up how little relationship it has to Superstructure!). 3. Section 1.3: last para: the reference to UML Design Interchange should be to UML 2 Diagram Interchange. There is a technical problem I think with the definition of concrete syntax compliance with reference to the DI standard - since the DI metamodel has a mandatory reference from a graphic element to a model element (via an intermediate Bridge class). hence it is not possible to exchange notation only using DI without also having a model to refer to. So as far as I see, as stated stated the concrete syntax compliance definition does not meet the declared aim. 4. Following on from our lengthy discussion about reuse of the same namespace we still do need to have a name for formally referring to "the uml that merges in packages to form the Intermediate level of compliance": this will, for example, form the basis for naming the XML Schema for validating model interchanges for compliance at that level. 5. Why use 'uml' and not the more expected 'UML' - by convention all package names have an initial capital letter at least Editorial/minor comments: In 1.2 it would be better to have a better summary explanation of the capabilities provided by level L2 than 'adds some additional capabilities'. NB there is a typo 'Intermeideiate' First sentence of document states that "This means that a tool at a given level of compliance is able to interchange models with a tool at the same or higher level of compliance" - however the chapter later states that tools could be compliant at concrete syntax level only without the model interchange capability. Section 1.1 has "The modeling concepts of UML are grouped into capability sets, or, simply, capabilities.". I really don't think we need need 2 quite different terms referring to the same thing - especially given that different parts of the chapter use different ones (e.g. 1.3 uses capability whereas 1.4 uses capability set). I flailed around for a while to try to discover how the 2 concepts were related until I found the sentence in 1.1 saying they were the same thing! Given that compliance points are defined purely in terms of specific packages, I think we need a bit more justification for the concept of capabilities at all in terms of the compliance discussion: is it merely so that instead of claiming compliance to anything, vendors can claim they 'support' some capabilities? First para of 1.3 has "underlying concepts in lower levels that are required by that capability.": I think the concept of a concept 'requiring' other concepts should be made less fuzzy since that's not something defined in the specification. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 12, 2004 5:07 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Compliance section reissue Based on Cris' feedback, I have clarified and strengthened the portions of the text that describe the meaning of compliance and compliance levels. The very first paragraph has been modified and section 1.3 that talks about the meaning and forms of compliance has been rewritten. Hopefully this is no longer ambiguous. Thanks, Bran To: "Karl Frank" Cc: "Branislav Selic" , "Pete Rivett" , uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Sat, 14 Aug 2004 09:56:36 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/14/2004 08:00:19, Serialize complete at 08/14/2004 08:00:19 Karl, I doubt anyone will much care that Basic is defined in InfrastructureLibrary and not Superstructure. The users of UML will likely be reading books and product literature, not the specifations. And if they do, they might read them both since their both from OMG. In any case, we're not talking about MOF, InfrastructureLibrary, or Superstructure, we're talking about UML2 and how to best move the industry forward. I know of no particular bias towards Java. IBM uses EMF (EMOF/Basic) for modeling all sorts of things that aren't Java, but also including J2EE and Java. I'm just looking for something that can establish minimal interoperability and interchange, something we don't have now, of model elements that are (to repeat myself) well understood, easily implemented, and have proven value through common practice. "Karl Frank" 08/14/2004 09:40 AM To Jim Amsden/Raleigh/IBM@IBMUS cc "Branislav Selic" , "Pete Rivett" , Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic Don't get me wrong. I am an admirer of Basic. It is one of the cleanest best thought out parts of UML 2. For one thing, Basic's definition of Data Type declares that datatypes are identfiable. ;-) The real need is to counter Pete's question: Why should the Superstructure define a compliance level in terms of what is not defined in the superstructure? My answer is that the UML name has better market recognition than MOF, so it will be useful to UML users and vendors to have the Superstructure validate compliance with Basic as a form of UML 2 compliance. In challenging Bran's arguments, I am looking for forthright reasons why the Superstructure should define a compliance level by reference to something that is only included by reference in the Superstructure spec; I guess you Java guys think inclusion by reference is better than inclusion by value, but the reasons given initially were not convincing. I think the forthright reason is the marketing reason I gave above. Now, if I understand rightly, you are arguing that Infrastructure Basic is superior to Superstructure Kernel because Kernel is already too complicated. That is convinging to me, and quite different from arguing that Kernel isn't useful, despite the fact that it merges Constructs which already includes Basic. Kernel + Dependencies, my choice for a simplified UML L 0 may indeed be too complex. Kernel has n-ary associations, it has parameter direction kind. These are reasons for saying a more lightweight UML compliance point will be useful. I suspect an unstated reason for advocating Infrastructure Basic has to do with industry strategy relating to Java. - Karl -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, August 14, 2004 7:13 AM To: Karl Frank Cc: Branislav Selic; Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Karl, Basic is just as much part of UML2 super as it is MOF, so there's no reason Basic alone couldn't be a super compliance point. The primary reason for L0 is to ensure tool vendors can easily claim compliance to something. In the past, the barrier to entry for UML was high. UML2 will make it even higher, even just implementing Kernel completely. As a result, there was little interchange between tools. (Of course there are other reasons for this too - including the informality and interpretation of the spec). What we're hoping for is that by providing UML2 compliance level L0 that only includes Basic, we will be able to AT LEAST get interchange of simple structural models built using modeling concepts that are well understood, easily implemented, and with proven value through common practice. This seems like a good place to start to grow interoperability and interchange from where we are today. L1 adds to that by including behavior resulting a metamodel that is sufficiently computationally complete to be executable and translatable to other platform models. "Karl Frank" 08/13/2004 10:40 PM To "Branislav Selic" cc "Pete Rivett" , Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic Agreed that Kernel and Dependencies are a much better choice than Kernel alone for Level 0. To be blunt, such a very simple version of UML 2 would, contrary to what you argue, be useful cause it would be a competitor to the even more simple metamodel that Microsoft will be advocating, but is (unlike the proposed resolution) a UML 2 Superstructure compliance point. Constructs merges Basic, and your argument is that Infrastructure Basic by itself is more useful than Superstructure Kernel which merges Constructs?. Sounds like the mantra "More is Less" turned around, so "Less is More". Or has the Infra FTF turned these packages around completely? What am I missing here? I also don't get it that Java devleopers are the main users. My perception is that the more mature DoD and such are much heavier users of UML that the Java world, and they do a lot of C++ etc. Finally, the objective of having EMF modelling be possible in compliance with UML 2 is still possible with a compliance point defined by reference to the UML 2 spec, at the expense of having it include just a little more than EMF supports. Just don't ues the part that is not needed? - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, August 13, 2004 10:18 AM To: Karl Frank Cc: Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Kernel by itself is not very useful (e.g., it does not even have dependencies or interfaces). I doubt if it would have many adherents. Strangely enough, as I explained in my response to Pete, the proposed Basic by itself is much more meaningful. So, in my view, we either get rid of L0 altogether or leave it the way it is. Bran "Karl Frank" 08/13/2004 09:50 AM To "Pete Rivett" , Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic to voice support for making the changes Pete suggest. Hear! Hear! A specific way to satisfy his request wrt both 1 and 2: In place of the proposal that "level 0" be defined by reference to the Infrastructure Basic, I propose level 0 of UML superstructure compliance should be defined by reference to the Superstructure Kernel package, which is a proper UML 2 modeling capability but a subset of the current proposed level 1. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, August 13, 2004 9:03 AM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Sorry these are late in the day for this draft - but in my defense I have made the 1st 2 substantive points several times before. Substantive comments: 1. I think it's daft to have a Level called 'Basic' which is nothing to do with the package called Basic! Especially when we do have a level virtually identical to the package Basic which is called something else - Core. 2. it seems odd to have Core (equivalent to EMOF) as a compliance level for Superstructure since it represents nothing at all in Superstructure - the most 'primitive' level in Superstructure is Kernel: it seems we should have that as the lowest compliance level. MOF and Infra will have their own compliance levels for which the levels proposed as Core would more naturally fit. (For completeness Core must be included in section 1.4 - though that would show up how little relationship it has to Superstructure!). 3. Section 1.3: last para: the reference to UML Design Interchange should be to UML 2 Diagram Interchange. There is a technical problem I think with the definition of concrete syntax compliance with reference to the DI standard - since the DI metamodel has a mandatory reference from a graphic element to a model element (via an intermediate Bridge class). hence it is not possible to exchange notation only using DI without also having a model to refer to. So as far as I see, as stated stated the concrete syntax compliance definition does not meet the declared aim. 4. Following on from our lengthy discussion about reuse of the same namespace we still do need to have a name for formally referring to "the uml that merges in packages to form the Intermediate level of compliance": this will, for example, form the basis for naming the XML Schema for validating model interchanges for compliance at that level. 5. Why use 'uml' and not the more expected 'UML' - by convention all package names have an initial capital letter at least Editorial/minor comments: In 1.2 it would be better to have a better summary explanation of the capabilities provided by level L2 than 'adds some additional capabilities'. NB there is a typo 'Intermeideiate' First sentence of document states that "This means that a tool at a given level of compliance is able to interchange models with a tool at the same or higher level of compliance" - however the chapter later states that tools could be compliant at concrete syntax level only without the model interchange capability. Section 1.1 has "The modeling concepts of UML are grouped into capability sets, or, simply, capabilities.". I really don't think we need need 2 quite different terms referring to the same thing - especially given that different parts of the chapter use different ones (e.g. 1.3 uses capability whereas 1.4 uses capability set). I flailed around for a while to try to discover how the 2 concepts were related until I found the sentence in 1.1 saying they were the same thing! Given that compliance points are defined purely in terms of specific packages, I think we need a bit more justification for the concept of capabilities at all in terms of the compliance discussion: is it merely so that instead of claiming compliance to anything, vendors can claim they 'support' some capabilities? First para of 1.3 has "underlying concepts in lower levels that are required by that capability.": I think the concept of a concept 'requiring' other concepts should be made less fuzzy since that's not something defined in the specification. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 12, 2004 5:07 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Compliance section reissue Based on Cris' feedback, I have clarified and strengthened the portions of the text that describe the meaning of compliance and compliance levels. The very first paragraph has been modified and section 1.3 that talks about the meaning and forms of compliance has been rewritten. Hopefully this is no longer ambiguous. Thanks, Bran Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Date: Sat, 14 Aug 2004 07:31:01 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance section reissue - let's avoid naoming confusion re Basic Thread-Index: AcSCBwsiXTGH50oqSOm+l7SgDjg7VwAAtBbg From: "Karl Frank" To: "Jim Amsden" Cc: "Branislav Selic" , "Pete Rivett" , X-OriginalArrivalTime: 14 Aug 2004 14:31:04.0295 (UTC) FILETIME=[54400770:01C4820B] OK, I am agreeable to the proposal to have Level 0 be defined as proposed in the circulated resolution, as modifed in response to Pete's issue about naming confusion (just use Level numbers as the identifiers for compliance points, no names such as "basic"). Pete still has an issue with respect to conformance of diagrams to the abstract syntax, which I do not recall as being adequately addressed yet by any proposed modification of the proposed resolution. Limitations on concrete notation is surely what the abstract syntax is meant to impose on diagrams, as Pete explains. Has Pete's point been addressed in an email I missed? If so, I think we have a good proposal for resolving the compliance issue. - Karl -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, August 14, 2004 9:57 AM To: Karl Frank Cc: Branislav Selic; Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Karl, I doubt anyone will much care that Basic is defined in InfrastructureLibrary and not Superstructure. The users of UML will likely be reading books and product literature, not the specifations. And if they do, they might read them both since their both from OMG. In any case, we're not talking about MOF, InfrastructureLibrary, or Superstructure, we're talking about UML2 and how to best move the industry forward. I know of no particular bias towards Java. IBM uses EMF (EMOF/Basic) for modeling all sorts of things that aren't Java, but also including J2EE and Java. I'm just looking for something that can establish minimal interoperability and interchange, something we don't have now, of model elements that are (to repeat myself) well understood, easily implemented, and have proven value through common practice. "Karl Frank" 08/14/2004 09:40 AM To Jim Amsden/Raleigh/IBM@IBMUS cc "Branislav Selic" , "Pete Rivett" , Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic Don't get me wrong. I am an admirer of Basic. It is one of the cleanest best thought out parts of UML 2. For one thing, Basic's definition of Data Type declares that datatypes are identfiable. ;-) The real need is to counter Pete's question: Why should the Superstructure define a compliance level in terms of what is not defined in the superstructure? My answer is that the UML name has better market recognition than MOF, so it will be useful to UML users and vendors to have the Superstructure validate compliance with Basic as a form of UML 2 compliance. In challenging Bran's arguments, I am looking for forthright reasons why the Superstructure should define a compliance level by reference to something that is only included by reference in the Superstructure spec; I guess you Java guys think inclusion by reference is better than inclusion by value, but the reasons given initially were not convincing. I think the forthright reason is the marketing reason I gave above. Now, if I understand rightly, you are arguing that Infrastructure Basic is superior to Superstructure Kernel because Kernel is already too complicated. That is convinging to me, and quite different from arguing that Kernel isn't useful, despite the fact that it merges Constructs which already includes Basic. Kernel + Dependencies, my choice for a simplified UML L 0 may indeed be too complex. Kernel has n-ary associations, it has parameter direction kind. These are reasons for saying a more lightweight UML compliance point will be useful. I suspect an unstated reason for advocating Infrastructure Basic has to do with industry strategy relating to Java. - Karl -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, August 14, 2004 7:13 AM To: Karl Frank Cc: Branislav Selic; Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Karl, Basic is just as much part of UML2 super as it is MOF, so there's no reason Basic alone couldn't be a super compliance point. The primary reason for L0 is to ensure tool vendors can easily claim compliance to something. In the past, the barrier to entry for UML was high. UML2 will make it even higher, even just implementing Kernel completely. As a result, there was little interchange between tools. (Of course there are other reasons for this too - including the informality and interpretation of the spec). What we're hoping for is that by providing UML2 compliance level L0 that only includes Basic, we will be able to AT LEAST get interchange of simple structural models built using modeling concepts that are well understood, easily implemented, and with proven value through common practice. This seems like a good place to start to grow interoperability and interchange from where we are today. L1 adds to that by including behavior resulting a metamodel that is sufficiently computationally complete to be executable and translatable to other platform models. "Karl Frank" 08/13/2004 10:40 PM To "Branislav Selic" cc "Pete Rivett" , Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic Agreed that Kernel and Dependencies are a much better choice than Kernel alone for Level 0. To be blunt, such a very simple version of UML 2 would, contrary to what you argue, be useful cause it would be a competitor to the even more simple metamodel that Microsoft will be advocating, but is (unlike the proposed resolution) a UML 2 Superstructure compliance point. Constructs merges Basic, and your argument is that Infrastructure Basic by itself is more useful than Superstructure Kernel which merges Constructs?. Sounds like the mantra "More is Less" turned around, so "Less is More". Or has the Infra FTF turned these packages around completely? What am I missing here? I also don't get it that Java devleopers are the main users. My perception is that the more mature DoD and such are much heavier users of UML that the Java world, and they do a lot of C++ etc. Finally, the objective of having EMF modelling be possible in compliance with UML 2 is still possible with a compliance point defined by reference to the UML 2 spec, at the expense of having it include just a little more than EMF supports. Just don't ues the part that is not needed? - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, August 13, 2004 10:18 AM To: Karl Frank Cc: Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Kernel by itself is not very useful (e.g., it does not even have dependencies or interfaces). I doubt if it would have many adherents. Strangely enough, as I explained in my response to Pete, the proposed Basic by itself is much more meaningful. So, in my view, we either get rid of L0 altogether or leave it the way it is. Bran "Karl Frank" 08/13/2004 09:50 AM To "Pete Rivett" , Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic to voice support for making the changes Pete suggest. Hear! Hear! A specific way to satisfy his request wrt both 1 and 2: In place of the proposal that "level 0" be defined by reference to the Infrastructure Basic, I propose level 0 of UML superstructure compliance should be defined by reference to the Superstructure Kernel package, which is a proper UML 2 modeling capability but a subset of the current proposed level 1. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, August 13, 2004 9:03 AM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Sorry these are late in the day for this draft - but in my defense I have made the 1st 2 substantive points several times before. Substantive comments: 1. I think it's daft to have a Level called 'Basic' which is nothing to do with the package called Basic! Especially when we do have a level virtually identical to the package Basic which is called something else - Core. 2. it seems odd to have Core (equivalent to EMOF) as a compliance level for Superstructure since it represents nothing at all in Superstructure - the most 'primitive' level in Superstructure is Kernel: it seems we should have that as the lowest compliance level. MOF and Infra will have their own compliance levels for which the levels proposed as Core would more naturally fit. (For completeness Core must be included in section 1.4 - though that would show up how little relationship it has to Superstructure!). 3. Section 1.3: last para: the reference to UML Design Interchange should be to UML 2 Diagram Interchange. There is a technical problem I think with the definition of concrete syntax compliance with reference to the DI standard - since the DI metamodel has a mandatory reference from a graphic element to a model element (via an intermediate Bridge class). hence it is not possible to exchange notation only using DI without also having a model to refer to. So as far as I see, as stated stated the concrete syntax compliance definition does not meet the declared aim. 4. Following on from our lengthy discussion about reuse of the same namespace we still do need to have a name for formally referring to "the uml that merges in packages to form the Intermediate level of compliance": this will, for example, form the basis for naming the XML Schema for validating model interchanges for compliance at that level. 5. Why use 'uml' and not the more expected 'UML' - by convention all package names have an initial capital letter at least Editorial/minor comments: In 1.2 it would be better to have a better summary explanation of the capabilities provided by level L2 than 'adds some additional capabilities'. NB there is a typo 'Intermeideiate' First sentence of document states that "This means that a tool at a given level of compliance is able to interchange models with a tool at the same or higher level of compliance" - however the chapter later states that tools could be compliant at concrete syntax level only without the model interchange capability. Section 1.1 has "The modeling concepts of UML are grouped into capability sets, or, simply, capabilities.". I really don't think we need need 2 quite different terms referring to the same thing - especially given that different parts of the chapter use different ones (e.g. 1.3 uses capability whereas 1.4 uses capability set). I flailed around for a while to try to discover how the 2 concepts were related until I found the sentence in 1.1 saying they were the same thing! Given that compliance points are defined purely in terms of specific packages, I think we need a bit more justification for the concept of capabilities at all in terms of the compliance discussion: is it merely so that instead of claiming compliance to anything, vendors can claim they 'support' some capabilities? First para of 1.3 has "underlying concepts in lower levels that are required by that capability.": I think the concept of a concept 'requiring' other concepts should be made less fuzzy since that's not something defined in the specification. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 12, 2004 5:07 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Compliance section reissue Based on Cris' feedback, I have clarified and strengthened the portions of the text that describe the meaning of compliance and compliance levels. The very first paragraph has been modified and section 1.3 that talks about the meaning and forms of compliance has been rewritten. Hopefully this is no longer ambiguous. Thanks, Bran To: "Karl Frank" Cc: "Branislav Selic" , "Pete Rivett" , uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Sat, 14 Aug 2004 11:14:47 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/14/2004 09:14:55, Serialize complete at 08/14/2004 09:14:55 Karl, The diminsions of compliance were intended to be abstract syntax (or just metamodel) and notation (with semantics to come later). We somehow coupled notation with diagram interchange - probably because abstract syntax is coupled XMI. Diagram interchange has a ways to go, and I don't know if its going to address parsing text. There's also a possibility of having some text notation for UML. Interoperability and interchange are most effected by the metamodel, so that's a good place to start for compliance. There are also likely to be lots of variation in diagrams and notation to support domain specific languages. Maybe we should defer notation and semantics compliance for a subsequent RTF. "Karl Frank" 08/14/2004 10:31 AM To Jim Amsden/Raleigh/IBM@IBMUS cc "Branislav Selic" , "Pete Rivett" , Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic OK, I am agreeable to the proposal to have Level 0 be defined as proposed in the circulated resolution, as modifed in response to Pete's issue about naming confusion (just use Level numbers as the identifiers for compliance points, no names such as "basic"). Pete still has an issue with respect to conformance of diagrams to the abstract syntax, which I do not recall as being adequately addressed yet by any proposed modification of the proposed resolution. Limitations on concrete notation is surely what the abstract syntax is meant to impose on diagrams, as Pete explains. Has Pete's point been addressed in an email I missed? If so, I think we have a good proposal for resolving the compliance issue. - Karl -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, August 14, 2004 9:57 AM To: Karl Frank Cc: Branislav Selic; Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Karl, I doubt anyone will much care that Basic is defined in InfrastructureLibrary and not Superstructure. The users of UML will likely be reading books and product literature, not the specifations. And if they do, they might read them both since their both from OMG. In any case, we're not talking about MOF, InfrastructureLibrary, or Superstructure, we're talking about UML2 and how to best move the industry forward. I know of no particular bias towards Java. IBM uses EMF (EMOF/Basic) for modeling all sorts of things that aren't Java, but also including J2EE and Java. I'm just looking for something that can establish minimal interoperability and interchange, something we don't have now, of model elements that are (to repeat myself) well understood, easily implemented, and have proven value through common practice. "Karl Frank" 08/14/2004 09:40 AM To Jim Amsden/Raleigh/IBM@IBMUS cc "Branislav Selic" , "Pete Rivett" , Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic Don't get me wrong. I am an admirer of Basic. It is one of the cleanest best thought out parts of UML 2. For one thing, Basic's definition of Data Type declares that datatypes are identfiable. ;-) The real need is to counter Pete's question: Why should the Superstructure define a compliance level in terms of what is not defined in the superstructure? My answer is that the UML name has better market recognition than MOF, so it will be useful to UML users and vendors to have the Superstructure validate compliance with Basic as a form of UML 2 compliance. In challenging Bran's arguments, I am looking for forthright reasons why the Superstructure should define a compliance level by reference to something that is only included by reference in the Superstructure spec; I guess you Java guys think inclusion by reference is better than inclusion by value, but the reasons given initially were not convincing. I think the forthright reason is the marketing reason I gave above. Now, if I understand rightly, you are arguing that Infrastructure Basic is superior to Superstructure Kernel because Kernel is already too complicated. That is convinging to me, and quite different from arguing that Kernel isn't useful, despite the fact that it merges Constructs which already includes Basic. Kernel + Dependencies, my choice for a simplified UML L 0 may indeed be too complex. Kernel has n-ary associations, it has parameter direction kind. These are reasons for saying a more lightweight UML compliance point will be useful. I suspect an unstated reason for advocating Infrastructure Basic has to do with industry strategy relating to Java. - Karl -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, August 14, 2004 7:13 AM To: Karl Frank Cc: Branislav Selic; Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Karl, Basic is just as much part of UML2 super as it is MOF, so there's no reason Basic alone couldn't be a super compliance point. The primary reason for L0 is to ensure tool vendors can easily claim compliance to something. In the past, the barrier to entry for UML was high. UML2 will make it even higher, even just implementing Kernel completely. As a result, there was little interchange between tools. (Of course there are other reasons for this too - including the informality and interpretation of the spec). What we're hoping for is that by providing UML2 compliance level L0 that only includes Basic, we will be able to AT LEAST get interchange of simple structural models built using modeling concepts that are well understood, easily implemented, and with proven value through common practice. This seems like a good place to start to grow interoperability and interchange from where we are today. L1 adds to that by including behavior resulting a metamodel that is sufficiently computationally complete to be executable and translatable to other platform models. "Karl Frank" 08/13/2004 10:40 PM To "Branislav Selic" cc "Pete Rivett" , Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic Agreed that Kernel and Dependencies are a much better choice than Kernel alone for Level 0. To be blunt, such a very simple version of UML 2 would, contrary to what you argue, be useful cause it would be a competitor to the even more simple metamodel that Microsoft will be advocating, but is (unlike the proposed resolution) a UML 2 Superstructure compliance point. Constructs merges Basic, and your argument is that Infrastructure Basic by itself is more useful than Superstructure Kernel which merges Constructs?. Sounds like the mantra "More is Less" turned around, so "Less is More". Or has the Infra FTF turned these packages around completely? What am I missing here? I also don't get it that Java devleopers are the main users. My perception is that the more mature DoD and such are much heavier users of UML that the Java world, and they do a lot of C++ etc. Finally, the objective of having EMF modelling be possible in compliance with UML 2 is still possible with a compliance point defined by reference to the UML 2 spec, at the expense of having it include just a little more than EMF supports. Just don't ues the part that is not needed? - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, August 13, 2004 10:18 AM To: Karl Frank Cc: Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Kernel by itself is not very useful (e.g., it does not even have dependencies or interfaces). I doubt if it would have many adherents. Strangely enough, as I explained in my response to Pete, the proposed Basic by itself is much more meaningful. So, in my view, we either get rid of L0 altogether or leave it the way it is. Bran "Karl Frank" 08/13/2004 09:50 AM To "Pete Rivett" , Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic to voice support for making the changes Pete suggest. Hear! Hear! A specific way to satisfy his request wrt both 1 and 2: In place of the proposal that "level 0" be defined by reference to the Infrastructure Basic, I propose level 0 of UML superstructure compliance should be defined by reference to the Superstructure Kernel package, which is a proper UML 2 modeling capability but a subset of the current proposed level 1. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, August 13, 2004 9:03 AM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Sorry these are late in the day for this draft - but in my defense I have made the 1st 2 substantive points several times before. Substantive comments: 1. I think it's daft to have a Level called 'Basic' which is nothing to do with the package called Basic! Especially when we do have a level virtually identical to the package Basic which is called something else - Core. 2. it seems odd to have Core (equivalent to EMOF) as a compliance level for Superstructure since it represents nothing at all in Superstructure - the most 'primitive' level in Superstructure is Kernel: it seems we should have that as the lowest compliance level. MOF and Infra will have their own compliance levels for which the levels proposed as Core would more naturally fit. (For completeness Core must be included in section 1.4 - though that would show up how little relationship it has to Superstructure!). 3. Section 1.3: last para: the reference to UML Design Interchange should be to UML 2 Diagram Interchange. There is a technical problem I think with the definition of concrete syntax compliance with reference to the DI standard - since the DI metamodel has a mandatory reference from a graphic element to a model element (via an intermediate Bridge class). hence it is not possible to exchange notation only using DI without also having a model to refer to. So as far as I see, as stated stated the concrete syntax compliance definition does not meet the declared aim. 4. Following on from our lengthy discussion about reuse of the same namespace we still do need to have a name for formally referring to "the uml that merges in packages to form the Intermediate level of compliance": this will, for example, form the basis for naming the XML Schema for validating model interchanges for compliance at that level. 5. Why use 'uml' and not the more expected 'UML' - by convention all package names have an initial capital letter at least Editorial/minor comments: In 1.2 it would be better to have a better summary explanation of the capabilities provided by level L2 than 'adds some additional capabilities'. NB there is a typo 'Intermeideiate' First sentence of document states that "This means that a tool at a given level of compliance is able to interchange models with a tool at the same or higher level of compliance" - however the chapter later states that tools could be compliant at concrete syntax level only without the model interchange capability. Section 1.1 has "The modeling concepts of UML are grouped into capability sets, or, simply, capabilities.". I really don't think we need need 2 quite different terms referring to the same thing - especially given that different parts of the chapter use different ones (e.g. 1.3 uses capability whereas 1.4 uses capability set). I flailed around for a while to try to discover how the 2 concepts were related until I found the sentence in 1.1 saying they were the same thing! Given that compliance points are defined purely in terms of specific packages, I think we need a bit more justification for the concept of capabilities at all in terms of the compliance discussion: is it merely so that instead of claiming compliance to anything, vendors can claim they 'support' some capabilities? First para of 1.3 has "underlying concepts in lower levels that are required by that capability.": I think the concept of a concept 'requiring' other concepts should be made less fuzzy since that's not something defined in the specification. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 12, 2004 5:07 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Compliance section reissue Based on Cris' feedback, I have clarified and strengthened the portions of the text that describe the meaning of compliance and compliance levels. The very first paragraph has been modified and section 1.3 that talks about the meaning and forms of compliance has been rewritten. Hopefully this is no longer ambiguous. Thanks, Bran Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Date: Sat, 14 Aug 2004 11:33:18 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compliance section reissue - let's avoid naoming confusion re Basic Thread-Index: AcSCEup4jydyIXHdSgmbCdhwel/hYwAAMgJw From: "Pete Rivett" To: "Jim Amsden" , "Karl Frank" Cc: "Branislav Selic" , X-Virus-Scanned: by amavisd-new at sentraliant.com Jim, My main point about notation was less about interchange, than about whether notation compliance should require the tool to not permit "invalid diagrams" (which I defined in my previous email). To be more concrete, I propose we drop the need for diagram interchange in Superstructure (the DI spec will itself contain compliance points that cover this) and introduce the requirement above that notation compliance should require tools to have the ability to enforce diagram validity. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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, August 14, 2004 4:15 PM To: Karl Frank Cc: Branislav Selic; Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Karl, The diminsions of compliance were intended to be abstract syntax (or just metamodel) and notation (with semantics to come later). We somehow coupled notation with diagram interchange - probably because abstract syntax is coupled XMI. Diagram interchange has a ways to go, and I don't know if its going to address parsing text. There's also a possibility of having some text notation for UML. Interoperability and interchange are most effected by the metamodel, so that's a good place to start for compliance. There are also likely to be lots of variation in diagrams and notation to support domain specific languages. Maybe we should defer notation and semantics compliance for a subsequent RTF. "Karl Frank" 08/14/2004 10:31 AM To Jim Amsden/Raleigh/IBM@IBMUS cc "Branislav Selic" , "Pete Rivett" , Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic OK, I am agreeable to the proposal to have Level 0 be defined as proposed in the circulated resolution, as modifed in response to Pete's issue about naming confusion (just use Level numbers as the identifiers for compliance points, no names such as "basic"). Pete still has an issue with respect to conformance of diagrams to the abstract syntax, which I do not recall as being adequately addressed yet by any proposed modification of the proposed resolution. Limitations on concrete notation is surely what the abstract syntax is meant to impose on diagrams, as Pete explains. Has Pete's point been addressed in an email I missed? If so, I think we have a good proposal for resolving the compliance issue. - Karl -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, August 14, 2004 9:57 AM To: Karl Frank Cc: Branislav Selic; Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Karl, I doubt anyone will much care that Basic is defined in InfrastructureLibrary and not Superstructure. The users of UML will likely be reading books and product literature, not the specifations. And if they do, they might read them both since their both from OMG. In any case, we're not talking about MOF, InfrastructureLibrary, or Superstructure, we're talking about UML2 and how to best move the industry forward. I know of no particular bias towards Java. IBM uses EMF (EMOF/Basic) for modeling all sorts of things that aren't Java, but also including J2EE and Java. I'm just looking for something that can establish minimal interoperability and interchange, something we don't have now, of model elements that are (to repeat myself) well understood, easily implemented, and have proven value through common practice. "Karl Frank" 08/14/2004 09:40 AM To Jim Amsden/Raleigh/IBM@IBMUS cc "Branislav Selic" , "Pete Rivett" , Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic Don't get me wrong. I am an admirer of Basic. It is one of the cleanest best thought out parts of UML 2. For one thing, Basic's definition of Data Type declares that datatypes are identfiable. ;-) The real need is to counter Pete's question: Why should the Superstructure define a compliance level in terms of what is not defined in the superstructure? My answer is that the UML name has better market recognition than MOF, so it will be useful to UML users and vendors to have the Superstructure validate compliance with Basic as a form of UML 2 compliance. In challenging Bran's arguments, I am looking for forthright reasons why the Superstructure should define a compliance level by reference to something that is only included by reference in the Superstructure spec; I guess you Java guys think inclusion by reference is better than inclusion by value, but the reasons given initially were not convincing. I think the forthright reason is the marketing reason I gave above. Now, if I understand rightly, you are arguing that Infrastructure Basic is superior to Superstructure Kernel because Kernel is already too complicated. That is convinging to me, and quite different from arguing that Kernel isn't useful, despite the fact that it merges Constructs which already includes Basic. Kernel + Dependencies, my choice for a simplified UML L 0 may indeed be too complex. Kernel has n-ary associations, it has parameter direction kind. These are reasons for saying a more lightweight UML compliance point will be useful. I suspect an unstated reason for advocating Infrastructure Basic has to do with industry strategy relating to Java. - Karl -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, August 14, 2004 7:13 AM To: Karl Frank Cc: Branislav Selic; Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Karl, Basic is just as much part of UML2 super as it is MOF, so there's no reason Basic alone couldn't be a super compliance point. The primary reason for L0 is to ensure tool vendors can easily claim compliance to something. In the past, the barrier to entry for UML was high. UML2 will make it even higher, even just implementing Kernel completely. As a result, there was little interchange between tools. (Of course there are other reasons for this too - including the informality and interpretation of the spec). What we're hoping for is that by providing UML2 compliance level L0 that only includes Basic, we will be able to AT LEAST get interchange of simple structural models built using modeling concepts that are well understood, easily implemented, and with proven value through common practice. This seems like a good place to start to grow interoperability and interchange from where we are today. L1 adds to that by including behavior resulting a metamodel that is sufficiently computationally complete to be executable and translatable to other platform models. "Karl Frank" 08/13/2004 10:40 PM To "Branislav Selic" cc "Pete Rivett" , Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic Agreed that Kernel and Dependencies are a much better choice than Kernel alone for Level 0. To be blunt, such a very simple version of UML 2 would, contrary to what you argue, be useful cause it would be a competitor to the even more simple metamodel that Microsoft will be advocating, but is (unlike the proposed resolution) a UML 2 Superstructure compliance point. Constructs merges Basic, and your argument is that Infrastructure Basic by itself is more useful than Superstructure Kernel which merges Constructs?. Sounds like the mantra "More is Less" turned around, so "Less is More". Or has the Infra FTF turned these packages around completely? What am I missing here? I also don't get it that Java devleopers are the main users. My perception is that the more mature DoD and such are much heavier users of UML that the Java world, and they do a lot of C++ etc. Finally, the objective of having EMF modelling be possible in compliance with UML 2 is still possible with a compliance point defined by reference to the UML 2 spec, at the expense of having it include just a little more than EMF supports. Just don't ues the part that is not needed? - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, August 13, 2004 10:18 AM To: Karl Frank Cc: Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Kernel by itself is not very useful (e.g., it does not even have dependencies or interfaces). I doubt if it would have many adherents. Strangely enough, as I explained in my response to Pete, the proposed Basic by itself is much more meaningful. So, in my view, we either get rid of L0 altogether or leave it the way it is. Bran "Karl Frank" 08/13/2004 09:50 AM To "Pete Rivett" , Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic to voice support for making the changes Pete suggest. Hear! Hear! A specific way to satisfy his request wrt both 1 and 2: In place of the proposal that "level 0" be defined by reference to the Infrastructure Basic, I propose level 0 of UML superstructure compliance should be defined by reference to the Superstructure Kernel package, which is a proper UML 2 modeling capability but a subset of the current proposed level 1. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, August 13, 2004 9:03 AM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Sorry these are late in the day for this draft - but in my defense I have made the 1st 2 substantive points several times before. Substantive comments: 1. I think it's daft to have a Level called 'Basic' which is nothing to do with the package called Basic! Especially when we do have a level virtually identical to the package Basic which is called something else - Core. 2. it seems odd to have Core (equivalent to EMOF) as a compliance level for Superstructure since it represents nothing at all in Superstructure - the most 'primitive' level in Superstructure is Kernel: it seems we should have that as the lowest compliance level. MOF and Infra will have their own compliance levels for which the levels proposed as Core would more naturally fit. (For completeness Core must be included in section 1.4 - though that would show up how little relationship it has to Superstructure!). 3. Section 1.3: last para: the reference to UML Design Interchange should be to UML 2 Diagram Interchange. There is a technical problem I think with the definition of concrete syntax compliance with reference to the DI standard - since the DI metamodel has a mandatory reference from a graphic element to a model element (via an intermediate Bridge class). hence it is not possible to exchange notation only using DI without also having a model to refer to. So as far as I see, as stated stated the concrete syntax compliance definition does not meet the declared aim. 4. Following on from our lengthy discussion about reuse of the same namespace we still do need to have a name for formally referring to "the uml that merges in packages to form the Intermediate level of compliance": this will, for example, form the basis for naming the XML Schema for validating model interchanges for compliance at that level. 5. Why use 'uml' and not the more expected 'UML' - by convention all package names have an initial capital letter at least Editorial/minor comments: In 1.2 it would be better to have a better summary explanation of the capabilities provided by level L2 than 'adds some additional capabilities'. NB there is a typo 'Intermeideiate' First sentence of document states that "This means that a tool at a given level of compliance is able to interchange models with a tool at the same or higher level of compliance" - however the chapter later states that tools could be compliant at concrete syntax level only without the model interchange capability. Section 1.1 has "The modeling concepts of UML are grouped into capability sets, or, simply, capabilities.". I really don't think we need need 2 quite different terms referring to the same thing - especially given that different parts of the chapter use different ones (e.g. 1.3 uses capability whereas 1.4 uses capability set). I flailed around for a while to try to discover how the 2 concepts were related until I found the sentence in 1.1 saying they were the same thing! Given that compliance points are defined purely in terms of specific packages, I think we need a bit more justification for the concept of capabilities at all in terms of the compliance discussion: is it merely so that instead of claiming compliance to anything, vendors can claim they 'support' some capabilities? First para of 1.3 has "underlying concepts in lower levels that are required by that capability.": I think the concept of a concept 'requiring' other concepts should be made less fuzzy since that's not something defined in the specification. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 12, 2004 5:07 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Compliance section reissue Based on Cris' feedback, I have clarified and strengthened the portions of the text that describe the meaning of compliance and compliance levels. The very first paragraph has been modified and section 1.3 that talks about the meaning and forms of compliance has been rewritten. Hopefully this is no longer ambiguous. Thanks, Bran To: "Pete Rivett" Cc: "Branislav Selic" , "Karl Frank" , uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Sat, 14 Aug 2004 12:23:33 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/14/2004 10:23:37, Serialize complete at 08/14/2004 10:23:37 Pete, I agree, but think we might want to think about going a step further and not even include notation conformance at this point. We don't have any way to verify conformance, so it doesn't make too much sense to talk about it until we do. "Pete Rivett" 08/14/2004 11:33 AM To Jim Amsden/Raleigh/IBM@IBMUS, "Karl Frank" cc "Branislav Selic" , Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic Jim, My main point about notation was less about interchange, than about whether notation compliance should require the tool to not permit "invalid diagrams" (which I defined in my previous email). To be more concrete, I propose we drop the need for diagram interchange in Superstructure (the DI spec will itself contain compliance points that cover this) and introduce the requirement above that notation compliance should require tools to have the ability to enforce diagram validity. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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, August 14, 2004 4:15 PM To: Karl Frank Cc: Branislav Selic; Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Karl, The diminsions of compliance were intended to be abstract syntax (or just metamodel) and notation (with semantics to come later). We somehow coupled notation with diagram interchange - probably because abstract syntax is coupled XMI. Diagram interchange has a ways to go, and I don't know if its going to address parsing text. There's also a possibility of having some text notation for UML. Interoperability and interchange are most effected by the metamodel, so that's a good place to start for compliance. There are also likely to be lots of variation in diagrams and notation to support domain specific languages. Maybe we should defer notation and semantics compliance for a subsequent RTF. "Karl Frank" 08/14/2004 10:31 AM To Jim Amsden/Raleigh/IBM@IBMUS cc "Branislav Selic" , "Pete Rivett" , Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic OK, I am agreeable to the proposal to have Level 0 be defined as proposed in the circulated resolution, as modifed in response to Pete's issue about naming confusion (just use Level numbers as the identifiers for compliance points, no names such as "basic"). Pete still has an issue with respect to conformance of diagrams to the abstract syntax, which I do not recall as being adequately addressed yet by any proposed modification of the proposed resolution. Limitations on concrete notation is surely what the abstract syntax is meant to impose on diagrams, as Pete explains. Has Pete's point been addressed in an email I missed? If so, I think we have a good proposal for resolving the compliance issue. - Karl -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, August 14, 2004 9:57 AM To: Karl Frank Cc: Branislav Selic; Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Karl, I doubt anyone will much care that Basic is defined in InfrastructureLibrary and not Superstructure. The users of UML will likely be reading books and product literature, not the specifations. And if they do, they might read them both since their both from OMG. In any case, we're not talking about MOF, InfrastructureLibrary, or Superstructure, we're talking about UML2 and how to best move the industry forward. I know of no particular bias towards Java. IBM uses EMF (EMOF/Basic) for modeling all sorts of things that aren't Java, but also including J2EE and Java. I'm just looking for something that can establish minimal interoperability and interchange, something we don't have now, of model elements that are (to repeat myself) well understood, easily implemented, and have proven value through common practice. "Karl Frank" 08/14/2004 09:40 AM To Jim Amsden/Raleigh/IBM@IBMUS cc "Branislav Selic" , "Pete Rivett" , Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic Don't get me wrong. I am an admirer of Basic. It is one of the cleanest best thought out parts of UML 2. For one thing, Basic's definition of Data Type declares that datatypes are identfiable. ;-) The real need is to counter Pete's question: Why should the Superstructure define a compliance level in terms of what is not defined in the superstructure? My answer is that the UML name has better market recognition than MOF, so it will be useful to UML users and vendors to have the Superstructure validate compliance with Basic as a form of UML 2 compliance. In challenging Bran's arguments, I am looking for forthright reasons why the Superstructure should define a compliance level by reference to something that is only included by reference in the Superstructure spec; I guess you Java guys think inclusion by reference is better than inclusion by value, but the reasons given initially were not convincing. I think the forthright reason is the marketing reason I gave above. Now, if I understand rightly, you are arguing that Infrastructure Basic is superior to Superstructure Kernel because Kernel is already too complicated. That is convinging to me, and quite different from arguing that Kernel isn't useful, despite the fact that it merges Constructs which already includes Basic. Kernel + Dependencies, my choice for a simplified UML L 0 may indeed be too complex. Kernel has n-ary associations, it has parameter direction kind. These are reasons for saying a more lightweight UML compliance point will be useful. I suspect an unstated reason for advocating Infrastructure Basic has to do with industry strategy relating to Java. - Karl -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Saturday, August 14, 2004 7:13 AM To: Karl Frank Cc: Branislav Selic; Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Karl, Basic is just as much part of UML2 super as it is MOF, so there's no reason Basic alone couldn't be a super compliance point. The primary reason for L0 is to ensure tool vendors can easily claim compliance to something. In the past, the barrier to entry for UML was high. UML2 will make it even higher, even just implementing Kernel completely. As a result, there was little interchange between tools. (Of course there are other reasons for this too - including the informality and interpretation of the spec). What we're hoping for is that by providing UML2 compliance level L0 that only includes Basic, we will be able to AT LEAST get interchange of simple structural models built using modeling concepts that are well understood, easily implemented, and with proven value through common practice. This seems like a good place to start to grow interoperability and interchange from where we are today. L1 adds to that by including behavior resulting a metamodel that is sufficiently computationally complete to be executable and translatable to other platform models. "Karl Frank" 08/13/2004 10:40 PM To "Branislav Selic" cc "Pete Rivett" , Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic Agreed that Kernel and Dependencies are a much better choice than Kernel alone for Level 0. To be blunt, such a very simple version of UML 2 would, contrary to what you argue, be useful cause it would be a competitor to the even more simple metamodel that Microsoft will be advocating, but is (unlike the proposed resolution) a UML 2 Superstructure compliance point. Constructs merges Basic, and your argument is that Infrastructure Basic by itself is more useful than Superstructure Kernel which merges Constructs?. Sounds like the mantra "More is Less" turned around, so "Less is More". Or has the Infra FTF turned these packages around completely? What am I missing here? I also don't get it that Java devleopers are the main users. My perception is that the more mature DoD and such are much heavier users of UML that the Java world, and they do a lot of C++ etc. Finally, the objective of having EMF modelling be possible in compliance with UML 2 is still possible with a compliance point defined by reference to the UML 2 spec, at the expense of having it include just a little more than EMF supports. Just don't ues the part that is not needed? - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, August 13, 2004 10:18 AM To: Karl Frank Cc: Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Kernel by itself is not very useful (e.g., it does not even have dependencies or interfaces). I doubt if it would have many adherents. Strangely enough, as I explained in my response to Pete, the proposed Basic by itself is much more meaningful. So, in my view, we either get rid of L0 altogether or leave it the way it is. Bran "Karl Frank" 08/13/2004 09:50 AM To "Pete Rivett" , Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Compliance section reissue - let's avoid naoming confusion re Basic to voice support for making the changes Pete suggest. Hear! Hear! A specific way to satisfy his request wrt both 1 and 2: In place of the proposal that "level 0" be defined by reference to the Infrastructure Basic, I propose level 0 of UML superstructure compliance should be defined by reference to the Superstructure Kernel package, which is a proper UML 2 modeling capability but a subset of the current proposed level 1. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, August 13, 2004 9:03 AM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: RE: Compliance section reissue - let's avoid naoming confusion re Basic Sorry these are late in the day for this draft - but in my defense I have made the 1st 2 substantive points several times before. Substantive comments: 1. I think it's daft to have a Level called 'Basic' which is nothing to do with the package called Basic! Especially when we do have a level virtually identical to the package Basic which is called something else - Core. 2. it seems odd to have Core (equivalent to EMOF) as a compliance level for Superstructure since it represents nothing at all in Superstructure - the most 'primitive' level in Superstructure is Kernel: it seems we should have that as the lowest compliance level. MOF and Infra will have their own compliance levels for which the levels proposed as Core would more naturally fit. (For completeness Core must be included in section 1.4 - though that would show up how little relationship it has to Superstructure!). 3. Section 1.3: last para: the reference to UML Design Interchange should be to UML 2 Diagram Interchange. There is a technical problem I think with the definition of concrete syntax compliance with reference to the DI standard - since the DI metamodel has a mandatory reference from a graphic element to a model element (via an intermediate Bridge class). hence it is not possible to exchange notation only using DI without also having a model to refer to. So as far as I see, as stated stated the concrete syntax compliance definition does not meet the declared aim. 4. Following on from our lengthy discussion about reuse of the same namespace we still do need to have a name for formally referring to "the uml that merges in packages to form the Intermediate level of compliance": this will, for example, form the basis for naming the XML Schema for validating model interchanges for compliance at that level. 5. Why use 'uml' and not the more expected 'UML' - by convention all package names have an initial capital letter at least Editorial/minor comments: In 1.2 it would be better to have a better summary explanation of the capabilities provided by level L2 than 'adds some additional capabilities'. NB there is a typo 'Intermeideiate' First sentence of document states that "This means that a tool at a given level of compliance is able to interchange models with a tool at the same or higher level of compliance" - however the chapter later states that tools could be compliant at concrete syntax level only without the model interchange capability. Section 1.1 has "The modeling concepts of UML are grouped into capability sets, or, simply, capabilities.". I really don't think we need need 2 quite different terms referring to the same thing - especially given that different parts of the chapter use different ones (e.g. 1.3 uses capability whereas 1.4 uses capability set). I flailed around for a while to try to discover how the 2 concepts were related until I found the sentence in 1.1 saying they were the same thing! Given that compliance points are defined purely in terms of specific packages, I think we need a bit more justification for the concept of capabilities at all in terms of the compliance discussion: is it merely so that instead of claiming compliance to anything, vendors can claim they 'support' some capabilities? First para of 1.3 has "underlying concepts in lower levels that are required by that capability.": I think the concept of a concept 'requiring' other concepts should be made less fuzzy since that's not something defined in the specification. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 12, 2004 5:07 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Compliance section reissue Based on Cris' feedback, I have clarified and strengthened the portions of the text that describe the meaning of compliance and compliance levels. The very first paragraph has been modified and section 1.3 that talks about the meaning and forms of compliance has been rewritten. Hopefully this is no longer ambiguous. Thanks, Bran To: uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org Subject: Consolidated compliance section proposal X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 19 Aug 2004 23:31:20 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/19/2004 23:31:21 I have merged in a number of inputs from various FTF members and produced the consolidated proposal attached below. Of course, as is usally the case in the FTF, I had to trade off a number of essentially conflicting opinions, which, of course, means compromise. Nonetheless, I do feel that all the major concerns from all parties are addressed by this proposal, although I am sure everyone would prefer to change something in it. I do not believe that we will progress any further by extending this discussion (even if we had the time), so my intent is to put this resolution out on a special ballot starting at noon tomorrow. If you have any suggestions about fine-tuning the text, please tell me before then. Because of the exceptional circumstances and the hard deadline imposed by the PTC meeting next week in Montreal, the voting period will be shorter than usual and will finish at 6 PM EDT on Tuesday, August 24. For those who have not been following the discussions here is an explanation: (1) The architecture board has made it clear that it will not accept our revision work until a satisfactory solution is provided to the UML compliance points issues (specifically, an excess of compliance points, ambiguity as to their meaning, and unsuitability for enabling interchange). This proposal is intended to address all those concerns. As I said above, I am pretty sure that it does. (2) OTOH, if we cannot agree on this proposal, then we will need to ask for a postponement of the FTF completion date. This requires approval of the PTC which meets on Friday of next week in Montreal. If we somehow miss that date, we will have to submit what we have on September 30 -- and without a resolution to the compliance problem, our submission will not be accepted. At that point, things become a real procedural mess and everyone loses. If anyone has any questions about the above, please feel free to send me an e-mail or give me a call. My contact information is in the trailer below. Thanks, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com To: uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org Subject: UML compliance section (complete and unexpurgated) -- please read X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 10 Aug 2004 14:41:28 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/10/2004 14:41:29 Attached is the second draft of the compliance section of UML 2. I got rid of some of the waffle wording and ambiguities in the first version that were pointed out to me. I have also tried my best to provide a wording that accommodates the reality of today's divergent tools without sacrificing the whole concept of conformance. Again, I have not rearranged anything in the previously defined compliance levels (although, as I noted, I would like to move Profiles to L1 instead of L2). I realize that some might be uncomfortable about being explicit on this issue (makes it sound like porn, eh?), but I want to remind everyone of the following: The AB has been unequivocal that, until we work the definition of compliance into an acceptable form, the UML spec will not be adopted Users were most unhappy with the definition of compliance in 1.x We debated this issue over many months and had straw polls that finally led to a consensus proposal; that proposal has been soaking for many months and the only thing that this resolution does is propose a concrete wording that captures the consensus So, please read this carefully and provide constructive feedback and/or propose changes that you think will be helpful. Cheers...Bran Compliance.section.addin1.pdf Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 12 Aug 2004 12:12:48 -0700 To: UML Superstructure FTF , MOF UML Infrastructure FTF From: Joaquin Miller Subject: RE: UML compliance section (complete and unexpurgated) -- please read Of course, existing vendors will have difficulty meeting these compliance criteria, at least until they catch up. This is an unpleasant fact that we have been trying to avoid in the past, but which neither the AB nor the market will tolerate any more. Rightly so. In my text, I tried to give the vendors a weasel-wording way out -- at least temporarily -- by suggesting that they can talk about "support for" (but not "compliance with") a given package or set of packages. I can take out this text if the consensus is that I should, but I suspect that not all vendors will be happy with that choice either. X-Change Technologies is not a vendor; we work for and are ourselves users. We urge removing the option to claim "support for." Compliant or not covers the interesting bases. Therefore, theoretically, one can talk about 8 possible kinds of compliance if one takes into account the abstract vs. concrete syntax split. (The decision to separate the latter two forms of compliance was made for the sake of drawing tools such as Visio, which only provide concrete syntax compliance. That decisions, BTW, was also made a long time ago when the consensus was hammered out.) This fits within the range of "less than 10 compliance points" that was the majority opinion voiced in Anaheim. We could also count this as four. I'm sympathetic with tool vendors who would like to, say, supply full state machines, but not activities (other than basic activities), or full activities, but no state machines. But X-Change Technologies does not propose a change at this time, because we've waited far too long, and missed our chance. Unless a member wants to propose extending the deadline for the FTF report, so we can consider an alternate replacement text they will submit, let's vote on the text before us. Cordially, Joaquin Reply-To: From: "Cris Kobryn" To: "'Branislav Selic'" , Cc: , Subject: RE: UML compliance section (complete and unexpurgated) -- please read Date: Wed, 11 Aug 2004 22:07:12 -0700 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcR/CyEaRk4KhArLQOS+SRrMTkznYABGeWcg This revision doesn't address two of the major problems associated with the the UML 1.x version: 1) it leads to an exponential number of compliance combinations; and 2) it remains awkward and confusing to use. Re the exponential number or combinations: Even allowing for the new terminology, there are at least 3 forms of compliance: abstract syntax, concrete syntax and "non-compliance." Given the large number of packages in each layer, and the three forms of compliance, the number of combinations remains exponential. Re awkward and confusing usage: This version inherits all the problems of its predecessor regarding difficulty in defining compliance. Please provide some realistic examples that show how UML 2 implementations and UML 2 profiles can efficiently define their compliance. This issue is critical to Telelogic since our customers are already asking us how our TauG2 UML 2 implementation compares with other UML 2 tools regarding UML 2 standards compliance. In addition, it is also critical to the SysML Partners, who are defining a UML 2 profile for systems engineering applications. Since our approach emphasizes that systems engineers only require a relatively small subset of UML 2 constructs, and we need to be able to define this subset accurately and efficiently. The current proposal needs further discussion and refinement, and is not yet ready to move to a ballot. -- Cris > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Tuesday, August 10, 2004 11:41 AM > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: UML compliance section (complete and unexpurgated) -- please read > > > Attached is the second draft of the compliance section of UML 2. > > I got rid of some of the waffle wording and ambiguities in the first > version that were pointed out to me. I have also tried my best to provide > a wording that accommodates the reality of today's divergent tools without > sacrificing the whole concept of conformance. Again, I have not rearranged > anything in the previously defined compliance levels (although, as I > noted, I would like to move Profiles to L1 instead of L2). > > I realize that some might be uncomfortable about being explicit on this > issue (makes it sound like porn, eh?), but I want to remind everyone of > the following: > > > 1. The AB has been unequivocal that, until we work the definition of > compliance into an acceptable form, the UML spec will not be adopted > 2. Users were most unhappy with the definition of compliance in 1.x > 3. We debated this issue over many months and had straw polls that > finally led to a consensus proposal; that proposal has been soaking for > many months and the only thing that this resolution does is propose a > concrete wording that captures the consensus > > > So, please read this carefully and provide constructive feedback and/or > propose changes that you think will be helpful. > > Cheers...Bran > > To: Cc: "'Branislav Selic'" , mu2i-ftf@omg.org, sysml@yahoogroups.com, uml2-superstructure-ftf@omg.org Subject: RE: UML compliance section (complete and unexpurgated) -- please read X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Thu, 12 Aug 2004 08:57:28 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/12/2004 06:57:31, Serialize complete at 08/12/2004 06:57:31 Cris, Thanks for giving this such a thorough review. I'll attempt to address you concerns in-line below. "Cris Kobryn" wrote on 08/12/2004 01:07:12 AM: > This revision doesn't address two of the major problems associated with the > the UML 1.x version: 1) it leads to an exponential number of compliance > combinations; and 2) it remains awkward and confusing to use. > > Re the exponential number or combinations: Even allowing for the new > terminology, there are at least 3 forms of compliance: abstract syntax, > concrete syntax and "non-compliance." Given the large number of packages in > each layer, and the three forms of compliance, the number of combinations > remains exponential. > Non-compliance is not a very interesting dimension of compliance since it sets no predictable expectations. There are only 4 compliance levels, L0 (EMOF), L1 (Basic), L2 (Intermediate), and L3 (complete). For each compliance level, a vendor can comply with the metamodel, the notation, or both. This doesn't seem either overly complicated, or that many choices. The number of packages in each compliance level does not contribute to the number of choices as each level explicitly specifies the packages included and how. > Re awkward and confusing usage: This version inherits all the problems of > its predecessor regarding difficulty in defining compliance. Please provide > some realistic examples that show how UML 2 implementations and UML 2 > profiles can efficiently define their compliance. > I'm not sure I understand the problem. Each compliance level is defined as a set of model elements and their corresponding notation. A vendor's tool supports creating instances of those model elements and exchanging them using XMI for the compliance level, and/or supports the UML notation for those model elements. EMF (www.eclipse.org) is an example of a tool that supports L0. The eclipse UML2 project is an example of an API that supports L3 (subject to updates resulting from changes in the spec). Not sure what you mean by profiles efficiently defining their compliance. UML2 profiles are not involved in the specification of the UML2 compliance levels. I suspect that industry and standard profiles will emerge to customize UML2 for specific domains or markings for MDA transformation. Conformance to those profiles should be simply applying them to the model. Now verifying compliance is another matter, and one that should be addressed at some point. There are a number of ways this could be done including published test suites (XMI documents) or a reference implementation. But tools can verify compliance to the metamodel by using the XMI document defining the compliance level to validate their implementation. Notation would be more difficult as we don't have standard document interchange yet, or any effective way to parse pictures. > This issue is critical to Telelogic since our customers are already asking > us how our TauG2 UML 2 implementation compares with other UML 2 tools > regarding UML 2 standards compliance. > It's critical to IBM too, and I suspect to all vendors who want to engage in a broader MDA community. > In addition, it is also critical to the SysML Partners, who are defining a > UML 2 profile for systems engineering applications. Since our approach > emphasizes that systems engineers only require a relatively small subset of > UML 2 constructs, and we need to be able to define this subset accurately > and efficiently. > SysML can define whatever subset it wants. There is no requirement to adhear to any UML2 compliance level. However, SysML may benefit from using one of the compliance levels as a starting point and then extend it as necessary. As a result, SysML can claim conformance to that compliance level, as well as advertise its extensions. Recall that conformance to a compliance level does not require the tool to only implement the capabilities of that compliance level. It must implement at least those capabilities, but is free to implement more, including other capabilities defined in UML2 but not included in the compliance level, as well as other new capabilities. The tool advertises the supported compliance level and any additional capabilities it provides. > The current proposal needs further discussion and refinement, and is not yet > ready to move to a ballot. > Let me know if you have further concerns and I'll do my best to address them. > -- Cris > > > > > > -----Original Message----- > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > Sent: Tuesday, August 10, 2004 11:41 AM > > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > > Subject: UML compliance section (complete and unexpurgated) -- please read > > > > > > Attached is the second draft of the compliance section of UML 2. > > > > I got rid of some of the waffle wording and ambiguities in the first > > version that were pointed out to me. I have also tried my best to provide > > a wording that accommodates the reality of today's divergent tools without > > sacrificing the whole concept of conformance. Again, I have not rearranged > > anything in the previously defined compliance levels (although, as I > > noted, I would like to move Profiles to L1 instead of L2). > > > > I realize that some might be uncomfortable about being explicit on this > > issue (makes it sound like porn, eh?), but I want to remind everyone of > > the following: > > > > > > 1. The AB has been unequivocal that, until we work the definition of > > compliance into an acceptable form, the UML spec will not be adopted > > 2. Users were most unhappy with the definition of compliance in 1.x > > 3. We debated this issue over many months and had straw polls that > > finally led to a consensus proposal; that proposal has been soaking for > > many months and the only thing that this resolution does is propose a > > concrete wording that captures the consensus > > > > > > So, please read this carefully and provide constructive feedback and/or > > propose changes that you think will be helpful. > > > > Cheers...Bran > > > > > > To: Cc: mu2i-ftf@omg.org, sysml@yahoogroups.com, uml2-superstructure-ftf@omg.org Subject: RE: UML compliance section (complete and unexpurgated) -- please read X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 12 Aug 2004 09:26:48 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/12/2004 09:26:50, Serialize complete at 08/12/2004 09:26:50 Cris, Thanks for the feedback. Clearly, some improvement is needed in the wording of the text because there is a fundamental misunderstanding here. Comments below: > This revision doesn't address two of the major problems associated with the > the UML 1.x version: 1) it leads to an exponential number of compliance > combinations; and 2) it remains awkward and confusing to use. > > Re the exponential number or combinations: Even allowing for the new > terminology, there are at least 3 forms of compliance: abstract syntax, > concrete syntax and "non-compliance." Given the large number of packages in > each layer, and the three forms of compliance, the number of combinations > remains exponential. There are, in fact, only 4 levels of compliance defined: L0, L1, L2, and L3. There is a statement in section 1.3 that says, "compliance to a given compliance level, as defined in this specification, entails full support for all capabilities that are defined as part of that level as well as compliance with all the levels below it." It seems that I should make this statement more prominent -- possibly by moving it to the front of the section and wording it more strongly. This means that a vendor that supports 9 out of 10 packages of a given level (e.g., does not implement InformationFlows at the Complete Level) cannot claim compliance. Of course, existing vendors will have difficulty meeting these compliance criteria, at least until they catch up. This is an unpleasant fact that we have been trying to avoid in the past, but which neither the AB nor the market will tolerate any more. In my text, I tried to give the vendors a weasel-wording way out -- at least temporarily -- by suggesting that they can talk about "support for" (but not "compliance with") a given package or set of packages. I can take out this text if the consensus is that I should, but I suspect that not all vendors will be happy with that choice either. Therefore, theoretically, one can talk about 8 possible kinds of compliance if one takes into account the abstract vs. concrete syntax split. (The decision to separate the latter two forms of compliance was made for the sake of drawing tools such as Visio, which only provide concrete syntax compliance. That decisions, BTW, was also made a long time ago when the consensus was hammered out.) This fits within the range of "less than 10 compliance points" that was the majority opinion voiced in Anaheim. > Re awkward and confusing usage: This version inherits all the problems of > its predecessor regarding difficulty in defining compliance. Please provide > some realistic examples that show how UML 2 implementations and UML 2 > profiles can efficiently define their compliance. > > This issue is critical to Telelogic since our customers are already asking > us how our TauG2 UML 2 implementation compares with other UML 2 tools > regarding UML 2 standards compliance. I hope that the above clears up the misunderstanding. I will modify the resolution accordingly. Any suggestions on how to do this are also welcome. > In addition, it is also critical to the SysML Partners, who are defining a > UML 2 profile for systems engineering applications. Since our approach > emphasizes that systems engineers only require a relatively small subset of > UML 2 constructs, and we need to be able to define this subset accurately > and efficiently. BTW, I have the latest version of the SysML spec, and from what I understand, SysML is not a profile of UML since it has its own metamodel. This means that one cannot expect a UML compliant tool to deal with SysML (NB: it may be a good idea to define a compliance level of SysML that is consistent with UML). So, I am not sure that the definition of UML compliance points will be particularly relevant to SysML. > The current proposal needs further discussion and refinement, and is not yet > ready to move to a ballot. I will add the clarifications and reissue the text. However, since it is only a question of clarification and not of substance, I see no reason to exclude the resolution from ballot 23. Given the imminent deadline and the fact that the proposal has been soaking for months now, I do not feel that it is appropriate to re-open discussion on this issue. There was plenty of opportunity to do that in the past. What is needed at this point is for the FTF to make a decision by voting. Regards...Bran Reply-To: From: "Cris Kobryn" To: "'Branislav Selic'" , Cc: , Subject: RE: UML compliance section (complete and unexpurgated) -- please read Date: Thu, 12 Aug 2004 11:27:53 -0700 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSAcTfbI8iPey+ITRGNxM4K6PeH1QAIeMwg > Thanks for the feedback. Clearly, some improvement is needed in the > wording of the text because there is a fundamental misunderstanding here. > Comments below: > ... > There are, in fact, only 4 levels of compliance defined: L0, L1, L2, and > L3. There is a statement in section 1.3 that says, "compliance to a given > compliance level, as defined in this specification, entails full support > for all capabilities that are defined as part of that level as well as > compliance with all the levels below it." It seems that I should make this > statement more prominent -- possibly by moving it to the front of the > section and wording it more strongly. > > This means that a vendor that supports 9 out of 10 packages of a given > level (e.g., does not implement InformationFlows at the Complete Level) > cannot claim compliance. > > Of course, existing vendors will have difficulty meeting these compliance > criteria, at least until they catch up. It will not only be difficult, the proposed changes will make it practically impossible for vendors serious about implementing major enhancements to UML 2 (such as Composite Structure diagrams) to claim compliance past Basic Level (L1). On the other hand, many UML 1.x vendors not serious about implementing major enhancements to UML 2 will be able to re-label their old UML 1.x wares as "UML 2 Basic Level" compliant. This will only increase confusion in the marketplace. Such an impractical proposal, where no vendor can realistically claim compliance with the spec past L1 and which leads to increased confusion in the marketplace makes a poor situation worse, not better. It is a major change to the Final Adopted Specification (FAS), which will not work for us as a vendor nor will it work for us as a SysML Partner defining a UML 2 profile. We are fine with making Basic Level (L1) compliance monolithic, as is the case with Core Level (L0), but this needs to be explained much more clearly in the spec, which is currently confusing. Once again, we recommend that examples be added to the revision to minimize confusion in an area that has been historically befuddling. However, treating Intermediate (L2) and Complete (L3) levels as monolithic regarding compliance is unacceptable, since we as vendor, and we as a SysML Partner have a real need to define partial compliance with a subset of L2 and L3 packages. We strongly oppose any changes to the FAS compliance that preclude us from being able to do this. -- Cris Subject: RE: UML compliance section (complete and unexpurgated) -- please read Date: Thu, 12 Aug 2004 12:26:44 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML compliance section (complete and unexpurgated) -- please read Thread-Index: AcSAcTfbI8iPey+ITRGNxM4K6PeH1QAIeMwgAALse6A= From: "Karl Frank" To: , "Branislav Selic" , Cc: , X-OriginalArrivalTime: 12 Aug 2004 19:26:41.0253 (UTC) FILETIME=[4B798950:01C480A2] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7CJdilj006875 Cris, I'm not saying you're wrong, I'm saying that I don't intuit the reasoning behind your statements. Could you expand? 1. "...will be able to re-label their old UML 1.x wares as "UML 2 Basic Level" compliant." How so? The abstract syntax of UML 2 is markedly different from 1.x It seems to follow that a UML 1.x modeling tool would not conform. Could you explain how the difference in syntax fails to bar UML 1.x tools from claiming conformance? 2. "... make it practically impossible for vendors serious about implementing major enhancements to UML [to meet these compliance criteria]" "...no vendor can realistically claim compliance with the spec past L1" Why? Do you mean cannot NOW (August 2004) claim compliance, or do you mean never? - Karl -----Original Message----- From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] Sent: Thursday, August 12, 2004 2:28 PM To: 'Branislav Selic'; uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org; sysml@yahoogroups.com Subject: RE: UML compliance section (complete and unexpurgated) -- please read > Thanks for the feedback. Clearly, some improvement is needed in the > wording of the text because there is a fundamental misunderstanding here. > Comments below: > ... > There are, in fact, only 4 levels of compliance defined: L0, L1, L2, > and L3. There is a statement in section 1.3 that says, "compliance to > a given compliance level, as defined in this specification, entails > full support for all capabilities that are defined as part of that > level as well as compliance with all the levels below it." It seems > that I should make this statement more prominent -- possibly by moving > it to the front of the section and wording it more strongly. > > This means that a vendor that supports 9 out of 10 packages of a given > level (e.g., does not implement InformationFlows at the Complete > Level) cannot claim compliance. > > Of course, existing vendors will have difficulty meeting these > compliance criteria, at least until they catch up. It will not only be difficult, the proposed changes will make it practically impossible for vendors serious about implementing major enhancements to UML 2 (such as Composite Structure diagrams) to claim compliance past Basic Level (L1). On the other hand, many UML 1.x vendors not serious about implementing major enhancements to UML 2 will be able to re-label their old UML 1.x wares as "UML 2 Basic Level" compliant. This will only increase confusion in the marketplace. Such an impractical proposal, where no vendor can realistically claim compliance with the spec past L1 and which leads to increased confusion in the marketplace makes a poor situation worse, not better. It is a major change to the Final Adopted Specification (FAS), which will not work for us as a vendor nor will it work for us as a SysML Partner defining a UML 2 profile. We are fine with making Basic Level (L1) compliance monolithic, as is the case with Core Level (L0), but this needs to be explained much more clearly in the spec, which is currently confusing. Once again, we recommend that examples be added to the revision to minimize confusion in an area that has been historically befuddling. However, treating Intermediate (L2) and Complete (L3) levels as monolithic regarding compliance is unacceptable, since we as vendor, and we as a SysML Partner have a real need to define partial compliance with a subset of L2 and L3 packages. We strongly oppose any changes to the FAS compliance that preclude us from being able to do this. -- Cris Reply-To: From: "Conrad Bock" To: , , Subject: RE: UML compliance section (complete and unexpurgated) -- please read Date: Thu, 12 Aug 2004 15:30:38 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, et al, Cris points derive from Thomas' original one: that there is no small set of compliance points that will cover most vendors. Most of the submarkets cut across these compliance points, as they would any small set. The only feasible way of defining useful compliance points is by the relations between metaclasses (not packages). Vendors who what to use a particular metaclass obviously need to implement metaclasses related to it via generaliation and mandatory associations and dependencies. I'm assuming: - Vendors will continue to ignore compliance points as they have in the past. - We don't have time to revisit this entire discussion and agree on a new way. So the current draft is about the only thing we can do at this point. Conrad To: Cc: "'Branislav Selic'" , mu2i-ftf@omg.org, sysml@yahoogroups.com, uml2-superstructure-ftf@omg.org Subject: RE: UML compliance section (complete and unexpurgated) -- please read X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Thu, 12 Aug 2004 15:46:00 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/12/2004 13:46:02, Serialize complete at 08/12/2004 13:46:02 Cris, My comments below... "Cris Kobryn" wrote on 08/12/2004 02:27:53 PM: > > Thanks for the feedback. Clearly, some improvement is needed in the > > wording of the text because there is a fundamental misunderstanding here. > > Comments below: > > ... > > There are, in fact, only 4 levels of compliance defined: L0, L1, L2, and > > L3. There is a statement in section 1.3 that says, "compliance to a given > > compliance level, as defined in this specification, entails full support > > for all capabilities that are defined as part of that level as well as > > compliance with all the levels below it." It seems that I should make this > > statement more prominent -- possibly by moving it to the front of the > > section and wording it more strongly. > > > > This means that a vendor that supports 9 out of 10 packages of a given > > level (e.g., does not implement InformationFlows at the Complete Level) > > cannot claim compliance. > > > > Of course, existing vendors will have difficulty meeting these compliance > > criteria, at least until they catch up. > > It will not only be difficult, the proposed changes will make it practically > impossible for vendors serious about implementing major enhancements to UML > 2 (such as Composite Structure diagrams) to claim compliance past Basic > Level (L1). On the other hand, many UML 1.x vendors not serious about > implementing major enhancements to UML 2 will be able to re-label their old > UML 1.x wares as "UML 2 Basic Level" compliant. This will only increase > confusion in the marketplace. > I think the difficulty Bran was refering to is vendors catching up by migrating their tools from UML 1.x to UML 2. They will have to do this regardless of the specified compliance levels. I don't see how a UML 1.x tool could possibly be labeled as "UML2 Basic Level" compliant as the metamodels are different. > Such an impractical proposal, where no vendor can realistically claim > compliance with the spec past L1 and which leads to increased confusion in > the marketplace makes a poor situation worse, not better. It is a major > change to the Final Adopted Specification (FAS), which will not work for us > as a vendor nor will it work for us as a SysML Partner defining a UML 2 > profile. > Eclipse has two projects that are, or soon will be compliant with L0 and L3. Both are in the open source community. So I don't understand how the compliance levels are unrealistic. L1 and L2 were chosen to include capabilities in common practice. I realize this is a compromise that is not likely to satisfy that many vendors. However, compliance at L0 is too low to be useful for much beyond simple structural modeling. It wouldn't for example support model driven development. L3 is probably too much for most vendors, so we can't require everything. So we did the best we could and picked a couple of intermediate points. > We are fine with making Basic Level (L1) compliance monolithic, as is the > case with Core Level (L0), but this needs to be explained much more clearly > in the spec, which is currently confusing. Once again, we recommend that > examples be added to the revision to minimize confusion in an area that has > been historically befuddling. > > However, treating Intermediate (L2) and Complete (L3) levels as monolithic > regarding compliance is unacceptable, since we as vendor, and we as a SysML > Partner have a real need to define partial compliance with a subset of L2 > and L3 packages. We strongly oppose any changes to the FAS compliance that > preclude us from being able to do this. > I'm not sure what you mean by monolithic compliance. A tool is free to implement L1 with additional capabilities from L2 plus its own custom extensions, specified with Profiles, MOF, or any other mechanism. It can claim conformance to L1 and read models from any other L1 compliant tool. It can also advertise its additional capabilities. We don't expect to get complete interoperability between all such tools, only interoberability at the conforming compliance level. This is of course a compromise between interoperability and tool vendor flexibility. In any case, the contents of the compliance levels are substantially the same as originally defined. Do you have any alternative suggestions on how to handle compliance and conformance? > -- Cris > > To: Cc: mu2i-ftf@omg.org, sysml@yahoogroups.com, uml2-superstructure-ftf@omg.org Subject: RE: UML compliance section (complete and unexpurgated) -- please read X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 12 Aug 2004 15:51:57 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/12/2004 15:51:59, Serialize complete at 08/12/2004 15:51:59 Cris, In reply to your e-mail: > > Of course, existing vendors will have difficulty meeting these compliance > > criteria, at least until they catch up. > > It will not only be difficult, the proposed changes will make it practically > impossible for vendors serious about implementing major enhancements to UML > 2 (such as Composite Structure diagrams) to claim compliance past Basic > Level (L1). On the other hand, many UML 1.x vendors not serious about > implementing major enhancements to UML 2 will be able to re-label their old > UML 1.x wares as "UML 2 Basic Level" compliant. This will only increase > confusion in the marketplace. I don't think that is quite accurate. The Basic level includes a variety of UML things that are beyond what is currently in UML 1.x -- including composite structures. So the possibility of UML 1.x vendors claiming compliance is practically nil. Confusion in the marketplace is indeed a problem, and this resolution is formulated precisely to deal with that by (a) stating unequivocally what compliance means and (b) by reducing the concept to something that is both useful and manageable. Compliance is no longer a matter of interpretation as it was in 1.x. We have to be frank that this latter strategy was driven by the vendors and definitely not the users. It would be wrong both morally and practically to retain that situation. > Such an impractical proposal, where no vendor can realistically claim > compliance with the spec past L1 Actually, no vendor can even claim compliance to L1. This is one of the things that I think is good about this proposal: it favors no vendor. > and which leads to increased confusion in > the marketplace makes a poor situation worse, not better. It is a major > change to the Final Adopted Specification (FAS), which will not work for us > as a vendor nor will it work for us as a SysML Partner defining a UML 2 > profile. I repeat my statement from earlier: SysML is not a UML profile from what I have seen. It reuses certain features from all the different levels of UML. While it might be possible to reorganize the compliance levels to suit SysML, it is a sure bet that such a scheme would not be sutiable for everyone else. > We are fine with making Basic Level (L1) compliance monolithic, as is the > case with Core Level (L0), but this needs to be explained much more clearly > in the spec, which is currently confusing. Once again, we recommend that > examples be added to the revision to minimize confusion in an area that has > been historically befuddling. The reasons it has been historically befuddling are: (1) as you pointed out before, the number of compliance points was so vast that it made interchange impossible (2) there was no clear cut definition of what compliance means -- there is one now. Of course if you can suggest concrete improvements to the present definition, those would be much appreciated. > However, treating Intermediate (L2) and Complete (L3) levels as monolithic > regarding compliance is unacceptable, since we as vendor, and we as a SysML > Partner have a real need to define partial compliance with a subset of L2 > and L3 packages. We strongly oppose any changes to the FAS compliance that > preclude us from being able to do this. Partial compliance is a non-starter; that was noted during the very first review by the AB. Concerning the "configurability" of levels 2 and 3, we know very well from experience, that with 14 different capability areas (many with additional "sub-capabilities"), three different levels, two dimensions of compliance, and 17 vendors, we will absolutely never be able to come up with a configuration of groupings of capabilities that will make all the vendors happy (or even a minority of vendors, for that matter). Therefore, realistically speaking, this too is a non-starter. But, this is not supposed to be about vendors but about users. They may or may not be sympathetic to the vendors' plight, but they are undoubtedly much more concerned about their own problems in exchanging UML models. If they want UML to succeed, the vendors will all have to bite the bullet and do what is right for the user. So, again, if you have concrete suggestions on how to improve the text, please provide them to me. At this stage, however, it is too late to reopen the discussion. There was plenty of time to do that before and now it is time to vote. For those who actively participated in the dicussions the course of action recommended in this resolution was the only one they found feasible, despite the obvious pain it inflicts. Regards, Bran To: Cc: mu2i-ftf@omg.org, sysml@yahoogroups.com, uml2-superstructure-ftf@omg.org Subject: RE: UML compliance section (complete and unexpurgated) -- please read X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Thu, 12 Aug 2004 16:06:20 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/12/2004 14:06:22, Serialize complete at 08/12/2004 14:06:22 Conrad, We anticipated these issues when coming up with the compliance recommendations. What we're trying to do is maximize tool interchange and interoperability while at the same time maximizing tool flexibility. These are of course conflicting goals, so compromise is the only solution unless we drop one or the other. We get maximum interchange and interoperability by setting an expectation about what specifically can be exchanged through the definition of the compliance levels. We get maximum tool flexibility by allowing a tool to implement more capabilities than those specified for a given compliance level, including capabilities that are not defined in UML2. Such a tool can only claim conformance to the supported compliance level, but is free to implement anything else it needs. Then tools will always be able to at least interchange model elements contained in the compliance levels they conform to. That's much better than what we have now. However, it doesn't say what a tool should do with model elements it doesn't understand. We discussed this at various meetings and telecons, and as I recall determined the best we could do is adopt the XML extensibility style. Tools at least ignore model elements they don't understand, and at best don't throw them away on load and save. We didn't make this a normative rule, but rather a suggested practice to maximize both interchange and tool flexibility. "Conrad Bock" 08/12/2004 03:30 PM Please respond to conrad.bock To , , cc Subject RE: UML compliance section (complete and unexpurgated) -- please read Bran, et al, Cris points derive from Thomas' original one: that there is no small set of compliance points that will cover most vendors. Most of the submarkets cut across these compliance points, as they would any small set. The only feasible way of defining useful compliance points is by the relations between metaclasses (not packages). Vendors who what to use a particular metaclass obviously need to implement metaclasses related to it via generaliation and mandatory associations and dependencies. I'm assuming: - Vendors will continue to ignore compliance points as they have in the past. - We don't have time to revisit this entire discussion and agree on a new way. So the current draft is about the only thing we can do at this point. Conrad Reply-To: From: "Cris Kobryn" To: , Cc: , Subject: RE: UML compliance section (complete and unexpurgated) -- please read Date: Thu, 12 Aug 2004 13:16:50 -0700 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSAo+yO2m3pxjkATEKM/UcI03euYAAA/F8g > The only feasible way of defining useful compliance points is by the > relations between metaclasses (not packages). Vendors who what to use a > particular metaclass obviously need to implement metaclasses related to > it via generaliation and mandatory associations and dependencies. > > I'm assuming: > > - Vendors will continue to ignore compliance points as they have in > the past. Your cynicism reinforces my previous point about the impracticality of the new proposal. Telelogic and our customers do not want to ignore compliance points, since we consider them useful in distinguishing our UML2 implementations from those of our competitors. My assumption here was different, namely that we were sincerely trying to significantly improve the current compliance scheme. Otherwise why make a change at all? > - We don't have time to revisit this entire discussion and agree on a > new way. > > So the current draft is about the only thing we can do at this point. It doesn't follow that this is the only solution, since we always have the option of cleaning up the current version, which is backward compatible with UML 1.x and was voted upon by the PTC in our open process. -- Cris To: Cc: mu2i-ftf@omg.org, sysml@yahoogroups.com, uml2-superstructure-ftf@omg.org Subject: RE: UML compliance section (complete and unexpurgated) -- please read X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 12 Aug 2004 16:26:17 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/12/2004 16:26:20, Serialize complete at 08/12/2004 16:26:20 Conrad, You wrote: > I'm assuming: > > - Vendors will continue to ignore compliance points as they have in > the past. I really don't think they will be able to evade this issue as they could before, because the definition of compliance is much more specific. Their users (and, equally likely, their competitors) can now point them to the definition in the spec and ask them very concrete questions whether they support feature X of capability Y at level Z, because X,Y,and Z are now all explicitly identified as being part of a compliance level. The full metamodel is covered and everything in that metamodel is given a placement in one of the 4 compliance levels. Most importantly, with the removal of "partial" compliance as a formal notion, compliance is now a Boolean predicate. Vendors will have no choice but to move to compliant implementations, their customers will force them. The next step, of course, is to provide compliance verification suites. With the new definition, this is now quite feasible -- it was practically impossible before. > - We don't have time to revisit this entire discussion and agree on a > new way. > > So the current draft is about the only thing we can do at this > point. I would like to think that it is more than just "the only thing", but one that was worked out very carefully with the intrest of users being paramount. Cheers...Bran To: Cc: mu2i-ftf@omg.org, sysml@yahoogroups.com, uml2-superstructure-ftf@omg.org Subject: RE: UML compliance section (complete and unexpurgated) -- please read X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 12 Aug 2004 16:26:17 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/12/2004 16:26:20, Serialize complete at 08/12/2004 16:26:20 Conrad, You wrote: > I'm assuming: > > - Vendors will continue to ignore compliance points as they have in > the past. I really don't think they will be able to evade this issue as they could before, because the definition of compliance is much more specific. Their users (and, equally likely, their competitors) can now point them to the definition in the spec and ask them very concrete questions whether they support feature X of capability Y at level Z, because X,Y,and Z are now all explicitly identified as being part of a compliance level. The full metamodel is covered and everything in that metamodel is given a placement in one of the 4 compliance levels. Most importantly, with the removal of "partial" compliance as a formal notion, compliance is now a Boolean predicate. Vendors will have no choice but to move to compliant implementations, their customers will force them. The next step, of course, is to provide compliance verification suites. With the new definition, this is now quite feasible -- it was practically impossible before. > - We don't have time to revisit this entire discussion and agree on a > new way. > > So the current draft is about the only thing we can do at this > point. I would like to think that it is more than just "the only thing", but one that was worked out very carefully with the intrest of users being paramount. Cheers...Bran Compliance.section.addin.040819.pdf