Issue 14552: Ordered derived unions (uml2-rtf) Source: (Dr. Maged Elaasar, melaasar(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: When you specify a property as an ordered derived union, with the implied derivation of union-ing the subsetting properties, how do you specify the order of the resulting union? Resolution: Revised Text: Actions taken: October 7, 2009: received issue October 9, 2009: moved from MOF Core RTF to the UML 2 Infrastructure RTF Discussion: End of Annotations:===== ubject: Ordered derived unions To: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 7 Oct 2009 17:03:57 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/07/2009 17:03:58 When you specify a property as an ordered derived union, with the implied derivation of union-ing the subsetting properties, how do you specify the order of the resulting union? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: Ordered derived unions Date: Wed, 7 Oct 2009 14:13:48 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ordered derived unions Thread-Index: AcpHkbjxrfD4/PxVQlKR/4OvGvDy/AAAGFag From: "Pete Rivett" To: "Maged Elaasar" , There is no such capability provided. There is in fact no need to specify the order of the resulting union . all that is meant by {ordered} is that the order is maintained and not randomly different on subsequent accesses to the property value (assuming no intervening update). I.m not sure how much sense {ordered} makes for a {union}. It minimally requires all the subsetting properties to also be {ordered} . we should either specify that constraint or disallow it. Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 07 October 2009 14:04 To: uml2-rtf@omg.org Subject: Ordered derived unions When you specify a property as an ordered derived union, with the implied derivation of union-ing the subsetting properties, how do you specify the order of the resulting union? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: Ordered derived unions Date: Thu, 8 Oct 2009 11:51:23 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ordered derived unions thread-index: AQHKR5IliipxxxMFyEeAq6iPRSJFD5D6hjcAgADZieCAAG8OkA== From: "Ed Seidewitz" To: "Steve Cook" , "Pete Rivett - Adaptive" , "Maged Elaasar" , Note that, in the UML action metamodel, the add structural feature value action has an .insertAt. pin for ordered features (which essentially has the behavior of .insert before., with a value of .*. meaning .append at end.). Of course, this isn.t available for MOF. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 08, 2009 5:20 AM To: Pete Rivett - Adaptive; Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions >all that is meant by {ordered} is that the order is maintained and not randomly different on subsequent accesses to the property value (assuming no intervening update). I was surprised to read that, but on looking at the MOF spec it appears to be true. I also expect an ordered property to be one in which it is possible to control where insertions occur, i.e. the API includes operations like insertAfter, insertBefore, etc. Otherwise how is it possible to create a decent modeling tool! From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 07 October 2009 22:14 To: Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions There is no such capability provided. There is in fact no need to specify the order of the resulting union . all that is meant by {ordered} is that the order is maintained and not randomly different on subsequent accesses to the property value (assuming no intervening update). I.m not sure how much sense {ordered} makes for a {union}. It minimally requires all the subsetting properties to also be {ordered} . we should either specify that constraint or disallow it. Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 07 October 2009 14:04 To: uml2-rtf@omg.org Subject: Ordered derived unions When you specify a property as an ordered derived union, with the implied derivation of union-ing the subsetting properties, how do you specify the order of the resulting union? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: Ordered derived unions Date: Thu, 8 Oct 2009 09:11:48 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ordered derived unions Thread-Index: AQHKR5IliipxxxMFyEeAq6iPRSJFD5D6hjcAgADZieCAAG8OkIAAA/Xg From: "Pete Rivett" To: "Ed Seidewitz" , "Steve Cook" , "Maged Elaasar" , MOF does define interfaces for maintaining order: specifically 10.7 ReflectiveSequence has add(index, object), remove(index), set(index, object). That was not my point which was not about controlling the order of the content but about .specifying. the order.. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 08 October 2009 08:51 To: Steve Cook; Pete Rivett; Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions Note that, in the UML action metamodel, the add structural feature value action has an .insertAt. pin for ordered features (which essentially has the behavior of .insert before., with a value of .*. meaning .append at end.). Of course, this isn.t available for MOF. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 08, 2009 5:20 AM To: Pete Rivett - Adaptive; Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions >all that is meant by {ordered} is that the order is maintained and not randomly different on subsequent accesses to the property value (assuming no intervening update). I was surprised to read that, but on looking at the MOF spec it appears to be true. I also expect an ordered property to be one in which it is possible to control where insertions occur, i.e. the API includes operations like insertAfter, insertBefore, etc. Otherwise how is it possible to create a decent modeling tool! From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 07 October 2009 22:14 To: Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions There is no such capability provided. There is in fact no need to specify the order of the resulting union . all that is meant by {ordered} is that the order is maintained and not randomly different on subsequent accesses to the property value (assuming no intervening update). I.m not sure how much sense {ordered} makes for a {union}. It minimally requires all the subsetting properties to also be {ordered} . we should either specify that constraint or disallow it. Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 07 October 2009 14:04 To: uml2-rtf@omg.org Subject: Ordered derived unions When you specify a property as an ordered derived union, with the implied derivation of union-ing the subsetting properties, how do you specify the order of the resulting union? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 From: Steve Cook To: Pete Rivett , Ed Seidewitz , Maged Elaasar , "uml2-rtf@omg.org" Subject: RE: Ordered derived unions Thread-Topic: Ordered derived unions Thread-Index: AQHKR5IliipxxxMFyEeAq6iPRSJFD5D6hjcAgADZieCAAG8OkIAAA/XggAAGctA= Date: Thu, 8 Oct 2009 16:30:54 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Ah yes: I stand corrected. I was actually looking at the CMOF semantics chapter, which talks about links, but says nothing about how they might be ordered with respect to their ends. Perhaps that semantics chapter should be deleted. I doubt it adds significant value. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 08 October 2009 17:12 To: Ed Seidewitz; Steve Cook; Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions MOF does define interfaces for maintaining order: specifically 10.7 ReflectiveSequence has add(index, object), remove(index), set(index, object). That was not my point which was not about controlling the order of the content but about .specifying. the order.. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 08 October 2009 08:51 To: Steve Cook; Pete Rivett; Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions Note that, in the UML action metamodel, the add structural feature value action has an .insertAt. pin for ordered features (which essentially has the behavior of .insert before., with a value of .*. meaning .append at end.). Of course, this isn.t available for MOF. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 08, 2009 5:20 AM To: Pete Rivett - Adaptive; Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions >all that is meant by {ordered} is that the order is maintained and not randomly different on subsequent accesses to the property value (assuming no intervening update). I was surprised to read that, but on looking at the MOF spec it appears to be true. I also expect an ordered property to be one in which it is possible to control where insertions occur, i.e. the API includes operations like insertAfter, insertBefore, etc. Otherwise how is it possible to create a decent modeling tool! From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 07 October 2009 22:14 To: Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions There is no such capability provided. There is in fact no need to specify the order of the resulting union . all that is meant by {ordered} is that the order is maintained and not randomly different on subsequent accesses to the property value (assuming no intervening update). I.m not sure how much sense {ordered} makes for a {union}. It minimally requires all the subsetting properties to also be {ordered} . we should either specify that constraint or disallow it. Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 07 October 2009 14:04 To: uml2-rtf@omg.org Subject: Ordered derived unions When you specify a property as an ordered derived union, with the implied derivation of union-ing the subsetting properties, how do you specify the order of the resulting union? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: Ordered derived unions To: "Pete Rivett" Cc: "Ed Seidewitz" , "Steve Cook" , uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 8 Oct 2009 12:31:23 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/08/2009 12:31:23 Yes - since ordered derived unions are "derived", you can only control the order through "specification", which is not a supported feature as you mentioned. "Pete Rivett" "Pete Rivett" 10/08/2009 12:11 PM To "Ed Seidewitz" , "Steve Cook" , Maged Elaasar/Ottawa/IBM@IBMCA, cc Subject RE: Ordered derived unions MOF does define interfaces for maintaining order: specifically 10.7 ReflectiveSequence has add(index, object), remove(index), set(index, object). That was not my point which was not about controlling the order of the content but about .specifying. the order.. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 08 October 2009 08:51 To: Steve Cook; Pete Rivett; Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions Note that, in the UML action metamodel, the add structural feature value action has an .insertAt. pin for ordered features (which essentially has the behavior of .insert before., with a value of .*. meaning .append at end.). Of course, this isn.t available for MOF. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 08, 2009 5:20 AM To: Pete Rivett - Adaptive; Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions >all that is meant by {ordered} is that the order is maintained and not randomly different on subsequent accesses to the property value (assuming no intervening update). I was surprised to read that, but on looking at the MOF spec it appears to be true. I also expect an ordered property to be one in which it is possible to control where insertions occur, i.e. the API includes operations like insertAfter, insertBefore, etc. Otherwise how is it possible to create a decent modeling tool! From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 07 October 2009 22:14 To: Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions There is no such capability provided. There is in fact no need to specify the order of the resulting union . all that is meant by {ordered} is that the order is maintained and not randomly different on subsequent accesses to the property value (assuming no intervening update). I.m not sure how much sense {ordered} makes for a {union}. It minimally requires all the subsetting properties to also be {ordered} . we should either specify that constraint or disallow it. Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 07 October 2009 14:04 To: uml2-rtf@omg.org Subject: Ordered derived unions When you specify a property as an ordered derived union, with the implied derivation of union-ing the subsetting properties, how do you specify the order of the resulting union? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 pic32629.gif From: "Bock, Conrad" To: "uml2-rtf@omg.org" Date: Thu, 8 Oct 2009 12:43:14 -0400 Subject: RE: Ordered derived unions Thread-Topic: Ordered derived unions Thread-Index: AcpINQXgP5XLRSVxSjSqDRwql/ptcQAAL0+A Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n98GfiqP019522 Maged, > Yes - since ordered derived unions are "derived", you can > only control the order through "specification", which is > not a supported feature as you mentioned. I hope derivation is different than read-only. You should be able to set a derived property as long as the value is consistent with the derivation (or the derivation is reversable). In this case, you should be able to reorder the values as long as order specified in the subsets (if any) is preserved in the union. There was some discussion of interchanging derived values that are set, but I don't remember the outcome. Conrad From: Steve Cook To: "Bock, Conrad" , "uml2-rtf@omg.org" Subject: RE: Ordered derived unions Thread-Topic: Ordered derived unions Thread-Index: AQHKR5IliipxxxMFyEeAq6iPRSJFD5D6hjcAgADZieCAAG8OkIAAA/Xg///24YCAAANPAIAAE7nQ Date: Thu, 8 Oct 2009 16:54:00 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n98GqX88021699 >From UML: [8] A derived union is read only. isDerivedUnion implies isReadOnly -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 08 October 2009 17:43 To: uml2-rtf@omg.org Subject: RE: Ordered derived unions Maged, > Yes - since ordered derived unions are "derived", you can > only control the order through "specification", which is > not a supported feature as you mentioned. I hope derivation is different than read-only. You should be able to set a derived property as long as the value is consistent with the derivation (or the derivation is reversable). In this case, you should be able to reorder the values as long as order specified in the subsets (if any) is preserved in the union. There was some discussion of interchanging derived values that are set, but I don't remember the outcome. Conrad From: "Bock, Conrad" To: "uml2-rtf@omg.org" Date: Thu, 8 Oct 2009 12:57:23 -0400 Subject: RE: Ordered derived unions Thread-Topic: Ordered derived unions Thread-Index: AQHKR5IliipxxxMFyEeAq6iPRSJFD5D6hjcAgADZieCAAG8OkIAAA/Xg///24YCAAANPAIAAE7nQgAAA6kA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n98GtsHi022373 Steve, > [8] A derived union is read only. > isDerivedUnion implies isReadOnly Bug. :) Conrad Subject: RE: Ordered derived unions Date: Fri, 9 Oct 2009 08:54:06 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ordered derived unions Thread-Index: AQHKR5IliipxxxMFyEeAq6iPRSJFD5D6hjcAgADZieCAAG8OkIAAA/Xg///24YCAAANPAIAAE7nQgAAA6kCAAOMZoA== From: "BERNARD, Yves" To: "Bock, Conrad" , X-OriginalArrivalTime: 09 Oct 2009 06:54:07.0266 (UTC) FILETIME=[4BDAE820:01CA48AD] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n996qZbb027089 Conrad, I disagree. By definition a "derived" property has its value calculated according to value from other properties. If its not the case, it means that the property is not derived. On the other hand, a non-derived property may have a default value calculated (i.e. derived) from value of other properties, but its only its default value... To me, if there is an inconsistency somewhere it because all derived properties should be readonly. Consider the practical impact of this statement from the UML specification (§7.3.44, semantic section): "where a derived property is changeable, an implementation is expected to make appropriate changes to the model in order for all the constraints to be met, in particular the derivation constraint for the derived property." More generaly, I don't think that derived union can be actually ordered because an union is a commutative law. Yves -----Message d'origine----- De : Bock, Conrad [mailto:conrad.bock@nist.gov] Envoyé : jeudi 8 octobre 2009 18:57 À : uml2-rtf@omg.org Objet : RE: Ordered derived unions Steve, > [8] A derived union is read only. > isDerivedUnion implies isReadOnly Bug. :) Conrad This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Date: Fri, 09 Oct 2009 11:48:54 +0100 From: Dave Hawkins User-Agent: Thunderbird 2.0.0.6 (X11/20070728) To: "Bock, Conrad" CC: "uml2-rtf@omg.org" Subject: Re: Ordered derived unions X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4ACF151E.0134:SCFMA4539814,ss=1,fgs=0 Conrad, Bock, Conrad wrote: Maged, > Yes - since ordered derived unions are "derived", you can > only control the order through "specification", which is > not a supported feature as you mentioned. I hope derivation is different than read-only. You should be able to set a derived property as long as the value is consistent with the derivation (or the derivation is reversable). In this case, you should be able to reorder the values as long as order specified in the subsets (if any) is preserved in the union. There was some discussion of interchanging derived values that are set, but I don't remember the outcome. If the union has to preserve the order of its subsets that would imply the subsets are all ordered in the same way. That could be regarded as the meaning of an ordered union. However I'm not sure how useful that would actually be and I think it would be better that unions never be ordered. If you want to explicitly order the union, then, as Bernard has said, the property is no longer derived because you are providing information that cannot be derived from other properties. It's not strictly the same as a non-derived property though because it's constrained to be the union of its subsets. So I could see an argument there for not requiring a union to be derived. Writeable derived properties are a nasty feature that I don't think should be allowed. They should always have the correct values anyway because they are derived from other properties, so in general it should never be necessary to set them. Setting them also requires reverse derivations, which are not supplied in the UML metamodel. I have a feeling writeable derived properties were allowed to support the various compliance levels, because a property could become derived in a higher compliance level. Thus to XMI import a lower compliance level in a higher level would require 'setting' the derived property. If compliance levels are now being removed, it should be considered whether derived properties should be anything other than read-only. Dave -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. Subject: RE: Ordered derived unions Date: Fri, 9 Oct 2009 08:15:32 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ordered derived unions Thread-Index: AcpIzkwtGU3juwtERBy+6EltaZFrfgAJC0gg From: "Pete Rivett" To: "Dave Hawkins" Cc: , "Bock, Conrad" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n99FE7Nq019009 > I have a feeling writeable derived properties were allowed to support the various compliance levels, because a property could become derived in a higher > compliance level. Thus to XMI import a lower compliance level in a higher level would require 'setting' the derived property. > If compliance levels are now being removed, it should be considered whether derived properties should be anything other than read-only. Writeable derived properties are useful in 'normal' modeling where there are 2 properties which are representations of the same value - for example 'weightInPounds' derived from 'weightInKilos'. Setting the former would implicitly set the other. Another example is something like 'fullName' derived from a number of other properties like 'firstNames', 'lastName' etc. Setting fullName could set the other attributes given a sufficiently sophisticated parser. Likewise 'fullAddress'. Pete -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: 09 October 2009 03:49 To: Bock, Conrad Cc: uml2-rtf@omg.org Subject: Re: Ordered derived unions Conrad, Bock, Conrad wrote: > Maged, > > > Yes - since ordered derived unions are "derived", you can > > only control the order through "specification", which is > > not a supported feature as you mentioned. > > I hope derivation is different than read-only. You should be able to > set a derived property as long as the value is consistent with the > derivation (or the derivation is reversable). In this case, you should > be able to reorder the values as long as order specified in the subsets > (if any) is preserved in the union. There was some discussion of > interchanging derived values that are set, but I don't remember the > outcome. If the union has to preserve the order of its subsets that would imply the subsets are all ordered in the same way. That could be regarded as the meaning of an ordered union. However I'm not sure how useful that would actually be and I think it would be better that unions never be ordered. If you want to explicitly order the union, then, as Bernard has said, the property is no longer derived because you are providing information that cannot be derived from other properties. It's not strictly the same as a non-derived property though because it's constrained to be the union of its subsets. So I could see an argument there for not requiring a union to be derived. Writeable derived properties are a nasty feature that I don't think should be allowed. They should always have the correct values anyway because they are derived from other properties, so in general it should never be necessary to set them. Setting them also requires reverse derivations, which are not supplied in the UML metamodel. I have a feeling writeable derived properties were allowed to support the various compliance levels, because a property could become derived in a higher compliance level. Thus to XMI import a lower compliance level in a higher level would require 'setting' the derived property. If compliance levels are now being removed, it should be considered whether derived properties should be anything other than read-only. Dave -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. From: "Bock, Conrad" To: "uml2-rtf@omg.org" Date: Fri, 9 Oct 2009 11:22:41 -0400 Subject: RE: Ordered derived unions Thread-Topic: Ordered derived unions Thread-Index: AcpIzi6pomJD2VFmSRi8WlPMURhU8wAJaaAw Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n99FL52u020506 Dave, > If the union has to preserve the order of its subsets that would > imply the subsets are all ordered in the same way. No, it just means the order of elements in the union that come from the same susbet are in the same order as the subset. The subsets don't need to be ordered by the same criteria. > Writeable derived properties are a nasty feature that I don't think > should be allowed. They should always have the correct values anyway > because they are derived from other properties, so in general it > should never be necessary to set them. Setting them also requires > reverse derivations, which are not supplied in the UML metamodel. The values the derivation is based on might not be there. For example, you should be able to interchange the area of a square even if the width and height aren't known. Conrad From: "Bock, Conrad" To: "BERNARD, Yves" , "uml2-rtf@omg.org" Date: Fri, 9 Oct 2009 11:25:05 -0400 Subject: RE: Ordered derived unions Thread-Topic: Ordered derived unions Thread-Index: AQHKR5IliipxxxMFyEeAq6iPRSJFD5D6hjcAgADZieCAAG8OkIAAA/Xg///24YCAAANPAIAAE7nQgAAA6kCAAOMZoIAAlOMA Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n99FNQw1020973 Yves, > I disagree. By definition a "derived" property has its > value calculated according to value from other properties. > If its not the case, it means that the property is not > derived. On the other hand, a non-derived property may have > a default value calculated (i.e. derived) from value of > other properties, but its only its default value... > To me, if there is an inconsistency somewhere it because > all derived properties should be readonly. Consider the > practical impact of this statement from the UML > specification (§7.3.44, semantic section): > "where a derived property is changeable, an implementation > is expected to make appropriate changes to the model in > order for all the constraints to be met, in particular the > derivation constraint for the derived property." See my message to Dave. It's very useful to treat derived properties as specified by constraint, so explicitly writing a derived value places a constraint on the values used in the derivation. Conrad X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 09 Oct 2009 11:41:35 -0400 To: Steve Cook , Pete Rivett , Ed Seidewitz , Maged Elaasar , "uml2-rtf@omg.org" From: Juergen Boldt Subject: RE: Ordered derived unions should I assign an issue number to this email thread? -Juergen At 12:30 PM 10/8/2009, Steve Cook wrote: Ah yes: I stand corrected. I was actually looking at the CMOF semantics chapter, which talks about links, but says nothing about how they might be ordered with respect to their ends. Perhaps that semantics chapter should be deleted. I doubt it adds significant value. -- Steve From: Pete Rivett [ mailto:pete.rivett@adaptive.com] Sent: 08 October 2009 17:12 To: Ed Seidewitz; Steve Cook; Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions MOF does define interfaces for maintaining order: specifically 10.7 ReflectiveSequence has add(index, object), remove(index), set(index, object). That was not my point which was not about controlling the order of the content but about .specifying. the order.. Pete From: Ed Seidewitz [ mailto:ed-s@modeldriven.com] Sent: 08 October 2009 08:51 To: Steve Cook; Pete Rivett; Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions Note that, in the UML action metamodel, the add structural feature value action has an .insertAt. pin for ordered features (which essentially has the behavior of .insert before., with a value of .*. meaning .append at end.). Of course, this isn.t available for MOF. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [ mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 08, 2009 5:20 AM To: Pete Rivett - Adaptive; Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions >all that is meant by {ordered} is that the order is maintained and not randomly different on subsequent accesses to the property value (assuming no intervening update). I was surprised to read that, but on looking at the MOF spec it appears to be true. I also expect an ordered property to be one in which it is possible to control where insertions occur, i.e. the API includes operations like insertAfter, insertBefore, etc. Otherwise how is it possible to create a decent modeling tool! From: Pete Rivett [ mailto:pete.rivett@adaptive.com] Sent: 07 October 2009 22:14 To: Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions There is no such capability provided. There is in fact no need to specify the order of the resulting union . all that is meant by {ordered} is that the order is maintained and not randomly different on subsequent accesses to the property value (assuming no intervening update). I.m not sure how much sense {ordered} makes for a {union}. It minimally requires all the subsetting properties to also be {ordered} . we should either specify that constraint or disallow it. Pete From: Maged Elaasar [ mailto:melaasar@ca.ibm.com] Sent: 07 October 2009 14:04 To: uml2-rtf@omg.org Subject: Ordered derived unions When you specify a property as an ordered derived union, with the implied derivation of union-ing the subsetting properties, how do you specify the order of the resulting union? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org From: Steve Cook To: Juergen Boldt , Pete Rivett , Ed Seidewitz , Maged Elaasar , "uml2-rtf@omg.org" Subject: RE: Ordered derived unions Thread-Topic: Ordered derived unions Thread-Index: AQHKR5IliipxxxMFyEeAq6iPRSJFD5D6hjcAgADZieCAAG8OkIAAA/XggAAGctCAAYZZVoAAATxg Date: Fri, 9 Oct 2009 15:49:46 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Juergen I think it is a MOF issue: CMOF semantics chapter says nothing about link ordering. So yes please. Thanks -- Steve From: Juergen Boldt [mailto:juergen@omg.org] Sent: 09 October 2009 16:42 To: Steve Cook; Pete Rivett; Ed Seidewitz; Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions should I assign an issue number to this email thread? -Juergen At 12:30 PM 10/8/2009, Steve Cook wrote: Ah yes: I stand corrected. I was actually looking at the CMOF semantics chapter, which talks about links, but says nothing about how they might be ordered with respect to their ends. Perhaps that semantics chapter should be deleted. I doubt it adds significant value. -- Steve From: Pete Rivett [ mailto:pete.rivett@adaptive.com] Sent: 08 October 2009 17:12 To: Ed Seidewitz; Steve Cook; Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions MOF does define interfaces for maintaining order: specifically 10.7 ReflectiveSequence has add(index, object), remove(index), set(index, object). That was not my point which was not about controlling the order of the content but about .specifying. the order.. Pete From: Ed Seidewitz [ mailto:ed-s@modeldriven.com] Sent: 08 October 2009 08:51 To: Steve Cook; Pete Rivett; Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions Note that, in the UML action metamodel, the add structural feature value action has an .insertAt. pin for ordered features (which essentially has the behavior of .insert before., with a value of .*. meaning .append at end.). Of course, this isn.t available for MOF. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [ mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 08, 2009 5:20 AM To: Pete Rivett - Adaptive; Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions >all that is meant by {ordered} is that the order is maintained and not randomly different on subsequent accesses to the property value (assuming no intervening update). I was surprised to read that, but on looking at the MOF spec it appears to be true. I also expect an ordered property to be one in which it is possible to control where insertions occur, i.e. the API includes operations like insertAfter, insertBefore, etc. Otherwise how is it possible to create a decent modeling tool! From: Pete Rivett [ mailto:pete.rivett@adaptive.com] Sent: 07 October 2009 22:14 To: Maged Elaasar; uml2-rtf@omg.org Subject: RE: Ordered derived unions There is no such capability provided. There is in fact no need to specify the order of the resulting union . all that is meant by {ordered} is that the order is maintained and not randomly different on subsequent accesses to the property value (assuming no intervening update). I.m not sure how much sense {ordered} makes for a {union}. It minimally requires all the subsetting properties to also be {ordered} . we should either specify that constraint or disallow it. Pete From: Maged Elaasar [ mailto:melaasar@ca.ibm.com] Sent: 07 October 2009 14:04 To: uml2-rtf@omg.org Subject: Ordered derived unions When you specify a property as an ordered derived union, with the implied derivation of union-ing the subsetting properties, how do you specify the order of the resulting union? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 09 Oct 2009 12:00:15 -0400 To: issues@omg.org, mof2core-rtf@omg.org From: Juergen Boldt Subject: issue 14552 -- MOF 2 Core RTF issue Cc: uml2-rtf@omg.org Subject: Ordered derived unions To: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 7 Oct 2009 17:03:57 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/07/2009 17:03:58 When you specify a property as an ordered derived union, with the implied derivation of union-ing the subsetting properties, how do you specify the order of the resulting union? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org From: "Bock, Conrad" To: "uml2-rtf@omg.org" Date: Fri, 9 Oct 2009 12:05:57 -0400 Subject: RE: Ordered derived unions Thread-Topic: Ordered derived unions Thread-Index: AQHKR5IliipxxxMFyEeAq6iPRSJFD5D6hjcAgADZieCAAG8OkIAAA/XggAAGctCAAYZZVoAAATxggAABzpA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n99G4HRc028734 Steve, > I think it is a MOF issue: CMOF semantics chapter says > nothing about link ordering. So yes please. Is this shared with UML? In any case, link ordering is different than this thread one setting derived properties, how to specify ordering in derived unions, etc, though related of course. Conrad From: Steve Cook To: "Bock, Conrad" , "uml2-rtf@omg.org" Subject: RE: Ordered derived unions Thread-Topic: Ordered derived unions Thread-Index: AQHKR5IliipxxxMFyEeAq6iPRSJFD5D6hjcAgADZieCAAG8OkIAAA/XggAAGctCAAYZZVoAAATxggAABzpCAAAOToA== Date: Fri, 9 Oct 2009 16:08:46 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n99G7L8K029155 Not shared with UML. MOF has its own semantics chapter. -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 09 October 2009 17:06 To: uml2-rtf@omg.org Subject: RE: Ordered derived unions Steve, > I think it is a MOF issue: CMOF semantics chapter says > nothing about link ordering. So yes please. Is this shared with UML? In any case, link ordering is different than this thread one setting derived properties, how to specify ordering in derived unions, etc, though related of course. Conrad From: "Bock, Conrad" To: "uml2-rtf@omg.org" Date: Fri, 9 Oct 2009 12:12:11 -0400 Subject: RE: Ordered derived unions Thread-Topic: Ordered derived unions Thread-Index: AQHKR5IliipxxxMFyEeAq6iPRSJFD5D6hjcAgADZieCAAG8OkIAAA/XggAAGctCAAYZZVoAAATxggAABzpCAAAOToIAAANrg Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n99GAXUX029583 Steve, > Not shared with UML. MOF has its own semantics chapter. In that case, I'd reassign the issue Juergen just entered to UML/Infrastructure, because UML has derived uonions also, then file another issue about links in the MOF semantics. Conrad Subject: RE: issue 14552 -- MOF 2 Core RTF issue Date: Fri, 9 Oct 2009 09:39:10 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 14552 -- MOF 2 Core RTF issue Thread-Index: AQHKSPoTKnVpSKi23UOnDIKK5oJCO5D9aUfQgAABbGA= From: "Pete Rivett" To: "Steve Cook" Cc: Ø In fact the MOF semantics chapter seems to add no value and perhaps it should be deleted from the spec altogether. Ø Notwithstanding the omission or ordering, are you saying there is inherently .no value. in attempting to represent the specific semantics of MOF, or that the current attempt to do that fails? If the latter, is it because of the approach taken (specifying the primitive operations in terms of post conditions at the instance level) or the current implementation of that approach? If the approach is the problem, what approach would you advocate? Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 09 October 2009 09:31 To: Juergen Boldt; issues@omg.org; mof2core-rtf@omg.org Cc: uml2-rtf@omg.org Subject: RE: issue 14552 -- MOF 2 Core RTF issue Juergen Can you reassign this one to UML infrastructure please, and raise a different issue against MOF: MOF semantics chapter says nothing about ordering of links when association ends are marked .ordered.. In fact the MOF semantics chapter seems to add no value and perhaps it should be deleted from the spec altogether. Thanks - -Steve From: Juergen Boldt [mailto:juergen@omg.org] Sent: 09 October 2009 17:00 To: issues@omg.org; mof2core-rtf@omg.org Cc: uml2-rtf@omg.org Subject: issue 14552 -- MOF 2 Core RTF issue Subject: Ordered derived unions To: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 7 Oct 2009 17:03:57 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/07/2009 17:03:58 When you specify a property as an ordered derived union, with the implied derivation of union-ing the subsetting properties, how do you specify the order of the resulting union? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org From: Steve Cook To: Pete Rivett CC: "mof2core-rtf@omg.org" Subject: RE: issue 14552 -- MOF 2 Core RTF issue Thread-Topic: issue 14552 -- MOF 2 Core RTF issue Thread-Index: AQHKSPoTKnVpSKi23UOnDIKK5oJCO5D9aUfQgAABbGCAAAQUcA== Date: Fri, 9 Oct 2009 16:52:01 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: There just seems to be plenty of relatively easily digestible information in the rest of the spec that says what the operations do, whereas the semantics chapter is verbose, and verification that what it says is meaningful is intractable. From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 09 October 2009 17:39 To: Steve Cook Cc: mof2core-rtf@omg.org Subject: RE: issue 14552 -- MOF 2 Core RTF issue Ø In fact the MOF semantics chapter seems to add no value and perhaps it should be deleted from the spec altogether. Ø Notwithstanding the omission or ordering, are you saying there is inherently .no value. in attempting to represent the specific semantics of MOF, or that the current attempt to do that fails? If the latter, is it because of the approach taken (specifying the primitive operations in terms of post conditions at the instance level) or the current implementation of that approach? If the approach is the problem, what approach would you advocate? Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 09 October 2009 09:31 To: Juergen Boldt; issues@omg.org; mof2core-rtf@omg.org Cc: uml2-rtf@omg.org Subject: RE: issue 14552 -- MOF 2 Core RTF issue Juergen Can you reassign this one to UML infrastructure please, and raise a different issue against MOF: MOF semantics chapter says nothing about ordering of links when association ends are marked .ordered.. In fact the MOF semantics chapter seems to add no value and perhaps it should be deleted from the spec altogether. Thanks - -Steve From: Juergen Boldt [mailto:juergen@omg.org] Sent: 09 October 2009 17:00 To: issues@omg.org; mof2core-rtf@omg.org Cc: uml2-rtf@omg.org Subject: issue 14552 -- MOF 2 Core RTF issue Subject: Ordered derived unions To: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 7 Oct 2009 17:03:57 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/07/2009 17:03:58 When you specify a property as an ordered derived union, with the implied derivation of union-ing the subsetting properties, how do you specify the order of the resulting union? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Date: Tue, 19 Feb 2013 14:45:31 +0000 From: Dave Hawkins User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 To: "Manfred R. Koethe" CC: "uml25-ftf@omg.org" Subject: [UML 2.5 FTF] Ballot 2 - Issue 14552 X-Source-IP: userp1040.oracle.com [156.151.31.81] X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== This doesn't make sense. You could have two mutually incompatible orderings. I'd also expect a sequential order to be predictable and thus total, but deriving the order means it can be a partial order or even just completely random. Derived unions just shouldn't be ordered. Dave On 17/02/13 22:27, Manfred R. Koethe wrote: Dear Colleagues, Thank you all for reading and commenting on Ballot 2 right away. As requested, and considering the early comments, I herewith change the voting period of Ballot 2 to: ==>> Poll start date: Monday, 25 February 2013 (01:00 AM EDT - 06:00 GMT) ==>> Poll closing date: Sunday, 03 March 2013 (7:00 PM EDT - 24:00 GMT) Please review the attached REVISED preview, which has changes to 12167, 17854, 17890 and 18071. Important: If you have comments on resolutions in Ballot 2, try to be on the call next Tuesday 11:00 - 12:00 EST or delegate your comments to a call participant for discussion. Thank you. Kind regards, Manfred --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (617) 848 0525 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. Date: Wed, 20 Feb 2013 14:15:37 +0000 From: Dave Hawkins User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 To: Steve Cook CC: "Manfred R. Koethe" , "uml25-ftf@omg.org" Subject: Re: [UML 2.5 FTF] Ballot 2 - Issue 14552 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Steve, The revised text should make clear that incompatible orderings make the model invalid and ordering can be indeterminate. However I still think this is a bad idea. In the places I've seen ordering used, the positions of values are semantically significant. This means an indeterminate order will cause problems. Here's a simple example: If we have ordered property p : T, I'd expect the following to hold: let v1 : OrderedSet(T) = self.p, v2 : OrderedSet(T) = self.p in Sequence{1..self.p->size()}->forAll(i | v1->at(i) = v2->at(i)) However, if p is a derived union with subsets px and py containing {a} and {b} respectively the following are the valid ordered collections for p: {a, b} {b, a} So it would be valid for v1 to be {a, b} and v2 to be {b, a}. The OCL would be false, but sometimes, of course, it could be true. In the UML metamodel the ExceptionHandler::output_pins constraint relies on a determinate order for the ordered derived union Action::output. There are subclasses of Action with multiple subsets of output, for example, AcceptCallAction (result and returnInformation), so this isn't an entirely theoretical problem. Dave On 19/02/13 17:13, Steve Cook wrote: Dave The UML metamodel itself contains three examples of ordered unions. We cannot outlaw them. On today's call we decided that the proposed resolution is ok. If you had mutually incompatible orderings the model would be invalid. Otherwise the ordering is indeed indeterminate in cases where the union is derived from more than one subset. Thanks -- Steve -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: 19 February 2013 14:46 To: Manfred R. Koethe Cc: uml25-ftf@omg.org Subject: [UML 2.5 FTF] Ballot 2 - Issue 14552 This doesn't make sense. You could have two mutually incompatible orderings. I'd also expect a sequential order to be predictable and thus total, but deriving the order means it can be a partial order or even just completely random. Derived unions just shouldn't be ordered. Dave On 17/02/13 22:27, Manfred R. Koethe wrote: Dear Colleagues, Thank you all for reading and commenting on Ballot 2 right away. As requested, and considering the early comments, I herewith change the voting period of Ballot 2 to: ==>> Poll start date: Monday, 25 February 2013 (01:00 AM EDT - 06:00 GMT) ==>> Poll closing date: Sunday, 03 March 2013 (7:00 PM EDT - 24:00 GMT) Please review the attached REVISED preview, which has changes to 12167, 17854, 17890 and 18071. Important: If you have comments on resolutions in Ballot 2, try to be on the call next Tuesday 11:00 - 12:00 EST or delegate your comments to a call participant for discussion. Thank you. Kind regards, Manfred --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (617) 848 0525 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. From: Steve Cook To: Dave Hawkins CC: "Manfred R. Koethe" , "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] Ballot 2 - Issue 14552 Thread-Topic: [UML 2.5 FTF] Ballot 2 - Issue 14552 Thread-Index: AQHODq/l7edoaa2csEibedltfZ9gE5iBapNggAFhj4CAAAHDYA== Date: Wed, 20 Feb 2013 14:28:57 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(13464002)(71364001)(199002)(189002)(24454001)(479174001)(377454001)(51704002)(5403001)(4396001)(23726001)(80022001)(47976001)(50986001)(56816002)(65816001)(47736001)(50466001)(49866001)(44976002)(74662001)(31966008)(47446002)(74502001)(20776003)(15202345001)(79102001)(16406001)(53806001)(51856001)(63696002)(54356001)(55846006)(16601075001)(46102001)(56776001)(76482001)(46406002)(47776003)(5343635001)(5343655001)(33656001)(77982001)(54316002)(59766001);DIR:OUT;SFP:;SCL:1;SRVR:BY2FFO11HUB018;H:TK5EX14HUBC101.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07630F72AD X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r1KETwgJ027027 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Dave In your example, self.p might be either {a, b} or {b, a}, but whichever it is, surely v1 = v2 (elementwise)? The indeterminacy doesn't mean that self.p somehow contains a superposition of all possible interleavings, it just means that the ordering of self.p is not fully determined from its subsets. However your correct observation about ExceptionHandler::output_pins is disturbing. Perhaps we do need to enforce a determinate total ordering on unions. Do you have a suggestion on what it should be? -- Steve -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: 20 February 2013 14:16 To: Steve Cook Cc: Manfred R. Koethe; uml25-ftf@omg.org Subject: Re: [UML 2.5 FTF] Ballot 2 - Issue 14552 Steve, The revised text should make clear that incompatible orderings make the model invalid and ordering can be indeterminate. However I still think this is a bad idea. In the places I've seen ordering used, the positions of values are semantically significant. This means an indeterminate order will cause problems. Here's a simple example: If we have ordered property p : T, I'd expect the following to hold: let v1 : OrderedSet(T) = self.p, v2 : OrderedSet(T) = self.p in Sequence{1..self.p->size()}->forAll(i | v1->at(i) = v2->at(i)) However, if p is a derived union with subsets px and py containing {a} and {b} respectively the following are the valid ordered collections for p: {a, b} {b, a} So it would be valid for v1 to be {a, b} and v2 to be {b, a}. The OCL would be false, but sometimes, of course, it could be true. In the UML metamodel the ExceptionHandler::output_pins constraint relies on a determinate order for the ordered derived union Action::output. There are subclasses of Action with multiple subsets of output, for example, AcceptCallAction (result and returnInformation), so this isn't an entirely theoretical problem. Dave On 19/02/13 17:13, Steve Cook wrote: > Dave > > The UML metamodel itself contains three examples of ordered unions. We cannot outlaw them. On today's call we decided that the proposed resolution is ok. > > If you had mutually incompatible orderings the model would be invalid. Otherwise the ordering is indeed indeterminate in cases where the union is derived from more than one subset. > > Thanks > -- Steve > > -----Original Message----- > From: Dave Hawkins [mailto:dave.hawkins@oracle.com] > Sent: 19 February 2013 14:46 > To: Manfred R. Koethe > Cc: uml25-ftf@omg.org > Subject: [UML 2.5 FTF] Ballot 2 - Issue 14552 > > This doesn't make sense. You could have two mutually incompatible orderings. I'd also expect a sequential order to be predictable and thus total, but deriving the order means it can be a partial order or even just completely random. Derived unions just shouldn't be ordered. > > Dave > > On 17/02/13 22:27, Manfred R. Koethe wrote: >> Dear Colleagues, >> >> Thank you all for reading and commenting on Ballot 2 right away. As >> requested, and considering the early comments, I herewith change the voting period of Ballot 2 to: >> >> ==>> Poll start date: Monday, 25 February 2013 (01:00 AM EDT - 06:00 >> GMT) >> >> ==>> Poll closing date: Sunday, 03 March 2013 (7:00 PM EDT - 24:00 >> GMT) >> >> Please review the attached REVISED preview, which has changes to 12167, 17854, 17890 and 18071. >> >> Important: If you have comments on resolutions in Ballot 2, try to be >> on the call next Tuesday 11:00 - 12:00 EST or delegate your comments to a call participant for discussion. Thank you. >> >> Kind regards, >> >> Manfred >> --------------------------------------------------------------- >> Manfred R. Koethe 88solutions Corporation >> tel: +1 (617) 848 0525 fax: +1 (815) 550 2086 >> mailto: koethe@88solutions.com >> web: http://www.88solutions.com >> --------(Model-Driven Modeling Solutions)-------- >> >> >> >> >> >> >> > > -- > Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. > Company Reg. No. 1782505. > Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. > -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. Date: Wed, 20 Feb 2013 15:41:12 +0000 From: Dave Hawkins User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 To: Steve Cook CC: "Manfred R. Koethe" , "uml25-ftf@omg.org" Subject: Re: [UML 2.5 FTF] Ballot 2 - Issue 14552 X-Source-IP: userp1040.oracle.com [156.151.31.81] X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Sorry, I should have added some kind of copy operation when assigning v1 and v2 to make them different elementwise. I was really trying to show that since the property is derived, it could be derived differently at different times, even including during the execution of a seemingly straightforward statement. As I wrote previously, I'm not terribly keen on having ordered unions at all. However that doesn't help the current spec. I think some possibilities are: 1) Constrain subsets to be ordered. Union the subsets in a particular order. So for example, if the subsets are {a, b, c} and {d, a} we would get {a, b, c, d}; the second 'a' gets ignored because it's already in {a, b, c}. However I'm not sure how to define an order for the subsets; Classifier::attributes order isn't sufficient as the subset may be an ownedEnd. 2) Make these properties non-unions, ie just derived. The derivation must then create a determinate total order. This is effectively (1) but makes it the modelers responsibility to determine the subset order. Dave On 20/02/13 14:28, Steve Cook wrote: Dave In your example, self.p might be either {a, b} or {b, a}, but whichever it is, surely v1 = v2 (elementwise)? The indeterminacy doesn't mean that self.p somehow contains a superposition of all possible interleavings, it just means that the ordering of self.p is not fully determined from its subsets. However your correct observation about ExceptionHandler::output_pins is disturbing. Perhaps we do need to enforce a determinate total ordering on unions. Do you have a suggestion on what it should be? -- Steve -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: 20 February 2013 14:16 To: Steve Cook Cc: Manfred R. Koethe; uml25-ftf@omg.org Subject: Re: [UML 2.5 FTF] Ballot 2 - Issue 14552 Steve, The revised text should make clear that incompatible orderings make the model invalid and ordering can be indeterminate. However I still think this is a bad idea. In the places I've seen ordering used, the positions of values are semantically significant. This means an indeterminate order will cause problems. Here's a simple example: If we have ordered property p : T, I'd expect the following to hold: let v1 : OrderedSet(T) = self.p, v2 : OrderedSet(T) = self.p in Sequence{1..self.p->size()}->forAll(i | v1->at(i) = v2->at(i)) However, if p is a derived union with subsets px and py containing {a} and {b} respectively the following are the valid ordered collections for p: {a, b} {b, a} So it would be valid for v1 to be {a, b} and v2 to be {b, a}. The OCL would be false, but sometimes, of course, it could be true. In the UML metamodel the ExceptionHandler::output_pins constraint relies on a determinate order for the ordered derived union Action::output. There are subclasses of Action with multiple subsets of output, for example, AcceptCallAction (result and returnInformation), so this isn't an entirely theoretical problem. Dave On 19/02/13 17:13, Steve Cook wrote: Dave The UML metamodel itself contains three examples of ordered unions. We cannot outlaw them. On today's call we decided that the proposed resolution is ok. If you had mutually incompatible orderings the model would be invalid. Otherwise the ordering is indeed indeterminate in cases where the union is derived from more than one subset. Thanks -- Steve -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: 19 February 2013 14:46 To: Manfred R. Koethe Cc: uml25-ftf@omg.org Subject: [UML 2.5 FTF] Ballot 2 - Issue 14552 This doesn't make sense. You could have two mutually incompatible orderings. I'd also expect a sequential order to be predictable and thus total, but deriving the order means it can be a partial order or even just completely random. Derived unions just shouldn't be ordered. Dave On 17/02/13 22:27, Manfred R. Koethe wrote: Dear Colleagues, Thank you all for reading and commenting on Ballot 2 right away. As requested, and considering the early comments, I herewith change the voting period of Ballot 2 to: ==>> Poll start date: Monday, 25 February 2013 (01:00 AM EDT - 06:00 GMT) ==>> Poll closing date: Sunday, 03 March 2013 (7:00 PM EDT - 24:00 GMT) Please review the attached REVISED preview, which has changes to 12167, 17854, 17890 and 18071. Important: If you have comments on resolutions in Ballot 2, try to be on the call next Tuesday 11:00 - 12:00 EST or delegate your comments to a call participant for discussion. Thank you. Kind regards, Manfred --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (617) 848 0525 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. From: Steve Cook To: Dave Hawkins CC: "Manfred R. Koethe" , "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] Ballot 2 - Issue 14552 Thread-Topic: [UML 2.5 FTF] Ballot 2 - Issue 14552 Thread-Index: AQHODq/l7edoaa2csEibedltfZ9gE5iBapNggAFhj4CAAAHDYIAAFiYAgAAJOgA= Date: Wed, 20 Feb 2013 16:29:42 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(199002)(189002)(24454001)(5403001)(31014001)(479174001)(71364001)(377454001)(51704002)(13464002)(79102001)(5343655001)(56776001)(16601075001)(44976002)(63696002)(31966008)(23726001)(54356001)(5343635001)(47446002)(54316002)(74502001)(59766001)(74662001)(77982001)(33656001)(47776003)(20776003)(65816001)(16406001)(80022001)(51856001)(15202345001)(76482001)(53806001)(46406002)(49866001)(47736001)(50466001)(56816002)(4396001)(47976001)(55846006)(46102001)(50986001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB030;H:TK5EX14HUBC104.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07630F72AD X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r1KGUTHg005457 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== I think we should withdraw 14552 from this ballot. Then we should raise a new issue that ExceptionHandler::output_pins is ill-defined because the ordering of /output is ill-defined. To solve this I'm leaning towards saying that derived unions shall not be ordered. Then (say) ExceptionHandler::output_pins could be defined in terms of a new operation (say orderedOutputPins()), and orderedOutputPins() would have to be redefined for different subclasses of Action. Similarly we'd have to introduce orderedAttributes() for Classifier, and possibly orderedInputs() for Action, although I haven't found anywhere that the input order matters. -- Steve -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: 20 February 2013 15:41 To: Steve Cook Cc: Manfred R. Koethe; uml25-ftf@omg.org Subject: Re: [UML 2.5 FTF] Ballot 2 - Issue 14552 Sorry, I should have added some kind of copy operation when assigning v1 and v2 to make them different elementwise. I was really trying to show that since the property is derived, it could be derived differently at different times, even including during the execution of a seemingly straightforward statement. As I wrote previously, I'm not terribly keen on having ordered unions at all. However that doesn't help the current spec. I think some possibilities are: 1) Constrain subsets to be ordered. Union the subsets in a particular order. So for example, if the subsets are {a, b, c} and {d, a} we would get {a, b, c, d}; the second 'a' gets ignored because it's already in {a, b, c}. However I'm not sure how to define an order for the subsets; Classifier::attributes order isn't sufficient as the subset may be an ownedEnd. 2) Make these properties non-unions, ie just derived. The derivation must then create a determinate total order. This is effectively (1) but makes it the modelers responsibility to determine the subset order. Dave On 20/02/13 14:28, Steve Cook wrote: > Dave > > In your example, self.p might be either {a, b} or {b, a}, but whichever it is, surely v1 = v2 (elementwise)? The indeterminacy doesn't mean that self.p somehow contains a superposition of all possible interleavings, it just means that the ordering of self.p is not fully determined from its subsets. > > However your correct observation about ExceptionHandler::output_pins is disturbing. Perhaps we do need to enforce a determinate total ordering on unions. Do you have a suggestion on what it should be? > > -- Steve > > -----Original Message----- > From: Dave Hawkins [mailto:dave.hawkins@oracle.com] > Sent: 20 February 2013 14:16 > To: Steve Cook > Cc: Manfred R. Koethe; uml25-ftf@omg.org > Subject: Re: [UML 2.5 FTF] Ballot 2 - Issue 14552 > > Steve, > > The revised text should make clear that incompatible orderings make the model invalid and ordering can be indeterminate. However I still think this is a bad idea. > > In the places I've seen ordering used, the positions of values are semantically significant. This means an indeterminate order will cause problems. Here's a simple example: > > If we have ordered property p : T, I'd expect the following to hold: > > let v1 : OrderedSet(T) = self.p, v2 : OrderedSet(T) = self.p in > Sequence{1..self.p->size()}->forAll(i | v1->at(i) = v2->at(i)) > > However, if p is a derived union with subsets px and py containing {a} and {b} respectively the following are the valid ordered collections for p: > {a, b} > {b, a} > > So it would be valid for v1 to be {a, b} and v2 to be {b, a}. The OCL would be false, but sometimes, of course, it could be true. > > In the UML metamodel the ExceptionHandler::output_pins constraint relies on a determinate order for the ordered derived union Action::output. There are subclasses of Action with multiple subsets of output, for example, AcceptCallAction (result and returnInformation), so this isn't an entirely theoretical problem. > > Dave > > On 19/02/13 17:13, Steve Cook wrote: >> Dave >> >> The UML metamodel itself contains three examples of ordered unions. We cannot outlaw them. On today's call we decided that the proposed resolution is ok. >> >> If you had mutually incompatible orderings the model would be invalid. Otherwise the ordering is indeed indeterminate in cases where the union is derived from more than one subset. >> >> Thanks >> -- Steve >> >> -----Original Message----- >> From: Dave Hawkins [mailto:dave.hawkins@oracle.com] >> Sent: 19 February 2013 14:46 >> To: Manfred R. Koethe >> Cc: uml25-ftf@omg.org >> Subject: [UML 2.5 FTF] Ballot 2 - Issue 14552 >> >> This doesn't make sense. You could have two mutually incompatible orderings. I'd also expect a sequential order to be predictable and thus total, but deriving the order means it can be a partial order or even just completely random. Derived unions just shouldn't be ordered. >> >> Dave >> >> On 17/02/13 22:27, Manfred R. Koethe wrote: >>> Dear Colleagues, >>> >>> Thank you all for reading and commenting on Ballot 2 right away. As >>> requested, and considering the early comments, I herewith change the voting period of Ballot 2 to: >>> >>> ==>> Poll start date: Monday, 25 February 2013 (01:00 AM EDT - 06:00 >>> GMT) >>> >>> ==>> Poll closing date: Sunday, 03 March 2013 (7:00 PM EDT - 24:00 >>> GMT) >>> >>> Please review the attached REVISED preview, which has changes to 12167, 17854, 17890 and 18071. >>> >>> Important: If you have comments on resolutions in Ballot 2, try to >>> be on the call next Tuesday 11:00 - 12:00 EST or delegate your comments to a call participant for discussion. Thank you. >>> >>> Kind regards, >>> >>> Manfred >>> --------------------------------------------------------------- >>> Manfred R. Koethe 88solutions Corporation >>> tel: +1 (617) 848 0525 fax: +1 (815) 550 2086 >>> mailto: koethe@88solutions.com >>> web: http://www.88solutions.com >>> --------(Model-Driven Modeling Solutions)-------- >>> >>> >>> >>> >>> >>> >>> >> >> -- >> Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. >> Company Reg. No. 1782505. >> Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. >> > > -- > Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. > Company Reg. No. 1782505. > Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. > -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. From: Ed Seidewitz To: Steve Cook CC: "uml25-ftf@omg.org" Date: Wed, 20 Feb 2013 13:27:28 -0500 Subject: RE: [UML 2.5 FTF] Ballot 2 - Issue 14552 Thread-Topic: [UML 2.5 FTF] Ballot 2 - Issue 14552 Thread-Index: AQHODq/l7edoaa2csEibedltfZ9gE5iBapNggAFhj4CAAAHDYIAAFiYAgAAJOgCAACKmMA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.226]|10.1.50.226|outbound.mailprotector.net|0.0|0.0|0|||0|0|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.226, Ugly c=0.776404 p=-0.992517 Source White X-Mailprotector-Scan-Diagnostics: 0-0-0-18043-c X-Mailprotector-ID: 17c985a5-686c-4a50-88f4-1cb0f42aa22e X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r1KIkCet017100 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Steve -- I don't think we should make it illegal to have ordered derived unions, since this would be taking away a capability that has been allowed so far. And he changes to the metamodel you suggest to compensate for taking away that capability that seem to me to be a lot for what is a relatively limited problem, in practical cases. It is not possible to make the ordering for a derived union deterministic in all cases, because it is not possible to order inherited members when there is multiple generalizations. However, we could require that the ordering of the values a derived union with multiple subset attributes respects the ordering of the attributes given by the Classifier::allAttributes() operation. This is not deterministic at least in the case of only single generalization and would resolve the problem with the ordering of outputs for actions. For the case in which a derived union has multiple subset association owned ends, we could also say that the derived union value ordering respects the ordering of association memberEnds. If we want to handle inherited ends, we could introduce an allEnds operation similar to allAttributes, but I am not sure that is really necessary, given that there is rarely any sophisticated use of association inheritance. -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Wednesday, February 20, 2013 11:30 AM To: Dave Hawkins Cc: Manfred R. Koethe; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] Ballot 2 - Issue 14552 I think we should withdraw 14552 from this ballot. Then we should raise a new issue that ExceptionHandler::output_pins is ill-defined because the ordering of /output is ill-defined. To solve this I'm leaning towards saying that derived unions shall not be ordered. Then (say) ExceptionHandler::output_pins could be defined in terms of a new operation (say orderedOutputPins()), and orderedOutputPins() would have to be redefined for different subclasses of Action. Similarly we'd have to introduce orderedAttributes() for Classifier, and possibly orderedInputs() for Action, although I haven't found anywhere that the input order matters. -- Steve -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: 20 February 2013 15:41 To: Steve Cook Cc: Manfred R. Koethe; uml25-ftf@omg.org Subject: Re: [UML 2.5 FTF] Ballot 2 - Issue 14552 Sorry, I should have added some kind of copy operation when assigning v1 and v2 to make them different elementwise. I was really trying to show that since the property is derived, it could be derived differently at different times, even including during the execution of a seemingly straightforward statement. As I wrote previously, I'm not terribly keen on having ordered unions at all. However that doesn't help the current spec. I think some possibilities are: 1) Constrain subsets to be ordered. Union the subsets in a particular order. So for example, if the subsets are {a, b, c} and {d, a} we would get {a, b, c, d}; the second 'a' gets ignored because it's already in {a, b, c}. However I'm not sure how to define an order for the subsets; Classifier::attributes order isn't sufficient as the subset may be an ownedEnd. 2) Make these properties non-unions, ie just derived. The derivation must then create a determinate total order. This is effectively (1) but makes it the modelers responsibility to determine the subset order. Dave On 20/02/13 14:28, Steve Cook wrote: > Dave > > In your example, self.p might be either {a, b} or {b, a}, but whichever it is, surely v1 = v2 (elementwise)? The indeterminacy doesn't mean that self.p somehow contains a superposition of all possible interleavings, it just means that the ordering of self.p is not fully determined from its subsets. > > However your correct observation about ExceptionHandler::output_pins is disturbing. Perhaps we do need to enforce a determinate total ordering on unions. Do you have a suggestion on what it should be? > > -- Steve > > -----Original Message----- > From: Dave Hawkins [mailto:dave.hawkins@oracle.com] > Sent: 20 February 2013 14:16 > To: Steve Cook > Cc: Manfred R. Koethe; uml25-ftf@omg.org > Subject: Re: [UML 2.5 FTF] Ballot 2 - Issue 14552 > > Steve, > > The revised text should make clear that incompatible orderings make the model invalid and ordering can be indeterminate. However I still think this is a bad idea. > > In the places I've seen ordering used, the positions of values are semantically significant. This means an indeterminate order will cause problems. Here's a simple example: > > If we have ordered property p : T, I'd expect the following to hold: > > let v1 : OrderedSet(T) = self.p, v2 : OrderedSet(T) = self.p in > Sequence{1..self.p->size()}->forAll(i | v1->at(i) = v2->at(i)) > > However, if p is a derived union with subsets px and py containing {a} and {b} respectively the following are the valid ordered collections for p: > {a, b} > {b, a} > > So it would be valid for v1 to be {a, b} and v2 to be {b, a}. The OCL would be false, but sometimes, of course, it could be true. > > In the UML metamodel the ExceptionHandler::output_pins constraint relies on a determinate order for the ordered derived union Action::output. There are subclasses of Action with multiple subsets of output, for example, AcceptCallAction (result and returnInformation), so this isn't an entirely theoretical problem. > > Dave > > On 19/02/13 17:13, Steve Cook wrote: >> Dave >> >> The UML metamodel itself contains three examples of ordered unions. We cannot outlaw them. On today's call we decided that the proposed resolution is ok. >> >> If you had mutually incompatible orderings the model would be invalid. Otherwise the ordering is indeed indeterminate in cases where the union is derived from more than one subset. >> >> Thanks >> -- Steve >> >> -----Original Message----- >> From: Dave Hawkins [mailto:dave.hawkins@oracle.com] >> Sent: 19 February 2013 14:46 >> To: Manfred R. Koethe >> Cc: uml25-ftf@omg.org >> Subject: [UML 2.5 FTF] Ballot 2 - Issue 14552 >> >> This doesn't make sense. You could have two mutually incompatible orderings. I'd also expect a sequential order to be predictable and thus total, but deriving the order means it can be a partial order or even just completely random. Derived unions just shouldn't be ordered. >> >> Dave >> >> On 17/02/13 22:27, Manfred R. Koethe wrote: >>> Dear Colleagues, >>> >>> Thank you all for reading and commenting on Ballot 2 right away. As >>> requested, and considering the early comments, I herewith change the voting period of Ballot 2 to: >>> >>> ==>> Poll start date: Monday, 25 February 2013 (01:00 AM EDT - 06:00 >>> GMT) >>> >>> ==>> Poll closing date: Sunday, 03 March 2013 (7:00 PM EDT - 24:00 >>> GMT) >>> >>> Please review the attached REVISED preview, which has changes to 12167, 17854, 17890 and 18071. >>> >>> Important: If you have comments on resolutions in Ballot 2, try to >>> be on the call next Tuesday 11:00 - 12:00 EST or delegate your comments to a call participant for discussion. Thank you. >>> >>> Kind regards, >>> >>> Manfred >>> --------------------------------------------------------------- >>> Manfred R. Koethe 88solutions Corporation >>> tel: +1 (617) 848 0525 fax: +1 (815) 550 2086 >>> mailto: koethe@88solutions.com >>> web: http://www.88solutions.com >>> --------(Model-Driven Modeling Solutions)-------- >>> >>> >>> >>> >>> >>> >>> >> >> -- >> Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. >> Company Reg. No. 1782505. >> Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. >> > > -- > Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. > Company Reg. No. 1782505. > Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. > -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. X-Symantec-TimeoutProtection: 0 From: Steve Cook To: Ed Seidewitz CC: "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] Ballot 2 - Issue 14552 Thread-Topic: [UML 2.5 FTF] Ballot 2 - Issue 14552 Thread-Index: AQHODq/l7edoaa2csEibedltfZ9gE5iBapNggAFhj4CAAAHDYIAAFiYAgAAJOgCAACKmMIAACSUA Date: Wed, 20 Feb 2013 18:56:11 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(377454001)(71364001)(479174001)(51704002)(13464002)(5403001)(199002)(189002)(31014001)(24454001)(5343655001)(74502001)(49866001)(16601075001)(74662001)(51856001)(56776001)(54316002)(56816002)(50986001)(47976001)(46102001)(50466001)(55846006)(47736001)(4396001)(46406002)(59766001)(23726001)(16796002)(77982001)(65816001)(53806001)(47446002)(79102001)(54356001)(44976002)(5343635001)(80022001)(31966008)(16406001)(15202345001)(47776003)(20776003)(33656001)(63696002)(76482001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB016;H:TK5EX14HUBC106.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07630F72AD X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r1KJ088A018065 X-Brightmail-Tracker: AAAAAA== Ed I think you inserted an unintended "not" in the final sentence of the second paragraph. I didn't understand the third paragraph - how are association-owned ends that belong to different associations ordered? I think you are on the right track for getting this resolved. I'll have a go at writing a new resolution. -- Steve -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 20 February 2013 18:27 To: Steve Cook Cc: uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] Ballot 2 - Issue 14552 Steve -- I don't think we should make it illegal to have ordered derived unions, since this would be taking away a capability that has been allowed so far. And he changes to the metamodel you suggest to compensate for taking away that capability that seem to me to be a lot for what is a relatively limited problem, in practical cases. It is not possible to make the ordering for a derived union deterministic in all cases, because it is not possible to order inherited members when there is multiple generalizations. However, we could require that the ordering of the values a derived union with multiple subset attributes respects the ordering of the attributes given by the Classifier::allAttributes() operation. This is not deterministic at least in the case of only single generalization and would resolve the problem with the ordering of outputs for actions. For the case in which a derived union has multiple subset association owned ends, we could also say that the derived union value ordering respects the ordering of association memberEnds. If we want to handle inherited ends, we could introduce an allEnds operation similar to allAttributes, but I am not sure that is really necessary, given that there is rarely any sophisticated use of association inheritance. -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Wednesday, February 20, 2013 11:30 AM To: Dave Hawkins Cc: Manfred R. Koethe; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] Ballot 2 - Issue 14552 I think we should withdraw 14552 from this ballot. Then we should raise a new issue that ExceptionHandler::output_pins is ill-defined because the ordering of /output is ill-defined. To solve this I'm leaning towards saying that derived unions shall not be ordered. Then (say) ExceptionHandler::output_pins could be defined in terms of a new operation (say orderedOutputPins()), and orderedOutputPins() would have to be redefined for different subclasses of Action. Similarly we'd have to introduce orderedAttributes() for Classifier, and possibly orderedInputs() for Action, although I haven't found anywhere that the input order matters. -- Steve -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: 20 February 2013 15:41 To: Steve Cook Cc: Manfred R. Koethe; uml25-ftf@omg.org Subject: Re: [UML 2.5 FTF] Ballot 2 - Issue 14552 Sorry, I should have added some kind of copy operation when assigning v1 and v2 to make them different elementwise. I was really trying to show that since the property is derived, it could be derived differently at different times, even including during the execution of a seemingly straightforward statement. As I wrote previously, I'm not terribly keen on having ordered unions at all. However that doesn't help the current spec. I think some possibilities are: 1) Constrain subsets to be ordered. Union the subsets in a particular order. So for example, if the subsets are {a, b, c} and {d, a} we would get {a, b, c, d}; the second 'a' gets ignored because it's already in {a, b, c}. However I'm not sure how to define an order for the subsets; Classifier::attributes order isn't sufficient as the subset may be an ownedEnd. 2) Make these properties non-unions, ie just derived. The derivation must then create a determinate total order. This is effectively (1) but makes it the modelers responsibility to determine the subset order. Dave On 20/02/13 14:28, Steve Cook wrote: > Dave > > In your example, self.p might be either {a, b} or {b, a}, but whichever it is, surely v1 = v2 (elementwise)? The indeterminacy doesn't mean that self.p somehow contains a superposition of all possible interleavings, it just means that the ordering of self.p is not fully determined from its subsets. > > However your correct observation about ExceptionHandler::output_pins is disturbing. Perhaps we do need to enforce a determinate total ordering on unions. Do you have a suggestion on what it should be? > > -- Steve > > -----Original Message----- > From: Dave Hawkins [mailto:dave.hawkins@oracle.com] > Sent: 20 February 2013 14:16 > To: Steve Cook > Cc: Manfred R. Koethe; uml25-ftf@omg.org > Subject: Re: [UML 2.5 FTF] Ballot 2 - Issue 14552 > > Steve, > > The revised text should make clear that incompatible orderings make the model invalid and ordering can be indeterminate. However I still think this is a bad idea. > > In the places I've seen ordering used, the positions of values are semantically significant. This means an indeterminate order will cause problems. Here's a simple example: > > If we have ordered property p : T, I'd expect the following to hold: > > let v1 : OrderedSet(T) = self.p, v2 : OrderedSet(T) = self.p in > Sequence{1..self.p->size()}->forAll(i | v1->at(i) = v2->at(i)) > > However, if p is a derived union with subsets px and py containing {a} and {b} respectively the following are the valid ordered collections for p: > {a, b} > {b, a} > > So it would be valid for v1 to be {a, b} and v2 to be {b, a}. The OCL would be false, but sometimes, of course, it could be true. > > In the UML metamodel the ExceptionHandler::output_pins constraint relies on a determinate order for the ordered derived union Action::output. There are subclasses of Action with multiple subsets of output, for example, AcceptCallAction (result and returnInformation), so this isn't an entirely theoretical problem. > > Dave > > On 19/02/13 17:13, Steve Cook wrote: >> Dave >> >> The UML metamodel itself contains three examples of ordered unions. We cannot outlaw them. On today's call we decided that the proposed resolution is ok. >> >> If you had mutually incompatible orderings the model would be invalid. Otherwise the ordering is indeed indeterminate in cases where the union is derived from more than one subset. >> >> Thanks >> -- Steve >> >> -----Original Message----- >> From: Dave Hawkins [mailto:dave.hawkins@oracle.com] >> Sent: 19 February 2013 14:46 >> To: Manfred R. Koethe >> Cc: uml25-ftf@omg.org >> Subject: [UML 2.5 FTF] Ballot 2 - Issue 14552 >> >> This doesn't make sense. You could have two mutually incompatible orderings. I'd also expect a sequential order to be predictable and thus total, but deriving the order means it can be a partial order or even just completely random. Derived unions just shouldn't be ordered. >> >> Dave >> >> On 17/02/13 22:27, Manfred R. Koethe wrote: >>> Dear Colleagues, >>> >>> Thank you all for reading and commenting on Ballot 2 right away. As >>> requested, and considering the early comments, I herewith change the voting period of Ballot 2 to: >>> >>> ==>> Poll start date: Monday, 25 February 2013 (01:00 AM EDT - 06:00 >>> GMT) >>> >>> ==>> Poll closing date: Sunday, 03 March 2013 (7:00 PM EDT - 24:00 >>> GMT) >>> >>> Please review the attached REVISED preview, which has changes to 12167, 17854, 17890 and 18071. >>> >>> Important: If you have comments on resolutions in Ballot 2, try to >>> be on the call next Tuesday 11:00 - 12:00 EST or delegate your comments to a call participant for discussion. Thank you. >>> >>> Kind regards, >>> >>> Manfred >>> --------------------------------------------------------------- >>> Manfred R. Koethe 88solutions Corporation >>> tel: +1 (617) 848 0525 fax: +1 (815) 550 2086 >>> mailto: koethe@88solutions.com >>> web: http://www.88solutions.com >>> --------(Model-Driven Modeling Solutions)-------- >>> >>> >>> >>> >>> >>> >>> >> >> -- >> Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. >> Company Reg. No. 1782505. >> Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. >> > > -- > Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. > Company Reg. No. 1782505. > Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. > -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. From: Ed Seidewitz To: Steve Cook CC: "uml25-ftf@omg.org" Date: Wed, 20 Feb 2013 17:36:55 -0500 Subject: RE: [UML 2.5 FTF] Ballot 2 - Issue 14552 Thread-Topic: [UML 2.5 FTF] Ballot 2 - Issue 14552 Thread-Index: AQHODq/l7edoaa2csEibedltfZ9gE5iBapNggAFhj4CAAAHDYIAAFiYAgAAJOgCAACKmMIAACSUAgAA9ZKA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.226]|10.1.50.226|outbound.mailprotector.net|0.0|0.0|0|||0|0|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.226, Ugly c=0.80827 p=-0.9898 Source White X-Mailprotector-Scan-Diagnostics: 0-0-0-20793-c X-Mailprotector-ID: 90e5a53d-6ea8-4b45-a684-974f432c9274 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r1KMbsXM004158 Steve -- Ignore the third paragraph. I was thinking that the subsetting context for an association end was the association, but of course it is not, it is the opposite end type. So it may not be possible to come up with a deterministic ordering of association-owned ends relative to the attributes of the classifier that is the subsetting context for those ends. But I don't think this is really a big problem, as long as we are clear about it -- if you want the ordering to be deterministic, use owned ends and limit yourself to single generalization. -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Wednesday, February 20, 2013 1:56 PM To: Ed Seidewitz Cc: uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] Ballot 2 - Issue 14552 Ed I think you inserted an unintended "not" in the final sentence of the second paragraph. I didn't understand the third paragraph - how are association-owned ends that belong to different associations ordered? I think you are on the right track for getting this resolved. I'll have a go at writing a new resolution. -- Steve -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 20 February 2013 18:27 To: Steve Cook Cc: uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] Ballot 2 - Issue 14552 Steve -- I don't think we should make it illegal to have ordered derived unions, since this would be taking away a capability that has been allowed so far. And he changes to the metamodel you suggest to compensate for taking away that capability that seem to me to be a lot for what is a relatively limited problem, in practical cases. It is not possible to make the ordering for a derived union deterministic in all cases, because it is not possible to order inherited members when there is multiple generalizations. However, we could require that the ordering of the values a derived union with multiple subset attributes respects the ordering of the attributes given by the Classifier::allAttributes() operation. This is not deterministic at least in the case of only single generalization and would resolve the problem with the ordering of outputs for actions. For the case in which a derived union has multiple subset association owned ends, we could also say that the derived union value ordering respects the ordering of association memberEnds. If we want to handle inherited ends, we could introduce an allEnds operation similar to allAttributes, but I am not sure that is really necessary, given that there is rarely any sophisticated use of association inheritance. -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Wednesday, February 20, 2013 11:30 AM To: Dave Hawkins Cc: Manfred R. Koethe; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] Ballot 2 - Issue 14552 I think we should withdraw 14552 from this ballot. Then we should raise a new issue that ExceptionHandler::output_pins is ill-defined because the ordering of /output is ill-defined. To solve this I'm leaning towards saying that derived unions shall not be ordered. Then (say) ExceptionHandler::output_pins could be defined in terms of a new operation (say orderedOutputPins()), and orderedOutputPins() would have to be redefined for different subclasses of Action. Similarly we'd have to introduce orderedAttributes() for Classifier, and possibly orderedInputs() for Action, although I haven't found anywhere that the input order matters. -- Steve -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: 20 February 2013 15:41 To: Steve Cook Cc: Manfred R. Koethe; uml25-ftf@omg.org Subject: Re: [UML 2.5 FTF] Ballot 2 - Issue 14552 Sorry, I should have added some kind of copy operation when assigning v1 and v2 to make them different elementwise. I was really trying to show that since the property is derived, it could be derived differently at different times, even including during the execution of a seemingly straightforward statement. As I wrote previously, I'm not terribly keen on having ordered unions at all. However that doesn't help the current spec. I think some possibilities are: 1) Constrain subsets to be ordered. Union the subsets in a particular order. So for example, if the subsets are {a, b, c} and {d, a} we would get {a, b, c, d}; the second 'a' gets ignored because it's already in {a, b, c}. However I'm not sure how to define an order for the subsets; Classifier::attributes order isn't sufficient as the subset may be an ownedEnd. 2) Make these properties non-unions, ie just derived. The derivation must then create a determinate total order. This is effectively (1) but makes it the modelers responsibility to determine the subset order. Dave On 20/02/13 14:28, Steve Cook wrote: > Dave > > In your example, self.p might be either {a, b} or {b, a}, but whichever it is, surely v1 = v2 (elementwise)? The indeterminacy doesn't mean that self.p somehow contains a superposition of all possible interleavings, it just means that the ordering of self.p is not fully determined from its subsets. > > However your correct observation about ExceptionHandler::output_pins is disturbing. Perhaps we do need to enforce a determinate total ordering on unions. Do you have a suggestion on what it should be? > > -- Steve > > -----Original Message----- > From: Dave Hawkins [mailto:dave.hawkins@oracle.com] > Sent: 20 February 2013 14:16 > To: Steve Cook > Cc: Manfred R. Koethe; uml25-ftf@omg.org > Subject: Re: [UML 2.5 FTF] Ballot 2 - Issue 14552 > > Steve, > > The revised text should make clear that incompatible orderings make the model invalid and ordering can be indeterminate. However I still think this is a bad idea. > > In the places I've seen ordering used, the positions of values are semantically significant. This means an indeterminate order will cause problems. Here's a simple example: > > If we have ordered property p : T, I'd expect the following to hold: > > let v1 : OrderedSet(T) = self.p, v2 : OrderedSet(T) = self.p in > Sequence{1..self.p->size()}->forAll(i | v1->at(i) = v2->at(i)) > > However, if p is a derived union with subsets px and py containing {a} and {b} respectively the following are the valid ordered collections for p: > {a, b} > {b, a} > > So it would be valid for v1 to be {a, b} and v2 to be {b, a}. The OCL would be false, but sometimes, of course, it could be true. > > In the UML metamodel the ExceptionHandler::output_pins constraint relies on a determinate order for the ordered derived union Action::output. There are subclasses of Action with multiple subsets of output, for example, AcceptCallAction (result and returnInformation), so this isn't an entirely theoretical problem. > > Dave > > On 19/02/13 17:13, Steve Cook wrote: >> Dave >> >> The UML metamodel itself contains three examples of ordered unions. We cannot outlaw them. On today's call we decided that the proposed resolution is ok. >> >> If you had mutually incompatible orderings the model would be invalid. Otherwise the ordering is indeed indeterminate in cases where the union is derived from more than one subset. >> >> Thanks >> -- Steve >> >> -----Original Message----- >> From: Dave Hawkins [mailto:dave.hawkins@oracle.com] >> Sent: 19 February 2013 14:46 >> To: Manfred R. Koethe >> Cc: uml25-ftf@omg.org >> Subject: [UML 2.5 FTF] Ballot 2 - Issue 14552 >> >> This doesn't make sense. You could have two mutually incompatible orderings. I'd also expect a sequential order to be predictable and thus total, but deriving the order means it can be a partial order or even just completely random. Derived unions just shouldn't be ordered. >> >> Dave >> >> On 17/02/13 22:27, Manfred R. Koethe wrote: >>> Dear Colleagues, >>> >>> Thank you all for reading and commenting on Ballot 2 right away. As >>> requested, and considering the early comments, I herewith change the voting period of Ballot 2 to: >>> >>> ==>> Poll start date: Monday, 25 February 2013 (01:00 AM EDT - 06:00 >>> GMT) >>> >>> ==>> Poll closing date: Sunday, 03 March 2013 (7:00 PM EDT - 24:00 >>> GMT) >>> >>> Please review the attached REVISED preview, which has changes to 12167, 17854, 17890 and 18071. >>> >>> Important: If you have comments on resolutions in Ballot 2, try to >>> be on the call next Tuesday 11:00 - 12:00 EST or delegate your comments to a call participant for discussion. Thank you. >>> >>> Kind regards, >>> >>> Manfred >>> --------------------------------------------------------------- >>> Manfred R. Koethe 88solutions Corporation >>> tel: +1 (617) 848 0525 fax: +1 (815) 550 2086 >>> mailto: koethe@88solutions.com >>> web: http://www.88solutions.com >>> --------(Model-Driven Modeling Solutions)-------- >>> >>> >>> >>> >>> >>> >>> >> >> -- >> Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. >> Company Reg. No. 1782505. >> Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. >> > > -- > Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. > Company Reg. No. 1782505. > Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. > -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.