Issue 10436: 11.2.5 (ocl2-rtf) Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov) Nature: Uncategorized Issue Severity: Summary: oclIsTypeOf(typespec : OclType) : Boolean "Evaluates to true if the self is of the type identifid by typespec.." oclIsKindOf(typespec : OclType) : Boolean "Evaluates to true if the self conforms to the type identified by typespec" >From those descriptions I cannot distinguish these two. Isn't a dog "of the type" mammal" and wouldn't a dog "conform to the type" mammal? (Subtypes always conform to the supertype). I suspect that you intend that one of these evaluates to TRUE if and only if self is of type typespec *and not also of a subtype of typespec* . You might say just that. Resolution: Revised Text: Update the text in Section 11.2.5 Operations and Well-formedness Rules to read: oclIsTypeOf(t : Classifier) : Boolean Evaluates to true if self is of the type t but not a subtype of t. oclIsKindOf(t : Classifier) : Boolean Evaluates to true if the type of self conforms to t. That is, self is of type t or a subtype of t. Actions taken: November 2, 2006: received issue October 16, 2009: closed issue Discussion: Note that this resolution depends on the proposal for resolution of Issue 6532 that discards the OclType metatype in favour of Classifier. End of Annotations:===== s is issue # 10436 11.2.5 oclIsTypeOf(typespec : OclType) : Boolean "Evaluates to true if the self is of the type identifid by typespec.." oclIsKindOf(typespec : OclType) : Boolean "Evaluates to true if the self conforms to the type identified by typespec" >From those descriptions I cannot distinguish these two. Isn't a dog "of the type" mammal" and wouldn't a dog "conform to the type" mammal? (Subtypes always conform to the supertype). I suspect that you intend that one of these evaluates to TRUE if and only if self is of type typespec *and not also of a subtype of typespec* . You might 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 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAKcDwkrUnw6U/2dsb2JhbACTSMRJhB4F Date: Tue, 29 Sep 2009 20:56:53 +0100 From: Ed Willink User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) To: issues@omg.org Subject: OCL 2.1 Issue 10436 resolution ignored X-Plusnet-Relay: 268998831cd3b6dc894afd634d1bd6c2 Hi The OCL 2.1 RTF Beta final report providess Issue 10436 with a resolution. The OCL 2.1 Revised specification does not incorporate the revised text for issue 10436. Regards Ed Willink X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 Sep 2009 16:41:19 -0400 To: ocl2-rtf@omg.org From: Juergen Boldt Subject: Fwd: OCL 2.1 Issue 10436 resolution ignored X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAKcDwkrUnw6U/2dsb2JhbACTSMRJhB4F Date: Tue, 29 Sep 2009 20:56:53 +0100 From: Ed Willink User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) To: issues@omg.org Subject: OCL 2.1 Issue 10436 resolution ignored X-Plusnet-Relay: 268998831cd3b6dc894afd634d1bd6c2 Hi The OCL 2.1 RTF Beta final report providess Issue 10436 with a resolution. The OCL 2.1 Revised specification does not incorporate the revised text for issue 10436. Regards Ed Willink 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: "Willink, Ed" To: "'Juergen Boldt'" Subject: RE: OCL 2.1 Issue 10436 resolution ignored Date: Wed, 30 Sep 2009 10:54:11 +0100 X-Mailer: Internet Mail Service (5.5.2657.72) Hi Juergen Once again it is very unclear what the current status of the old and new OCL RTFs are and so perhaps this needs to be a new Issue. The problem occurs in documents that were provided for a ballot that finished at the end of August although it is not clear that any bollot result has been announced. The individual votes that I have seen were all Yes for everything. If the Issue resolution is normative and the revised text merely informative, then perhaps the oversight can be resolved editorial clean-up. Except that the failure to update the revise text makes it very difficult for voters to appreciate potential collisions betwen their resolutions. I sent in a similar email last week about Issue 10946. Did it get lost? Regards Ed Willink -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: 29 September 2009 21:41 To: ocl2-rtf@omg.org Subject: Fwd: OCL 2.1 Issue 10436 resolution ignored X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAKcDwkrUnw6U/2dsb2JhbACTSMRJhB4F Date: Tue, 29 Sep 2009 20:56:53 +0100 From: Ed Willink User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) To: issues@omg.org Subject: OCL 2.1 Issue 10436 resolution ignored X-Plusnet-Relay: 268998831cd3b6dc894afd634d1bd6c2 Hi The OCL 2.1 RTF Beta final report providess Issue 10436 with a resolution. The OCL 2.1 Revised specification does not incorporate the revised text for issue 10436. Regards Ed Willink 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 **************************************************************************** Please consider the environment before printing this email. **************************************************************************** Thales Research and Technology (UK) Limited DISCLAIMER: The information contained in this e-mail is confidential. It may also be legally privileged. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained herein. Such unauthorised use may be unlawful. We may monitor all e-mail communications through our networks. If you have received this e-mail in error, please inform us immediately on +44 (0)1293 575987 and delete it and all copies from your system. We accept no responsibility for changes to any e-mail which occur after it has been sent. Attachments to this e-mail may contain software viruses which could damage your system. We therefore recommend you virus-check all attachments before opening. The registered office of Thales Research and Technology (UK) Limited is at: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered in England No. 774298. **************************************************************************** say just that.