Issue 9171: Introduction and oclType() (ocl2-rtf) Source: SAP SE (Mr. Murray Spork, nobody) Nature: Uncategorized Issue Severity: Summary: I only recently joined the OCL rtf at the request of David Frankel (who is now with SAP) - I have not seen any activity on this mailing list as yet so I hope this is an appropriate forum to raise this question. First let me introduce myself - I am lead for a proof-of-concept project investigating the use of OCL to express integrity constraints on models. Hopefully I will get a chance next year to attend a f2f meeting so that I can meet you all. On to my specific question: we have noticed that some time between OCL 1.1 and UML 1.4 "oclType", as a predefined feature, was removed. (I have been unable to find any versions of OCL between 1.1 and UML 1.4). I thought it would be best if we found out whether this removal was intentional before officially raising it as an issue. The reason is that we find a) this is a useful reflective feature to have and 2) it is still used in some current OMG specifications (note that it is used inconsistently). e.g.: - UML2 Infrastructure - (ptc/03-09-15) pg.89: Classifier::maySpecializeType(c : Classifier) : Boolean; maySpecializeType = self.oclIsKindOf(c.oclType) - Meta Object Facility (MOF) 2.0 Core Specification (ptc/03-10-04) - pg.68 ExtentImpl::addObject(ObjectInstance o, String suppliedId [0..1]): String pre: not(self.entry.identifier includes suppliedId) post: oclIsNew(e) and oclType(e) = IdentifierEntry and e.object = o and self.entry includes e self.entry->select(ex | ex.identifier = e.identifier)->size() = 1 -- the new id is unique and (suppliedId <> null implies e.identifier = suppliedId) Resolution: Revised Text: Add an operation definition to Section 11.2.5 Operations and Well-formedness rules, in the OclAny subsection: oclType() : Classifier Evaluates to the type of which self is an instance. post: self.oclIsTypeOf(result) Actions taken: November 13, 2005: received issue October 16, 2009: closed issue Discussion: It appears that oclType was removed because MOF reflection provides the Element::getMetaClass() to obtain the metaclass of a model element. However, this is insufficient for three reasons: 1.Element in MOF is defined at the metamodeling level. OCL constraints in a model are defined at the modeling level and, therefore, constrain the run-time instances of the classes described by the model. These Classes do not inherit Element. 2.The UML Infrastructure does not merge the Reflection capability from MOF. Therefore, the UML metamodel cannot use Element::getMetaClass() in its own OCL constraints (to constrain UML models). 3.The result of Element::getMetaClass() is Class, which is the metatype for metaclasses, not Type. Thus, it would not be applicable to the values of DataTypes. For these reasons, OCL must define its own reflection capability for models (not metamodels). This is consistent with the oclIsKindOf and oclAsType. Also, it seems more natural to define it as an operation as MOF does with getMetaClass() than as an attribute End of Annotations:===== ubject: Introduction and oclType() Date: Mon, 14 Nov 2005 07:41:14 +0800 Thread-Topic: Introduction and oclType() Thread-Index: AcXoq7xubzDkEqYKRwyGxs1HYw/7WA== From: "Spork, Murray" To: X-OriginalArrivalTime: 13 Nov 2005 23:41:42.0492 (UTC) FILETIME=[CCEAD1C0:01C5E8AB] X-SAP: out X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id jADNbiPw010556 Hi all, I only recently joined the OCL rtf at the request of David Frankel (who is now with SAP) - I have not seen any activity on this mailing list as yet so I hope this is an appropriate forum to raise this question. First let me introduce myself - I am lead for a proof-of-concept project investigating the use of OCL to express integrity constraints on models. Hopefully I will get a chance next year to attend a f2f meeting so that I can meet you all. On to my specific question: we have noticed that some time between OCL 1.1 and UML 1.4 "oclType", as a predefined feature, was removed. (I have been unable to find any versions of OCL between 1.1 and UML 1.4). I thought it would be best if we found out whether this removal was intentional before officially raising it as an issue. The reason is that we find a) this is a useful reflective feature to have and 2) it is still used in some current OMG specifications (note that it is used inconsistently). e.g.: - UML2 Infrastructure - (ptc/03-09-15) pg.89: Classifier::maySpecializeType(c : Classifier) : Boolean; maySpecializeType = self.oclIsKindOf(c.oclType) - Meta Object Facility (MOF) 2.0 Core Specification (ptc/03-10-04) - pg.68 ExtentImpl::addObject(ObjectInstance o, String suppliedId [0..1]): String pre: not(self.entry.identifier includes suppliedId) post: oclIsNew(e) and oclType(e) = IdentifierEntry and e.object = o and self.entry includes e self.entry->select(ex | ex.identifier = e.identifier)->size() = 1 -- the new id is unique and (suppliedId <> null implies e.identifier = suppliedId) Regards, -- Murray Spork Senior Researcher SAP Research Centre Brisbane SAP Australia Pty Ltd. 133 Mary St., Brisbane QLD 4000, Australia T +61 7 3259 9591 F +61 7 3259 9599 M +61 409 778 383 E murray.spork@sap.com http://www.sap.com/research Subject: RE: Introduction and oclType() Date: Mon, 14 Nov 2005 04:36:12 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Introduction and oclType() Thread-Index: AcXoq7xubzDkEqYKRwyGxs1HYw/7WAAa/0Kg From: "Karl Frank" To: "Spork, Murray" , X-OriginalArrivalTime: 14 Nov 2005 12:35:17.0664 (UTC) FILETIME=[DE840200:01C5E917] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id jAECWjYE014132 would oclIsTypeOf() and oclIsKindOf() help you in this context? - Karl Frank -----Original Message----- From: Spork, Murray [mailto:murray.spork@sap.com] Sent: Sunday, November 13, 2005 3:41 PM To: ocl2-rtf@omg.org Subject: Introduction and oclType() Hi all, I only recently joined the OCL rtf at the request of David Frankel (who is now with SAP) - I have not seen any activity on this mailing list as yet so I hope this is an appropriate forum to raise this question. First let me introduce myself - I am lead for a proof-of-concept project investigating the use of OCL to express integrity constraints on models. Hopefully I will get a chance next year to attend a f2f meeting so that I can meet you all. On to my specific question: we have noticed that some time between OCL 1.1 and UML 1.4 "oclType", as a predefined feature, was removed. (I have been unable to find any versions of OCL between 1.1 and UML 1.4). I thought it would be best if we found out whether this removal was intentional before officially raising it as an issue. The reason is that we find a) this is a useful reflective feature to have and 2) it is still used in some current OMG specifications (note that it is used inconsistently). e.g.: - UML2 Infrastructure - (ptc/03-09-15) pg.89: Classifier::maySpecializeType(c : Classifier) : Boolean; maySpecializeType = self.oclIsKindOf(c.oclType) - Meta Object Facility (MOF) 2.0 Core Specification (ptc/03-10-04) - pg.68 ExtentImpl::addObject(ObjectInstance o, String suppliedId [0..1]): String pre: not(self.entry.identifier includes suppliedId) post: oclIsNew(e) and oclType(e) = IdentifierEntry and e.object = o and self.entry includes e self.entry->select(ex | ex.identifier = e.identifier)->size() = 1 -- the new id is unique and (suppliedId <> null implies e.identifier = suppliedId) Regards, -- Murray Spork Senior Researcher SAP Research Centre Brisbane SAP Australia Pty Ltd. 133 Mary St., Brisbane QLD 4000, Australia T +61 7 3259 9591 F +61 7 3259 9599 M +61 409 778 383 E murray.spork@sap.com http://www.sap.com/research Subject: RE: Introduction and oclType() Date: Mon, 14 Nov 2005 21:15:10 +0800 Thread-Topic: Introduction and oclType() Thread-Index: AcXoq7xubzDkEqYKRwyGxs1HYw/7WAAa/0KgAADcKmA= From: "Spork, Murray" To: "Karl Frank" , X-OriginalArrivalTime: 14 Nov 2005 13:15:09.0661 (UTC) FILETIME=[7041C8D0:01C5E91D] X-SAP: out X-SAP: out X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id jAEDBV9T014484 Hi Frank, Thanks for the response. The problem is, with only oclIsTypeOf and oclIsKindOf at your disposal, you cannot query a model for some object, and then use the type of the result object from this query as a parameter to another operation - such as oclIsKindOf - or the equality operation such as in the example below. How else might I express a constraint such as [C-7] SupertypeKindMustBeSame in MOF 1.4?: context GeneralizableElement inv: self.supertypes -> forAll(s | s.oclType() = self.oclType()) Cheers, Murray > -----Original Message----- > From: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Monday, 14 November 2005 1:36 PM > To: Spork, Murray; ocl2-rtf@omg.org > Subject: RE: Introduction and oclType() > > would oclIsTypeOf() and oclIsKindOf() help you in this context? > > - Karl Frank > > -----Original Message----- > From: Spork, Murray [mailto:murray.spork@sap.com] > Sent: Sunday, November 13, 2005 3:41 PM > To: ocl2-rtf@omg.org > Subject: Introduction and oclType() > > > Hi all, > > I only recently joined the OCL rtf at the request of David > Frankel (who > is now with SAP) - I have not seen any activity on this > mailing list as > yet so I hope this is an appropriate forum to raise this question. > > First let me introduce myself - I am lead for a > proof-of-concept project > investigating the use of OCL to express integrity constraints > on models. > Hopefully I will get a chance next year to attend a f2f > meeting so that > I can meet you all. > > On to my specific question: we have noticed that some time between OCL > 1.1 and UML 1.4 "oclType", as a predefined feature, was > removed. (I have > been unable to find any versions of OCL between 1.1 and UML 1.4). > > I thought it would be best if we found out whether this removal was > intentional before officially raising it as an issue. The > reason is that > we find a) this is a useful reflective feature to have and 2) it is > still used in some current OMG specifications (note that it is used > inconsistently). > e.g.: > - UML2 Infrastructure - (ptc/03-09-15) pg.89: > Classifier::maySpecializeType(c : Classifier) : Boolean; > maySpecializeType = self.oclIsKindOf(c.oclType) > > - Meta Object Facility (MOF) 2.0 Core Specification (ptc/03-10-04) - > pg.68 > ExtentImpl::addObject(ObjectInstance o, String suppliedId > [0..1]): String > pre: not(self.entry.identifier includes suppliedId) > post: oclIsNew(e) and oclType(e) = IdentifierEntry and > e.object = o and > self.entry includes e > self.entry->select(ex | ex.identifier = e.identifier)->size() = > 1 -- the new id is unique and > (suppliedId <> null implies e.identifier = suppliedId) > > Regards, > > -- > Murray Spork > Senior Researcher > SAP Research Centre Brisbane > SAP Australia Pty Ltd. > 133 Mary St., Brisbane QLD 4000, Australia > T +61 7 3259 9591 > F +61 7 3259 9599 > M +61 409 778 383 > E murray.spork@sap.com > http://www.sap.com/research > Subject: RE: Introduction and oclType() Date: Mon, 14 Nov 2005 16:11:31 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Introduction and oclType() Thread-Index: AcXoq7xubzDkEqYKRwyGxs1HYw/7WAAflwVA From: "BELAUNDE Mariano RD-MAPS-LAN" To: "Spork, Murray" , X-OriginalArrivalTime: 14 Nov 2005 15:11:32.0110 (UTC) FILETIME=[B21EF2E0:01C5E92D] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id jAEF7qNo016331 Hi Murray, First of all, welcome to the OCL RTF. We didn't yet started our activity but we will start as soon as possible since we still have a lot of issues that could not be adressed during the FTF. Regarding the question you raise, I don't know what was the rationale for removing the generic 'oclType' feature when going from OCL1 to OCL2. Anyway, thanks to MOF2 reflection, the invariant "SupertypeKindMustBeSame" can now be re-written in the Following way: context GeneralizableElement inv: self.supertypes -> forAll(s | s.getMetaClass() = self.getMetaClass()) However effective availability of MOF reflection in OCL2 modules is currently an issue since the MOF Reflection is only an optional Package in MOF and hence in UML. Also the way how MOF reflective types relate to the type of the arguments of oclIsKindOf and oclIsTypeOf operations also need to be clarified. So I would suggest you raise the issue anyway. Yours, Mariano -----Message d'origine----- De : Spork, Murray [mailto:murray.spork@sap.com] Envoyé : lundi 14 novembre 2005 00:41 À : ocl2-rtf@omg.org Objet : Introduction and oclType() Hi all, I only recently joined the OCL rtf at the request of David Frankel (who is now with SAP) - I have not seen any activity on this mailing list as yet so I hope this is an appropriate forum to raise this question. First let me introduce myself - I am lead for a proof-of-concept project investigating the use of OCL to express integrity constraints on models. Hopefully I will get a chance next year to attend a f2f meeting so that I can meet you all. On to my specific question: we have noticed that some time between OCL 1.1 and UML 1.4 "oclType", as a predefined feature, was removed. (I have been unable to find any versions of OCL between 1.1 and UML 1.4). I thought it would be best if we found out whether this removal was intentional before officially raising it as an issue. The reason is that we find a) this is a useful reflective feature to have and 2) it is still used in some current OMG specifications (note that it is used inconsistently). e.g.: - UML2 Infrastructure - (ptc/03-09-15) pg.89: Classifier::maySpecializeType(c : Classifier) : Boolean; maySpecializeType = self.oclIsKindOf(c.oclType) - Meta Object Facility (MOF) 2.0 Core Specification (ptc/03-10-04) - pg.68 ExtentImpl::addObject(ObjectInstance o, String suppliedId [0..1]): String pre: not(self.entry.identifier includes suppliedId) post: oclIsNew(e) and oclType(e) = IdentifierEntry and e.object = o and self.entry includes e self.entry->select(ex | ex.identifier = e.identifier)->size() = 1 -- the new id is unique and (suppliedId <> null implies e.identifier = suppliedId) Regards, -- Murray Spork Senior Researcher SAP Research Centre Brisbane SAP Australia Pty Ltd. 133 Mary St., Brisbane QLD 4000, Australia T +61 7 3259 9591 F +61 7 3259 9599 M +61 409 778 383 E murray.spork@sap.com http://www.sap.com/research Subject: RE: Introduction and oclType() Date: Mon, 14 Nov 2005 07:26:13 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Introduction and oclType() Thread-Index: AcXoq7xubzDkEqYKRwyGxs1HYw/7WAAflwVAAAEQ3NA= From: "Pete Rivett" To: "BELAUNDE Mariano RD-MAPS-LAN" , "Spork, Murray" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id jAEFLk3F016637 > Regarding the question you raise, I don't know what was the > rationale for removing the generic 'oclType' feature when > going from OCL1 to OCL2. I think the reason is bound up in resolution to issue 6531: this reflects a move away from treating OCLtype as a sort-of enumeration. An alternative proposal, to treat it as a powertype is in issue 6532 which was deferred to the RTF. Though the approach you suggest also seems reasonable. > However effective availability of MOF reflection in OCL2 > modules is currently an issue since the MOF Reflection is > only an optional Package in MOF and hence in UML. Not quite: Reflection is mandatory in MOF (both EMOF and CMOF); however it's not mandatory for UML tools to support Reflection (compliance with UML does not require compliance with MOF). However I'm not sure this is an issue specific to oclType() since a number of other OCL capabilities in effect require reflection (though less explicitly): for example navigating a non-navigable property by using the opposite classname. Regards Pete > -----Original Message----- > From: BELAUNDE Mariano RD-MAPS-LAN > [mailto:mariano.belaunde@francetelecom.com] > Sent: Monday, November 14, 2005 3:12 PM > To: Spork, Murray; ocl2-rtf@omg.org > Subject: RE: Introduction and oclType() > > Hi Murray, > > First of all, welcome to the OCL RTF. We didn't yet started > our activity but we will start as soon as possible since we > still have a lot of issues that could not be adressed during > the FTF. > > Regarding the question you raise, I don't know what was the > rationale for removing the generic 'oclType' feature when > going from OCL1 to OCL2. > Anyway, thanks to MOF2 reflection, the invariant > "SupertypeKindMustBeSame" can now be re-written in the > Following way: > > context GeneralizableElement > inv: self.supertypes > -> forAll(s | s.getMetaClass() = self.getMetaClass()) > > However effective availability of MOF reflection in OCL2 > modules is currently an issue since the MOF Reflection is > only an optional Package in MOF and hence in UML. > > Also the way how MOF reflective types relate to the type of > the arguments of oclIsKindOf and oclIsTypeOf operations also > need to be clarified. So I would suggest you raise the issue > anyway. > > Yours, > Mariano > > -----Message d'origine----- > De : Spork, Murray [mailto:murray.spork@sap.com] > Envoyé : lundi 14 novembre 2005 00:41 > À : ocl2-rtf@omg.org > Objet : Introduction and oclType() > > > Hi all, > > I only recently joined the OCL rtf at the request of David > Frankel (who is now with SAP) - I have not seen any activity > on this mailing list as yet so I hope this is an appropriate > forum to raise this question. > > First let me introduce myself - I am lead for a > proof-of-concept project investigating the use of OCL to > express integrity constraints on models. > Hopefully I will get a chance next year to attend a f2f > meeting so that I can meet you all. > > On to my specific question: we have noticed that some time between OCL > 1.1 and UML 1.4 "oclType", as a predefined feature, was > removed. (I have been unable to find any versions of OCL > between 1.1 and UML 1.4). > > I thought it would be best if we found out whether this > removal was intentional before officially raising it as an > issue. The reason is that we find a) this is a useful > reflective feature to have and 2) it is still used in some > current OMG specifications (note that it is used inconsistently). > e.g.: > - UML2 Infrastructure - (ptc/03-09-15) pg.89: > Classifier::maySpecializeType(c : Classifier) : Boolean; > maySpecializeType = self.oclIsKindOf(c.oclType) > > - Meta Object Facility (MOF) 2.0 Core Specification (ptc/03-10-04) - > pg.68 > ExtentImpl::addObject(ObjectInstance o, String suppliedId > [0..1]): String > pre: not(self.entry.identifier includes suppliedId) > post: oclIsNew(e) and oclType(e) = IdentifierEntry and > e.object = o and > self.entry includes e > self.entry->select(ex | ex.identifier = e.identifier)->size() = > 1 -- the new id is unique and > (suppliedId <> null implies e.identifier = suppliedId) > > Regards, > > -- > Murray Spork > Senior Researcher > SAP Research Centre Brisbane > SAP Australia Pty Ltd. > 133 Mary St., Brisbane QLD 4000, Australia > T +61 7 3259 9591 > F +61 7 3259 9599 > M +61 409 778 383 > E murray.spork@sap.com > http://www.sap.com/research Subject: Feedback on issues from 8663 to 12485 Date: Thu, 9 Oct 2008 16:04:37 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback on issues from 8663 to 12485 thread-index: AckqF/bHnUBqNPt8Ry6DkAvW50hUEQ== From: To: X-OriginalArrivalTime: 09 Oct 2008 14:04:41.0376 (UTC) FILETIME=[F9688200:01C92A17] Hi all, Continuing with my feedback on the proposed resolutions, here is my feedback for the rest of the issues from Christian document (from 8663 to 12485) >>> Issue 8663: Section: 11.9.1 exists Agree (No change, misunderstanding) >>> Issue 8664: Section: 11.9.1 reject Agree (No change, misunderstanding) >>> Issue 8787: The spec does not describes the syntax of integer, real or string literals Agree (Adding some text in 9.3 Concrete Syntax section). >>> Issue 8790: OclAny cannot be an instance of Classifier Agree (Closed, Already resolved) >>> Issue 8818: Reusing TypedElement for UnspecifiedValueExp Agree (Closed, Already resolved) >>> Issue 10787: OCL Collections applied to Properties Agree (No change) >>> Issue 8917: allInstances Agree (Adjusting the description text of allInstances) >>> Issue 8937: Notation for accessing class operations is inconsistent Agree (clarifying allInstance is not static) >>> Issue 9171: Introduction and oclType() Strongly agree. But the exact wording of teh resolution will depend on resolution of issue 6532 Notice that EssentialOcl merges the reflection MOF capability. However its true that getMetaClass() is not applicable to the values of DataTypes since it returns a Class. >>> Issue 9405: Wrong subtyping of PropertyCallExp and NavigationCallExp Agree (clarifying why the subtyping is not wrong) >>> Issue 9796: Section: 7.3.4 Agree (Fixing usage of @pre) >>> Issue 9913: Section: 8.3.5 Agree (Adding the missing definitions in concrete syntax part). In fact the FTF, for timing reasons didn't touch the concrete syntax section which become somehow de-synchrnized with the rest. >>> Issue 10430: Section 7.6.3 Agree (Clarifying number of iterators in forAll). >>> Issue 10432: Section "IteratorExpCS" Agree (No change) >>> Issue 10433: 11.2.3 Agree. Good point. OclVoid cannot conform to OclInvalid. >>> Issue 10434: 11.2.4 (OclInvalid) - similar criticism as 11.2.3 Agree (same as previous). >>> Issue 10436: 11.2.5 Agree (description reformulation). Indeed replacement of OclType by Classifier depends on issue 6532. >>> Issue 10436: 11.2.5 (02) Agree (Re-typing to a supertype does not mean ability to access an overridden property). However still the question whether we allow access to an overriden property is pending. (available in various languages). This may be useful when defining the overriden version of an Operation. But for sure this should not use the oclAsType operator. Replacement of OclType by Classifier depends on issue 6532. >>> Issue 10825: ownership of association ends does not matter for traversal in OCL I think this issue is controversial. We should take care not to define behaviors that cannot be easily implemented. Also this may have an impact on reflection. Does it means that when we use the reflective MOF interface to look for attributes of a class we obtain also not owned Attributes? Any opinion, reacion here? >>> Issue 10921: TypeType This depends on resolution of issue 6532. >>> Issue 10946: Collection element type serialization Agree. Non uniqueness of collection types is important since it gives more freedom on where to place its definition. However, it is important to clarify that it is not mandatory to use the "generatedType" association to store the generated types. Depending on the context of usage, these generated types can also be created within a Package (using ownedType association). >>> Issue 11097: Dynamic typing with allInstances() I don't think I agree with all the text. I prefer the actual definition notation: allInstances() : Set( T ) Instead of allInstances() : Set( self ) Which is syntactically very hazardous. Now, making the allInstances be an operation of Classifier (the M1 instance representing the UML Classifier metatype) will be, for sure, consistent with the proposed resolution of 6532. So I think this depends on issue 6532. More specifically, I believe this kind of change should be part of resolution of 6532 and not be the resolution of this issue. The resolution for issue 11097 should then probably be: Closed, no change. >>> Issue: 11098: Section: 7.4.7, 7.4.9, 9.3.2 Agree (adding implies and let in operator priority definition). >>> Issue 12378: Section 8.2 InvalidType Agree. Terminology clarification. >>> Issue 12419: CollectionType and CollectionKind I believe the resolution is not complete. The example provided by the submitter of the issue shows that the CollectionType cannot be an abstract metaclass since the definition of a OCL constraint really requires instatiating CollectionTypes (Collection(Type) in the provided example). In fact a Collection is "abstract" from a runtime point of view, but not "abstract" from an OCL constraint definition point of view. But in practice this means that the M2 metaclass ColelctionType cannot be abstract. >>> Issue 12449: no explanations about how to manipulate optional and multivalued attributes Agree (Misunderstanding) >>> Issue 12450: The Tuple constructor is problematic Agree (Misunderstanding) >>> Issue 12484: Section 8.2.1 Type Conformance on page 37 Agree (already discussed) >>> Issue 12485: Section 8.2 page 35 InvalidType Agree (duplicated) Mariano Belaunde Senior Researcher in Modelling Techniques Orange Labs 8 Avenue Pierre Marzin 22300 Lannion France tel +33 2 96 05 30 85 mariano.belaunde@orange-ftgroup.com From: "Christian W. Damus" To: ocl2-rtf@omg.org Subject: Re: Feedback on issues from 8663 to 12485 Date: Thu, 9 Oct 2008 12:22:11 -0400 X-Mailer: Apple Mail (2.929.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s014.panelboxmanager.com X-AntiAbuse: Original Domain - omg.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zeligsoft.com X-Source: X-Source-Args: X-Source-Dir: Hi, Mariano, Thanks again for taking the time for careful review of these proposals. I have a few more responses, in-line. cW On 9-Oct-08, at 10:04 AM, wrote: Hi all, Continuing with my feedback on the proposed resolutions, here is my feedback for the rest of the issues from Christian document (from 8663 to 12485) >>> Issue 8663: Section: 11.9.1 exists Agree (No change, misunderstanding) >>> Issue 8664: Section: 11.9.1 reject Agree (No change, misunderstanding) >>> Issue 8787: The spec does not describes the syntax of integer, real or string literals Agree (Adding some text in 9.3 Concrete Syntax section). >>> Issue 8790: OclAny cannot be an instance of Classifier Agree (Closed, Already resolved) >>> Issue 8818: Reusing TypedElement for UnspecifiedValueExp Agree (Closed, Already resolved) >>> Issue 10787: OCL Collections applied to Properties Agree (No change) >>> Issue 8917: allInstances Agree (Adjusting the description text of allInstances) >>> Issue 8937: Notation for accessing class operations is inconsistent Agree (clarifying allInstance is not static) >>> Issue 9171: Introduction and oclType() Strongly agree. But the exact wording of teh resolution will depend on resolution of issue 6532 Notice that EssentialOcl merges the reflection MOF capability. However its true that getMetaClass() is not applicable to the values of DataTypes since it returns a Class. Good point! I had not considered that. There is also a corollary: the oclIsKindOf() and other operations are defined by OclAny (as would the proposed oclType() operation). This makes them available on data types, except for the OCL collections, which explicitly do not not specialize OclAny. Should we repeat these operations on the CollectionType metaclass? Personally, I don't see that reflection on collection values would be useful in practice, but what do others think? >>> Issue 9405: Wrong subtyping of PropertyCallExp and NavigationCallExp Agree (clarifying why the subtyping is not wrong) >>> Issue 9796: Section: 7.3.4 Agree (Fixing usage of @pre) >>> Issue 9913: Section: 8.3.5 Agree (Adding the missing definitions in concrete syntax part). In fact the FTF, for timing reasons didn't touch the concrete syntax section which become somehow de-synchrnized with the rest. That raises a good question. Should we completely overhaul this section, perhaps also using a more modern notation? Or, should we excise it from this document altogether and let it be specified using a standard notation in a separate document as suggested in Issue 12562? Would anybody have the time for such an effort? I, personally, am rather weak in the practice of formal grammar definition. >>> Issue 10430: Section 7.6.3 Agree (Clarifying number of iterators in forAll). >>> Issue 10432: Section "IteratorExpCS" Agree (No change) >>> Issue 10433: 11.2.3 Agree. Good point. OclVoid cannot conform to OclInvalid. >>> Issue 10434: 11.2.4 (OclInvalid) - similar criticism as 11.2.3 Agree (same as previous). >>> Issue 10436: 11.2.5 Agree (description reformulation). Indeed replacement of OclType by Classifier depends on issue 6532. >>> Issue 10436: 11.2.5 (02) Agree (Re-typing to a supertype does not mean ability to access an overridden property). However still the question whether we allow access to an overriden property is pending. (available in various languages). This may be useful when defining the overriden version of an Operation. But for sure this should not use the oclAsType operator. Replacement of OclType by Classifier depends on issue 6532. Agreed. >>> Issue 10825: ownership of association ends does not matter for traversal in OCL I think this issue is controversial. We should take care not to define behaviors that cannot be easily implemented. Also this may have an impact on reflection. Does it means that when Navigation of association-owned ends is identified as an optional compliance point in Table 2.1, which I think is reasonable as this does have implementation dependencies. we use the reflective MOF interface to look for attributes of a class we obtain also not owned Attributes? Any opinion, reacion here? I don't think that OCL should attempt to change MOF's reflection capability. In any case, the question doesn't arise in EMOF because EMOF doesn't have associations. It would only be a concern in CompleteOcl (UML), but in the UML, the association-owned ends are not features of the corresponding end classifier. I think that the "... is considered as a property of ..." wording in the proposal is too strong and suggests a contradiction with UML semantics. I may have misunderstood your question. Are you, instead, suggesting that an OCL implementation should use MOF reflection in looking up attributes? >>> Issue 10921: TypeType This depends on resolution of issue 6532. Agreed. >>> Issue 10946: Collection element type serialization Agree. Non uniqueness of collection types is important since it gives more freedom on where to place its definition. However, it is important to clarify that it is not mandatory to use the "generatedType" association to store the generated types. Depending on the context of usage, these generated types can also be created within a Package (using ownedType association). Agreed, good point. I gather that the QVT language, for example, does specify a package to own these types? >>> Issue 11097: Dynamic typing with allInstances() I don't think I agree with all the text. I prefer the actual definition notation: allInstances() : Set( T ) Instead of allInstances() : Set( self ) Which is syntactically very hazardous. Yes, I agree that T is clearer and more consistent with other usage in the document. However, this raises the question of how to represent T in the model. OCL currently uses the names T and T2 as type parameters in various places, but the language does not seem to have caught up to the fact that UML 2.x classifiers and operations are templateable elements, and that some of the types that it needs to deal with are actually owned parametered elements. In particular, how does the OCL Standard Library represent T and T2? I can imagine a UML representation, but not so easily an EMOF one. Am I opening a can of worms? It is an important question, though, for the MOF serializations of the metamodel and standard library that I think we need to publish. Now, making the allInstances be an operation of Classifier (the M1 instance representing the UML Classifier metatype) will be, for sure, consistent with the proposed resolution of 6532. So I think this depends on issue 6532. Agreed. More specifically, I believe this kind of change should be part of resolution of 6532 and not be the resolution of this issue. The resolution for issue 11097 should then probably be: Closed, no change. Agreed, good idea. >>> Issue: 11098: Section: 7.4.7, 7.4.9, 9.3.2 Agree (adding implies and let in operator priority definition). >>> Issue 12378: Section 8.2 InvalidType Agree. Terminology clarification. >>> Issue 12419: CollectionType and CollectionKind I believe the resolution is not complete. The example provided by the submitter of the issue shows that the CollectionType cannot be an abstract metaclass since the definition of a OCL constraint really requires instatiating CollectionTypes (Collection(Type) in the provided example). In fact a Collection is "abstract" from a runtime point of view, but not "abstract" from an OCL constraint definition point of view. But in practice this means that the M2 metaclass ColelctionType cannot be abstract. I'm afraid I didn't quite follow your response. Are we agreed that CollectionType being non-abstract and Collection(T) abstract, as they are currently defined, is correct? Or are you suggesting that Collection(T) should also not be abstract? I'm not sure what you are proposing to add to or amend in the resolution text. >>> Issue 12449: no explanations about how to manipulate optional and multivalued attributes Agree (Misunderstanding) >>> Issue 12450: The Tuple constructor is problematic Agree (Misunderstanding) >>> Issue 12484: Section 8.2.1 Type Conformance on page 37 Agree (already discussed) >>> Issue 12485: Section 8.2 page 35 InvalidType Agree (duplicated) Mariano Belaunde Senior Researcher in Modelling Techniques Orange Labs 8 Avenue Pierre Marzin 22300 Lannion France tel +33 2 96 05 30 85 mariano.belaunde@orange-ftgroup.com -- Christian W. Damus Senior Software Developer, Zeligsoft Inc. Component Lead, Eclipse MDT OCL and EMF-QTV E-mail: cdamus@zeligsoft.com Subject: RE: Feedback on issues from 8663 to 12485 Date: Fri, 10 Oct 2008 15:23:57 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback on issues from 8663 to 12485 thread-index: AckqK5JTWdKUuCO/Tl6woKz525KspwABGLzg From: To: , X-OriginalArrivalTime: 10 Oct 2008 13:24:06.0364 (UTC) FILETIME=[7870E9C0:01C92ADB] Hi Christian and all, Some responses below... >>> Issue 9913: Section: 8.3.5 >>> Should we completely overhaul this section, perhaps also using a more modern notation? I think this is an issue for OCL 2.2 RTF. For OCL 2.1 we will not have enough time to provide a good response how to re-synchrnize the Concrete Syntax section. By the way the same is for section 10 (Semantics described with UML). >>> Issue 9171: Introduction and oclType() >>> Should we repeat these operations on the CollectionType metaclass? >>> Personally, I don't see that reflection on collection values would be useful in practice, >>> but what do others think? I think it sounds strange to have an operator to access meta type information that works for almost all objects but not for collection values. I believe we should consider having also this operation for collections. By the way, two comments here: maybe oclMetaType() would be a better name name oclType()?? This depends whether at M1-level accessing the type means always accessing an instance representing the meta type. Also is there any relationship between the type of an object returned by an OCL expression and this oclType() operation? Some clarification is needed here. The second comment: To be entirely consistent with UML2 and MOF2, I believe we should also avoid having this very specific type "OclAny" and instead use the reflective "Object" meta-type (which works for all kinds of objects, including collections). Looking at the operations defined for AnyType we can see that there are only two operations that are not applicable to collections: oclIsNew and allInstances. However these two operations are not valid also for primitives types. So at the end I see no justification for having this special type - that is unknown in UML and MOF - except to play the role of the more general Object. In UML context, however we may have the problem that the MOF reflexion capability is not merged by default... So a possible global solution could be: let's simply change the definition of OclAny so that it represents _really_ any object (without excluding the collection values). In the context of EssentialOcl, OclAny is a pure renaming of MOF::Object. This solution would have the advantage not to change the terminology and limit the editorial impact of the resolution. Any opinion on this idea? Should we then treat the problem of OclAny in OCL 2.1 consistently with OclType (as part of UML/MOF re-alignment in resolution of issue 6532), or defer the problem to OCL 2.2? >>> Issue 12419: CollectionType and CollectionKind I>>> 'm afraid I didn't quite follow your response. Are we agreed that CollectionType being non-abstract >>> and Collection(T) abstract, as they are currently defined, is correct? Or are you suggesting that >>> Collection(T) should also not be abstract? I'm not sure what you are proposing to add to or amend >>> in the resolution text. Yes, we all agree that CollectionType should be non-abstract and Collection is abstract. However in the OCL2 actual specification, the CollectionType metaclass is abstract and this is an error. Some change is needed in the text describing the CollectionType metaclass (Section 8.2) and in the figure 8.1 (removing italics). >>> Issue 10825: ownership of association ends does not matter for traversal in OCL >>> Navigation of association-owned ends is identified as an optional compliance point in Table 2.1, >>> which I think is reasonable as this does have implementation dependencies. OK, but in that case there should be a note to remain that implementation of this feature is an optional compliance point. >>> Issue 10946: Collection element type serialization >>> I gather that the QVT language, for example, does specify a package to own these types? Yes. Theses types types are owned by the qvt module which is a kind of package. >>> Issue 11097: Dynamic typing with allInstances() >>> However, this raises the question of how to represent T in the model. >>> I can imagine a UML representation, but not so easily an EMOF one. >>> Am I opening a can of worms? For OCL this is currently an unresolved issue (deferred to OCL 2.2??) . If we want just to represent the signature of the parameterized operations in the Ocl StdLib then a simple new metaclass TemplateParameterType is sufficient. This approach is taken currently in QVT. Now, if we are more ambitious and we want to let users define their own parameterized operations then the complete UML template support will be needed. Best Regards, Mariano -------------------------------------------------------------------------------- De : Christian W. Damus [mailto:cdamus@zeligsoft.com] Envoyé : jeudi 9 octobre 2008 18:22 À : ocl2-rtf@omg.org Objet : Re: Feedback on issues from 8663 to 12485 Hi, Mariano, Thanks again for taking the time for careful review of these proposals. I have a few more responses, in-line. cW On 9-Oct-08, at 10:04 AM, wrote: Hi all, Continuing with my feedback on the proposed resolutions, here is my feedback for the rest of the issues from Christian document (from 8663 to 12485) >>> Issue 8663: Section: 11.9.1 exists Agree (No change, misunderstanding) >>> Issue 8664: Section: 11.9.1 reject Agree (No change, misunderstanding) >>> Issue 8787: The spec does not describes the syntax of integer, real or string literals Agree (Adding some text in 9.3 Concrete Syntax section). >>> Issue 8790: OclAny cannot be an instance of Classifier Agree (Closed, Already resolved) >>> Issue 8818: Reusing TypedElement for UnspecifiedValueExp Agree (Closed, Already resolved) >>> Issue 10787: OCL Collections applied to Properties Agree (No change) >>> Issue 8917: allInstances Agree (Adjusting the description text of allInstances) >>> Issue 8937: Notation for accessing class operations is inconsistent Agree (clarifying allInstance is not static) >>> Issue 9171: Introduction and oclType() Strongly agree. But the exact wording of teh resolution will depend on resolution of issue 6532 Notice that EssentialOcl merges the reflection MOF capability. However its true that getMetaClass() is not applicable to the values of DataTypes since it returns a Class. Good point! I had not considered that. There is also a corollary: the oclIsKindOf() and other operations are defined by OclAny (as would the proposed oclType() operation). This makes them available on data types, except for the OCL collections, which explicitly do not not specialize OclAny. Should we repeat these operations on the CollectionType metaclass? Personally, I don't see that reflection on collection values would be useful in practice, but what do others think? >>> Issue 9405: Wrong subtyping of PropertyCallExp and NavigationCallExp Agree (clarifying why the subtyping is not wrong) >>> Issue 9796: Section: 7.3.4 Agree (Fixing usage of @pre) >>> Issue 9913: Section: 8.3.5 Agree (Adding the missing definitions in concrete syntax part). In fact the FTF, for timing reasons didn't touch the concrete syntax section which become somehow de-synchrnized with the rest. That raises a good question. Should we completely overhaul this section, perhaps also using a more modern notation? Or, should we excise it from this document altogether and let it be specified using a standard notation in a separate document as suggested in Issue 12562? Would anybody have the time for such an effort? I, personally, am rather weak in the practice of formal grammar definition. >>> Issue 10430: Section 7.6.3 Agree (Clarifying number of iterators in forAll). >>> Issue 10432: Section "IteratorExpCS" Agree (No change) >>> Issue 10433: 11.2.3 Agree. Good point. OclVoid cannot conform to OclInvalid. >>> Issue 10434: 11.2.4 (OclInvalid) - similar criticism as 11.2.3 Agree (same as previous). >>> Issue 10436: 11.2.5 Agree (description reformulation). Indeed replacement of OclType by Classifier depends on issue 6532. >>> Issue 10436: 11.2.5 (02) Agree (Re-typing to a supertype does not mean ability to access an overridden property). However still the question whether we allow access to an overriden property is pending. (available in various languages). This may be useful when defining the overriden version of an Operation. But for sure this should not use the oclAsType operator. Replacement of OclType by Classifier depends on issue 6532. Agreed. >>> Issue 10825: ownership of association ends does not matter for traversal in OCL I think this issue is controversial. We should take care not to define behaviors that cannot be easily implemented. Also this may have an impact on reflection. Does it means that when Navigation of association-owned ends is identified as an optional compliance point in Table 2.1, which I think is reasonable as this does have implementation dependencies. we use the reflective MOF interface to look for attributes of a class we obtain also not owned Attributes? Any opinion, reacion here? I don't think that OCL should attempt to change MOF's reflection capability. In any case, the question doesn't arise in EMOF because EMOF doesn't have associations. It would only be a concern in CompleteOcl (UML), but in the UML, the association-owned ends are not features of the corresponding end classifier. I think that the "... is considered as a property of ..." wording in the proposal is too strong and suggests a contradiction with UML semantics. I may have misunderstood your question. Are you, instead, suggesting that an OCL implementation should use MOF reflection in looking up attributes? >>> Issue 10921: TypeType This depends on resolution of issue 6532. Agreed. >>> Issue 10946: Collection element type serialization Agree. Non uniqueness of collection types is important since it gives more freedom on where to place its definition. However, it is important to clarify that it is not mandatory to use the "generatedType" association to store the generated types. Depending on the context of usage, these generated types can also be created within a Package (using ownedType association). Agreed, good point. I gather that the QVT language, for example, does specify a package to own these types? >>> Issue 11097: Dynamic typing with allInstances() I don't think I agree with all the text. I prefer the actual definition notation: allInstances() : Set( T ) Instead of allInstances() : Set( self ) Which is syntactically very hazardous. Yes, I agree that T is clearer and more consistent with other usage in the document. However, this raises the question of how to represent T in the model. OCL currently uses the names T and T2 as type parameters in various places, but the language does not seem to have caught up to the fact that UML 2.x classifiers and operations are templateable elements, and that some of the types that it needs to deal with are actually owned parametered elements. In particular, how does the OCL Standard Library represent T and T2? I can imagine a UML representation, but not so easily an EMOF one. Am I opening a can of worms? It is an important question, though, for the MOF serializations of the metamodel and standard library that I think we need to publish. Now, making the allInstances be an operation of Classifier (the M1 instance representing the UML Classifier metatype) will be, for sure, consistent with the proposed resolution of 6532. So I think this depends on issue 6532. Agreed. More specifically, I believe this kind of change should be part of resolution of 6532 and not be the resolution of this issue. The resolution for issue 11097 should then probably be: Closed, no change. Agreed, good idea. >>> Issue: 11098: Section: 7.4.7, 7.4.9, 9.3.2 Agree (adding implies and let in operator priority definition). >>> Issue 12378: Section 8.2 InvalidType Agree. Terminology clarification. >>> Issue 12419: CollectionType and CollectionKind I believe the resolution is not complete. The example provided by the submitter of the issue shows that the CollectionType cannot be an abstract metaclass since the definition of a OCL constraint really requires instatiating CollectionTypes (Collection(Type) in the provided example). In fact a Collection is "abstract" from a runtime point of view, but not "abstract" from an OCL constraint definition point of view. But in practice this means that the M2 metaclass ColelctionType cannot be abstract. I'm afraid I didn't quite follow your response. Are we agreed that CollectionType being non-abstract and Collection(T) abstract, as they are currently defined, is correct? Or are you suggesting that Collection(T) should also not be abstract? I'm not sure what you are proposing to add to or amend in the resolution text. >>> Issue 12449: no explanations about how to manipulate optional and multivalued attributes Agree (Misunderstanding) >>> Issue 12450: The Tuple constructor is problematic Agree (Misunderstanding) >>> Issue 12484: Section 8.2.1 Type Conformance on page 37 Agree (already discussed) >>> Issue 12485: Section 8.2 page 35 InvalidType Agree (duplicated) Mariano Belaunde Senior Researcher in Modelling Techniques Orange Labs 8 Avenue Pierre Marzin 22300 Lannion France tel +33 2 96 05 30 85 mariano.belaunde@orange-ftgroup.com -- Christian W. Damus Senior Software Developer, Zeligsoft Inc. Component Lead, Eclipse MDT OCL and EMF-QTV E-mail: cdamus@zeligsoft.com From: "Christian W. Damus" To: ocl2-rtf@omg.org Subject: Re: Feedback on issues from 8663 to 12485 Date: Fri, 10 Oct 2008 15:11:48 -0400 X-Mailer: Apple Mail (2.929.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s014.panelboxmanager.com X-AntiAbuse: Original Domain - omg.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zeligsoft.com X-Source: X-Source-Args: X-Source-Dir: On 10-Oct-08, at 9:23 AM, wrote: Hi Christian and all, Some responses below... >>> Issue 9913: Section: 8.3.5 >>> Should we completely overhaul this section, perhaps also using a more modern notation? I think this is an issue for OCL 2.2 RTF. For OCL 2.1 we will not have enough time to provide a good response how to re-synchrnize the Concrete Syntax section. By the way the same is for section 10 (Semantics described with UML). Strong agreement. >>> Issue 9171: Introduction and oclType() >>> Should we repeat these operations on the CollectionType metaclass? >>> Personally, I don't see that reflection on collection values would be useful in practice, >>> but what do others think? I think it sounds strange to have an operator to access meta type information that works for almost all objects but not for collection values. I believe we should consider having also this operation for collections. Yes. I see that you have already submitted an issue for more MOF-aligned reflection. Note that, for collections, we will again need to employ the arrow operator to distinguish invocation of operations on the collection value, itself. Thus, Set{aCat, anotherCat, aDog}.oclType() results in Set{Cat, Dog}, whereas Set{aCat, anotherCat, aDog}->oclType() results in Set(Mammal) or something more specific. The main reason why I questioned the usefulness of reflection on collection types is that, in most expressions, the actual collection type is known statically. For example, the collection-type of a multivalued property is entirely determined by its meta-attributes: isUnique, isOrdered, and type. If, at run-time, the actual values of a property "animals : Animal [*]" that is non-unique happen not to have duplicates and are all dogs, the collection value's type is still Bag(Animal) and not Set(Dog). I do agree, though, that consistency of the reflection capability is more desirable. By the way, two comments here: maybe oclMetaType() would be a better name name oclType()?? This depends whether at M1-level accessing the type means always accessing an instance representing the meta type. In an M1 constraint, the capability that we need is to access the M1 type of an M0 object. Thus, I think oclType() is the more appropriate name, because in this case the result is not a metaclass. In an M1 constraint, oclType().oclType() would evaluate to a metaclass, but that would rarely be useful, I expect. Also is there any relationship between the type of an object returned by an OCL expression and this oclType() operation? No, I don't think so. The oclType() operation must always return the actual run-time type (dynamic type) of the object on which it is called. It would be a run-time error if the dynamic type did not conform to the static type (the expression's result type). Some clarification is needed here. The second comment: To be entirely consistent with UML2 and MOF2, I believe we should also avoid having this very specific type "OclAny" and instead use the reflective "Object" meta-type (which works for all kinds of objects, including collections). Looking at the operations defined for AnyType we can see that there are only two operations that are not applicable to collections: oclIsNew and allInstances. However these two operations are not valid also for primitives types. So at the end I see no justification for having this special type - that is unknown in UML and MOF - except to play the role of the more general Object. Agreed. I confess that I did not understand the stated justification for collection types' non-conformance to OclAny. What was the circularity problem? It seems to me that the very foundation of MOF is the circularity of its construction. In UML context, however we may have the problem that the MOF reflexion capability is not merged by default... So a possible global solution could be: let's simply change the definition of OclAny so that it represents _really_ any object (without excluding the collection values). In the context of EssentialOcl, OclAny is a pure renaming of MOF::Object. This solution would have the advantage not to change the terminology and limit the editorial impact of the resolution. Any opinion on this idea? I like it. Especially as it augments UML with reflection Should we then treat the problem of OclAny in OCL 2.1 consistently with OclType (as part of UML/MOF re-alignment in resolution of issue 6532), or defer the problem to OCL 2.2? I think we should attempt it, but I don't understand (yet) what the scale of its impact will be. >>> Issue 12419: CollectionType and CollectionKind I>>> 'm afraid I didn't quite follow your response. Are we agreed that CollectionType being non-abstract >>> and Collection(T) abstract, as they are currently defined, is correct? Or are you suggesting that >>> Collection(T) should also not be abstract? I'm not sure what you are proposing to add to or amend >>> in the resolution text. Yes, we all agree that CollectionType should be non-abstract and Collection is abstract. However in the OCL2 actual specification, the CollectionType metaclass is abstract and this is an error. Some change is needed in the text describing the CollectionType metaclass (Section 8.2) and in the figure 8.1 (removing italics) Thanks for making that clear. >>> Issue 10825: ownership of association ends does not matter for traversal in OCL >>> Navigation of association-owned ends is identified as an optional compliance point in Table 2.1, >>> which I think is reasonable as this does have implementation dependencies. OK, but in that case there should be a note to remain that implementation of this feature is an optional compliance point. I'll see to it. >>> Issue 10946: Collection element type serialization >>> I gather that the QVT language, for example, does specify a package to own these types? Yes. Theses types types are owned by the qvt module which is a kind of package. >>> Issue 11097: Dynamic typing with allInstances() >>> However, this raises the question of how to represent T in the model. >>> I can imagine a UML representation, but not so easily an EMOF one. >>> Am I opening a can of worms? For OCL this is currently an unresolved issue (deferred to OCL 2.2??) . If we want just to represent the signature of the parameterized operations in the Ocl StdLib then a simple new metaclass TemplateParameterType is sufficient. This approach is taken currently in QVT. Then, perhaps we can simply "promote" the solution from QVT. OCL will need to define its own solution for EssentialOcl, anyway, as EMOF doesn't have templates. Now, if we are more ambitious and we want to let users define their own parameterized operations then the complete UML template support will be needed. Yes, OCL will have to handle template bindings, which does seem rather ambitious in the time that we have. Best Regards, Mariano -------------------------------------------------------------------------------- De : Christian W. Damus [mailto:cdamus@zeligsoft.com] Envoyé : jeudi 9 octobre 2008 18:22 À : ocl2-rtf@omg.org Objet : Re: Feedback on issues from 8663 to 12485 Hi, Mariano, Thanks again for taking the time for careful review of these proposals. I have a few more responses, in-line. cW On 9-Oct-08, at 10:04 AM, wrote: Hi all, Continuing with my feedback on the proposed resolutions, here is my feedback for the rest of the issues from Christian document (from 8663 to 12485) >>> Issue 8663: Section: 11.9.1 exists Agree (No change, misunderstanding) >>> Issue 8664: Section: 11.9.1 reject Agree (No change, misunderstanding) >>> Issue 8787: The spec does not describes the syntax of integer, real or string literals Agree (Adding some text in 9.3 Concrete Syntax section). >>> Issue 8790: OclAny cannot be an instance of Classifier Agree (Closed, Already resolved) >>> Issue 8818: Reusing TypedElement for UnspecifiedValueExp Agree (Closed, Already resolved) >>> Issue 10787: OCL Collections applied to Properties Agree (No change) >>> Issue 8917: allInstances Agree (Adjusting the description text of allInstances) >>> Issue 8937: Notation for accessing class operations is inconsistent Agree (clarifying allInstance is not static) >>> Issue 9171: Introduction and oclType() Strongly agree. But the exact wording of teh resolution will depend on resolution of issue 6532 Notice that EssentialOcl merges the reflection MOF capability. However its true that getMetaClass() is not applicable to the values of DataTypes since it returns a Class. Good point! I had not considered that. There is also a corollary: the oclIsKindOf() and other operations are defined by OclAny (as would the proposed oclType() operation). This makes them available on data types, except for the OCL collections, which explicitly do not not specialize OclAny. Should we repeat these operations on the CollectionType metaclass? Personally, I don't see that reflection on collection values would be useful in practice, but what do others think? >>> Issue 9405: Wrong subtyping of PropertyCallExp and NavigationCallExp Agree (clarifying why the subtyping is not wrong) >>> Issue 9796: Section: 7.3.4 Agree (Fixing usage of @pre) >>> Issue 9913: Section: 8.3.5 Agree (Adding the missing definitions in concrete syntax part). In fact the FTF, for timing reasons didn't touch the concrete syntax section which become somehow de-synchrnized with the rest. That raises a good question. Should we completely overhaul this section, perhaps also using a more modern notation? Or, should we excise it from this document altogether and let it be specified using a standard notation in a separate document as suggested in Issue 12562? Would anybody have the time for such an effort? I, personally, am rather weak in the practice of formal grammar definition. >>> Issue 10430: Section 7.6.3 Agree (Clarifying number of iterators in forAll). >>> Issue 10432: Section "IteratorExpCS" Agree (No change) >>> Issue 10433: 11.2.3 Agree. Good point. OclVoid cannot conform to OclInvalid. >>> Issue 10434: 11.2.4 (OclInvalid) - similar criticism as 11.2.3 Agree (same as previous). >>> Issue 10436: 11.2.5 Agree (description reformulation). Indeed replacement of OclType by Classifier depends on issue 6532. >>> Issue 10436: 11.2.5 (02) Agree (Re-typing to a supertype does not mean ability to access an overridden property). However still the question whether we allow access to an overriden property is pending. (available in various languages). This may be useful when defining the overriden version of an Operation. But for sure this should not use the oclAsType operator. Replacement of OclType by Classifier depends on issue 6532. Agreed. >>> Issue 10825: ownership of association ends does not matter for traversal in OCL I think this issue is controversial. We should take care not to define behaviors that cannot be easily implemented. Also this may have an impact on reflection. Does it means that when Navigation of association-owned ends is identified as an optional compliance point in Table 2.1, which I think is reasonable as this does have implementation dependencies. we use the reflective MOF interface to look for attributes of a class we obtain also not owned Attributes? Any opinion, reacion here? I don't think that OCL should attempt to change MOF's reflection capability. In any case, the question doesn't arise in EMOF because EMOF doesn't have associations. It would only be a concern in CompleteOcl (UML), but in the UML, the association-owned ends are not features of the corresponding end classifier. I think that the "... is considered as a property of ..." wording in the proposal is too strong and suggests a contradiction with UML semantics. I may have misunderstood your question. Are you, instead, suggesting that an OCL implementation should use MOF reflection in looking up attributes? >>> Issue 10921: TypeType This depends on resolution of issue 6532. Agreed. >>> Issue 10946: Collection element type serialization Agree. Non uniqueness of collection types is important since it gives more freedom on where to place its definition. However, it is important to clarify that it is not mandatory to use the "generatedType" association to store the generated types. Depending on the context of usage, these generated types can also be created within a Package (using ownedType association). Agreed, good point. I gather that the QVT language, for example, does specify a package to own these types? >>> Issue 11097: Dynamic typing with allInstances() I don't think I agree with all the text. I prefer the actual definition notation: allInstances() : Set( T ) Instead of allInstances() : Set( self ) Which is syntactically very hazardous. Yes, I agree that T is clearer and more consistent with other usage in the document. However, this raises the question of how to represent T in the model. OCL currently uses the names T and T2 as type parameters in various places, but the language does not seem to have caught up to the fact that UML 2.x classifiers and operations are templateable elements, and that some of the types that it needs to deal with are actually owned parametered elements. In particular, how does the OCL Standard Library represent T and T2? I can imagine a UML representation, but not so easily an EMOF one. Am I opening a can of worms? It is an important question, though, for the MOF serializations of the metamodel and standard library that I think we need to publish. Now, making the allInstances be an operation of Classifier (the M1 instance representing the UML Classifier metatype) will be, for sure, consistent with the proposed resolution of 6532. So I think this depends on issue 6532. Agreed. More specifically, I believe this kind of change should be part of resolution of 6532 and not be the resolution of this issue. The resolution for issue 11097 should then probably be: Closed, no change. Agreed, good idea. >>> Issue: 11098: Section: 7.4.7, 7.4.9, 9.3.2 Agree (adding implies and let in operator priority definition). >>> Issue 12378: Section 8.2 InvalidType Agree. Terminology clarification. >>> Issue 12419: CollectionType and CollectionKind I believe the resolution is not complete. The example provided by the submitter of the issue shows that the CollectionType cannot be an abstract metaclass since the definition of a OCL constraint really requires instatiating CollectionTypes (Collection(Type) in the provided example). In fact a Collection is "abstract" from a runtime point of view, but not "abstract" from an OCL constraint definition point of view. But in practice this means that the M2 metaclass ColelctionType cannot be abstract. I'm afraid I didn't quite follow your response. Are we agreed that CollectionType being non-abstract and Collection(T) abstract, as they are currently defined, is correct? Or are you suggesting that Collection(T) should also not be abstract? I'm not sure what you are proposing to add to or amend in the resolution text. >>> Issue 12449: no explanations about how to manipulate optional and multivalued attributes Agree (Misunderstanding) >>> Issue 12450: The Tuple constructor is problematic Agree (Misunderstanding) >>> Issue 12484: Section 8.2.1 Type Conformance on page 37 Agree (already discussed) >>> Issue 12485: Section 8.2 page 35 InvalidType Agree (duplicated) Mariano Belaunde Senior Researcher in Modelling Techniques Orange Labs 8 Avenue Pierre Marzin 22300 Lannion France tel +33 2 96 05 30 85 mariano.belaunde@orange-ftgroup.com -- Christian W. Damus Senior Software Developer, Zeligsoft Inc. Component Lead, Eclipse MDT OCL and EMF-QTV E-mail: cdamus@zeligsoft.com -- Christian W. Damus Senior Software Developer, Zeligsoft Inc. Component Lead, Eclipse MDT OCL and EMF-QTV E-mail: cdamus@zeligsoft.com >