Issue 17492: Section B5.2 (canonical-xmi-ftf) Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com) Nature: Uncategorized Issue Severity: Summary: This imposes an alphabetic order on the superclasses that isn't mentioned in the main specification for the superClassFirst option. It isn't clear to me what this is ordered on. It can't just be the name of the superclass, because there could be multiple superclasses with the same name. It's also a very complicated way to order the properties that will almost certainly be inconsistent with the way the metamodel is defined. Why not just sort the properties alphabetically by name? Resolution: Revised Text: Actions taken: July 13, 2012: received issue Discussion: End of Annotations:===== s is issue # 17492 From: Dave Hawkins Section B5.2 This imposes an alphabetic order on the superclasses that isn't mentioned in the main specification for the superClassFirst option. It isn't clear to me what this is ordered on. It can't just be the name of the superclass, because there could be multiple superclasses with the same name. It's also a very complicated way to order the properties that will almost certainly be inconsistent with the way the metamodel is defined. Why not just sort the properties alphabetically by name? From: "Rouquette, Nicolas F (313K)" To: Pete Rivett , "canonical-xmi-ftf@omg.org" CC: "Roy_M_Bell@raytheon.com" , "koethe@88solutions.com" Subject: Re: Canonical XMI FTF - Ballot 1 - Please Vote Now Thread-Topic: Canonical XMI FTF - Ballot 1 - Please Vote Now Thread-Index: Ac6apk40HeN0L4QgRF6u1SgqmDlIcgAADtSQAHjNFYA= Date: Mon, 19 Aug 2013 03:11:06 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org NASA votes NO on 17492 and 17494 and YES on all other resolutions in this ballot. Justifications follow: 17492: No Saying that "completely predictable order is not important for the main XMI specification" seems completely contradictory with the purpose of the Canonical XMI spec per B.1. Suggest deferring this issue instead as follows: Given that Canonical XMI provides more predictable identification and ordering, ensuring predictable ordering in B.5.2 for superclasses is left for consideration for future RTFs. 17494: No The resolution argues that requiring uuids to be URIs would be too large a change for this RTF. First, this is an FTF, not an RTF. Second, if the change is too large for this FTF, will future RTF be even more constrained in terms of what they can change compared to this FTF? Third, the resolution contradicts the Canonical XMI spec, B.6: Canonical XMI does not constrain the values to be used for xmi:uuids, since these represent a persistent and generally available identity. However the use of the MOF2 Facility Basic Encoding Scheme is strongly encouraged. Suggest deferring this issue as follows: Given that Canonical XMI does not constraint the values to be used for xmi:uuids, requiring such values to be URIs is left for consideration for future RTFs. - Nicolas. From: Pete Adaptive Date: Friday, August 16, 2013 10:32 AM To: Pete Adaptive , "canonical-xmi-ftf@omg.org" Cc: Roy M , Manfred Koethe Subject: RE: Canonical XMI FTF - Ballot 1 - Please Vote Now Adaptive votes YES to all the proposed resolutions in this ballot. Pete -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 9861 Irvine Center Drive Suite 200, Irvine, CA 92618 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, August 16, 2013 10:31 AM To: canonical-xmi-ftf@omg.org Cc: Roy_M_Bell@raytheon.com; koethe@88solutions.com Subject: Canonical XMI FTF - Ballot 1 - Please Vote Now Importance: High The attached ballot is as per the draft: I have held back the 3 issues without resolutions for another ballot (but thanks for the suggestions Simon). There are 20 issues in this ballot. THE BALLOT ENDS ON SUNDAY 25th AUGUST AT 5PM PACIFIC The voting list is as follows: -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 9861 Irvine Center Drive Suite 200, Irvine, CA 92618 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp Subject: RE: Canonical XMI FTF - Ballot 1 - Please Vote Now Date: Sun, 18 Aug 2013 21:36:33 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Canonical XMI FTF - Ballot 1 - Please Vote Now Thread-Index: Ac6apk40HeN0L4QgRF6u1SgqmDlIcgAADtSQAHjNFYAAAlA/YA== From: "Pete Rivett" To: "Rouquette, Nicolas F (313K)" , Cc: , X-Virus-Scanned: amavisd-new at omg.org Ø Saying that "completely predictable order is not important for the main XMI specification" seems completely contradictory with the purpose of the Canonical XMI spec per B.1. The resolution states that it.s OK for Canonical XMI to have a completely predictable ordering for superclasses despite such predictability not being important for the main XMI spec: i.e. that Canonical XMI is more rigorous. The issue was not complaining about predictability of ordering in Canonical XMI so your alternative proposal about B.5.2 changing in future RTFs does not make sense . the only thing that would have to change is the description of superclassFirst in the main XMI spec. Because of that it would be under the purview of the XMI RTF, not the Canonical XMI FTF . so the issue would have to be re-raised or transferred. Ø First, this is an FTF, not an RTF. Oops, you.re right. Ø Third, the resolution contradicts the Canonical XMI spec, B.6: Ø Canonical XMI does not constrain the values to be used for xmi:uuids, since these represent a persistent and generally available identity. However the use of the MOF2 Facility Basic Encoding Scheme is strongly encouraged. I don.t see the contradiction: in fact adopting the proposal in the Issue and constraining uuids to be URIs would be the contradiction! Ø Suggest deferring this issue as follows: Ø Given that Canonical XMI does not constraint the values to be used for xmi:uuids, requiring such values to be URIs is left for consideration for future RTFs. Hmm that.s pretty much what the proposed resolution does already say . the Disposition already is Deferred. Hope that clarifies things; please reconsider your NO votes, at least on the 2nd one where the proposal is almost identical to your suggestion. Pete From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Sunday, August 18, 2013 8:11 PM To: Pete Rivett; canonical-xmi-ftf@omg.org Cc: Roy_M_Bell@raytheon.com; koethe@88solutions.com Subject: Re: Canonical XMI FTF - Ballot 1 - Please Vote Now NASA votes NO on 17492 and 17494 and YES on all other resolutions in this ballot. Justifications follow: 17492: No Saying that "completely predictable order is not important for the main XMI specification" seems completely contradictory with the purpose of the Canonical XMI spec per B.1. Suggest deferring this issue instead as follows: Given that Canonical XMI provides more predictable identification and ordering, ensuring predictable ordering in B.5.2 for superclasses is left for consideration for future RTFs. 17494: No The resolution argues that requiring uuids to be URIs would be too large a change for this RTF. First, this is an FTF, not an RTF. Second, if the change is too large for this FTF, will future RTF be even more constrained in terms of what they can change compared to this FTF? Third, the resolution contradicts the Canonical XMI spec, B.6: Canonical XMI does not constrain the values to be used for xmi:uuids, since these represent a persistent and generally available identity. However the use of the MOF2 Facility Basic Encoding Scheme is strongly encouraged. Suggest deferring this issue as follows: Given that Canonical XMI does not constraint the values to be used for xmi:uuids, requiring such values to be URIs is left for consideration for future RTFs. - Nicolas. From: Pete Adaptive Date: Friday, August 16, 2013 10:32 AM To: Pete Adaptive , "canonical-xmi-ftf@omg.org" Cc: Roy M , Manfred Koethe Subject: RE: Canonical XMI FTF - Ballot 1 - Please Vote Now Adaptive votes YES to all the proposed resolutions in this ballot. Pete -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 9861 Irvine Center Drive Suite 200, Irvine, CA 92618 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, August 16, 2013 10:31 AM To: canonical-xmi-ftf@omg.org Cc: Roy_M_Bell@raytheon.com; koethe@88solutions.com Subject: Canonical XMI FTF - Ballot 1 - Please Vote Now Importance: High The attached ballot is as per the draft: I have held back the 3 issues without resolutions for another ballot (but thanks for the suggestions Simon). There are 20 issues in this ballot. THE BALLOT ENDS ON SUNDAY 25th AUGUST AT 5PM PACIFIC The voting list is as follows: -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 9861 Irvine Center Drive Suite 200, Irvine, CA 92618 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp image001.png image001.png