Issue 7568: Rename the specification to OMG Diagram Interchange Specification (uml2di-ftf) Source: Adaptive (Mr. Pete Rivett, pete.rivett@adaptive.com) Nature: Uncategorized Issue Severity: Summary: The current title of the document reflects the original RFP but is far too specific for the standard produced and unnecessarily limits how people may think it can be applied. Proposed resolution: Rename the specification to OMG Diagram Interchange Specification Resolution: Revised Text: Actions taken: July 7, 2004: received issue November 1, 2005: closed issue Discussion: The scope of the specification is UML 2.0 and the title should represent this scope. Therefore the title should not be changed to a title which excludes this scope. Disposition: Closed, no change has to be made End of Annotations:===== ubject: Issue for UML2 Diagram Interchange FTF Date: Thu, 8 Jul 2004 05:47:17 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue for UML2 Diagram Interchange FTF Thread-Index: AcRkz206f6+POFEKTi+lJ9KVrcQvqQ== From: "Pete Rivett" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i689kllj017859 The current title of the document reflects the original RFP but is far too specific for the standard produced and unnecessarily limits how people may think it can be applied. Proposed resolution: Rename the specification to OMG Diagram Interchange 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 From: "Marko Boger" To: "'Edwin Seidewitz'" , , , Cc: Subject: AW: Compliance points - Diagram Interchange. Date: Mon, 23 Aug 2004 10:24:45 +0200 X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7N8cglj008949 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: "Marko Boger" Cc: "'Edwin Seidewitz'" , mu2i-ftf@omg.org, ocl2-ftf@omg.org, uml2-superstructure-ftf@omg.org, uml2di-ftf@omg.org Subject: Re: AW: Compliance points - Diagram Interchange. X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 23 Aug 2004 07:44:57 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/23/2004 07:45:00, Serialize complete at 08/23/2004 07:45:00 Marko, In fact, you seem to be arguing that the spec should not even be referred to as a UML spec, but, perhaps, as a spec with a greater scope. This certainly sounds like an issue that needs to be discussed further. I suggest you raise an official issue to "issues@omg.org". Regards, Bran "Marko Boger" 08/23/2004 04:24 AM To "'Edwin Seidewitz'" , , , cc 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 > > > > > > > > > > > > > > > > > > > > > > > > Subject: RE: AW: Compliance points - Diagram Interchange. Date: Mon, 23 Aug 2004 09:00:05 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: Compliance points - Diagram Interchange. Thread-Index: AcSJC7kwmsAHP3xiSDOYUXeoxGyeXQAA9NOQ From: "Pete Rivett" To: "Branislav Selic" , "Marko Boger" Cc: "Edwin Seidewitz" , , , , X-Virus-Scanned: by amavisd-new at sentraliant.com I raised the issue some time ago - it's 7568 which is as follows: Issue 7568: Rename the specification to OMG Diagram Interchange Specification (uml2di-ftf) Click here for this issue's archive. Source: Adaptive Ltd. (Mr. Pete Rivett, pete.rivett@adaptive.com) Nature: Uncategorized Issue Severity: Summary: The current title of the document reflects the original RFP but is far too specific for the standard produced and unnecessarily limits how people may think it can be applied. Proposed resolution: Rename the specification to OMG Diagram Interchange 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: Monday, August 23, 2004 7:45 AM To: Marko Boger Cc: 'Edwin Seidewitz'; mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org; uml2di-ftf@omg.org Subject: Re: AW: Compliance points - Diagram Interchange. Marko, In fact, you seem to be arguing that the spec should not even be referred to as a UML spec, but, perhaps, as a spec with a greater scope. This certainly sounds like an issue that needs to be discussed further. I suggest you raise an official issue to "issues@omg.org". Regards, Bran "Marko Boger" 08/23/2004 04:24 AM To "'Edwin Seidewitz'" , , , cc 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 > > > > > > > > > > > > > > > > > > > > > > > > Subject: RE: Ballot 2 Proposal Date: Thu, 30 Sep 2004 01:47:03 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 2 Proposal Thread-Index: AcSmUR+RwwrPMnfeQ62Ps6oiXuMdbwASPC4Q From: "Pete Rivett" To: "Marko Boger" , X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i8U5rF1U018175 My main concern is the lack of updates to bring the spec up to UML2: for example the Nesting Guide (apparently agreed in Ballot 1 despite my NO vote) is explicitly UML 1.4 only. And the spec is still littered with statements such as para 2 of 6.1 "A more detailed evaluation of whether all the aspects of UML 2.0 have been taken into account is needed. However, this can only be done after UML 2.0 has been stabilized. In the current version, UML 1.4, XMI 1.2, and MOF 1.4 are used. It should not be very difficult to finalize this specification to use UML 2.0, XMI 2.1, and MOF 2.0." Also DI still uses Double despite the fact that AFAIK MOF/UML has not defined such a primitive type (it would be sensible for Infra to do so) nor has DI itself . Ironically the discussion for 7568 says "The scope of the specification is UML 2.0 and the title should represent this scope. Therefore the title should not be changed to a title which exclude this scope." I disagree with this: taking 'UML 2.0' out of the title by no means excludes UML 2: it does however avoid unnecessarily excluding other people who could use DI (for example Adaptive is already successfully using DI for process diagrams mapped to a proprietary metamodel). Moreover the metamodel includes an explicit class UML1SemanticModelBridge which clearly is outside the scope of UML2. I think 7305 could use some text being added in the document. The discussion of 7663 refers to the new Nesting Guide added in Ballot 1 as the only response to the issue whose main point is the lack of coverage of UML 2.0. This is an utterly inadequate response since that Nesting Guide covers ONLY UML 1.4!! Issue '????' (that adds the XML Schema) also needs to include editing instructions to specify how the XMI Schema should be inserted/referred to from the document (it should be a separate file in which case it could be properly checked). Even more important than the schema, the specification requires a MOF 2 XMI file which is the normative definition of the metamodel and from which the Schema (should have) been generated according to the XMI 2.1 rules. The Schema has a very strange and syntactically incorrect (includes 'http:///') namespace declaration: one point of namespace prefixes is to make representations more compact so a prefix of "org.omg.uml2.diagram_interchange" seems very odd and inconsistent with all other XMI-based standards. Also it does not use the correct xmlns format which should start http://schema.omg.org/spec - this is documented in document omg/02-03-02. I suggest the following: xmlns:DI="http://schema.omg.org/spec/DI/1.0" targetNamespace="http://schema.omg.org/spec/DI/1.0" The URI for XMI is also wrong and should be: xmlns:XMI="http://schema.omg.org/spec/XMI/2.1" The Schema seems odd in having the XML attributes of quite a different type from the elements for the same property: for example, for BezierPoint we have: This also begs the point as to how the complex type Point is supposed to be rendered in some form of structured text if the attribute option is used. Moreover this does not represent the XMI 2.1 rules for referencing objects: see 7.8.5 of ptc/04-06-11. 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: Marko Boger [mailto:marko.boger@gentleware.com] Sent: Wednesday, September 29, 2004 2:09 PM To: uml2di-ftf@omg.org Subject: Ballot 2 Proposal Hello everyone, the FTFs are coming to an end. Attached I am sending you a proposal for Ballot 2. Also I am attaching the schema we generated for the DI and the latest version of the model itself as wmf-file. Please let us know your thoughts. We hope to start the voting process on Friday of this week. Best 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 Subject: RE: [UML Diagram Interchange] Ballot 3 -- *** please vote ASAP - closes June 5 - thanks *** Date: Thu, 2 Jun 2005 23:38:24 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [UML Diagram Interchange] Ballot 3 -- *** please vote ASAP - closes June 5 - thanks *** Thread-Index: AcVnOQapeaEBlZZSTVOeil2OuecEowAsFy+A From: "Pete Rivett" To: "Manfred R. Koethe" , X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j533SDhh016415 Adaptive votes YES to all the issues except 7568 and 7788 to which it votes NO. I objected to these at the time of the original ballot draft put out by Marko (I forwarded this email to Manfred). For 7568 Marko himself agreed in a subsequent email to the DI mailing list that the name change would make sense. He said "I fully agree that DI is applicable to a much wider range of applications than UML 2 (or even UML) and have seen evidence of that in other applications. I am now open to renaming the DI spec from now "UML 2 Diagram Interchange" to "OMG Diagram Interchange". This does match the scope of the spec. My main worry is that vendors might use the renaming as an excuse for not having to implement it. Now that it IS referenced from the compliance points I would be open to changing this, if others agree to this." My objection to 7788 is the quality of the XML Schema proposed - again I provided some detailed comments at the time of the original ballot draft. Here they are again: --> One point of namespace prefixes is to make representations more compact so a prefix of "org.omg.uml2.diagram_interchange" seems very odd and inconsistent with all other XMI-based standards. Also it does not use the correct xmlns format which should start http://schema.omg.org/spec - this is documented in document omg/02-03-02. I suggest the following: xmlns:DI="http://schema.omg.org/spec/DI/1.0" targetNamespace="http://schema.omg.org/spec/DI/1.0" The URI for XMI is also wrong and should be: xmlns:XMI="http://schema.omg.org/spec/XMI/2.1" The Schema seems odd in having the XML attributes of quite a different type from the elements for the same property: for example, for BezierPoint we have: This also begs the point as to how the complex type Point is supposed to be rendered in some form of structured text if the attribute option is used. Moreover this does not represent the XMI 2.1 rules for referencing objects: see 7.8.5 of ptc/04-06-11. --> Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Manfred R. Koethe [mailto:koethe@88solutions.com] > Sent: Thursday, June 02, 2005 6:42 AM > To: uml2di-ftf@omg.org > Subject: [UML Diagram Interchange] Ballot 3 -- *** please > vote ASAP - closes June 5 - thanks *** > > Dear colleagues, > > This is Ballot 3 of the UML Diagram Interchange FTF. > >>> Please note: This is the last chance to close the Diagram- > >>> Interchange FTF, so please vote ASAP > >>> Poll closes June 5, 2005, 6pm (1800) EDT. > > I had received concerns from FTF members regarding the proposed > resolutions for 7259, 7268, 7269, 7270, 7271 and 7663. I decided > to move these issues as "Deferred" into the follow-on RTF. > Now wee need to close this FTF in time orderly. > > Therefore please vote ASAP. Poll closes on Sunday June 5 at 6.0pm > (1800) EDT. > > Thanks for your cooperation, > > Manfred > > > PS: This is the UML Diagram Interchange FTF voting list: > > 88solutions Manfred Koethe > Adaptive Ltd. Pete Rivett > Boeing Woody Pidcock > Compuware Corp. Wim Bast > Hewlett-Packard Jishnu Mukerji > IBM Bran Selic > Kennedy Carter Ian Wilkie > No Magic, Inc. Daniel Brookshier > Sun Microsystems Martin Matula > THALES Laurent Rioux > Telelogic AB Cris Kobryn > Unisys Sumeet Malhotra > > -- > ___________________ > / Manfred R. Koethe \_____________________________________ > 88solutions Corp. E-Mail: koethe@88solutions.com > 37 Mague Avenue Tel: +1 (617) 848 0525 > Newton, MA 02465-1553 FAX: +1 (617) 848 8819 > U.S.A. > _____________________________"We make your business flow"_ > http://www.adaptive.com