Issue 14985: OCL 2.1 11.2 Conflicting {OclVoid, OclInvalid}::{oclIsTypeOf, oclIsKindOf, oclAsType} semantics (ocl2-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Uncategorized Issue Severity: Summary: 11.2.3 states clearly that "Any property call applied on null results in OclInvalid, except for the operations oclIsUndefined() and oclIsInvalid()." This is being revised by Issue 14197 in OCL 2.3 to: "Any property call applied on OclVoid results in invalid, except for the operations oclIsUndefined(), oclIsInvalid(), =(OclAny) and <>(OclAny)." 11.2.4 states clearly that "Any property call applied on invalid results in OclInvalid, except for the operations oclIsUndefined() and oclIsInvalid()." This is being revised by Issue 14197 in OCL 2.3 to: "Any property call applied on OclInvalid results in invalid, except for the operations oclIsUndefined() and oclIsInvalid()." Therefore invalid.oclIsTypeOf(OclInvalid) => invalid and null.oclIsTypeOf(OclVoid) => invalid. But the above are widely used in the specification as for example: "oclIsUndefined() : Boolean Evaluates to true if the self is equal to OclInvalid or equal to null. post: result = self.isTypeOf( OclVoid ) or self.isTypeOf(OclInvalid)" clearly expecting isTypeOf (a typo) to return true/false, not invalid sometimes. Issue 14197 relaxed the OclVoid property list to allow = and <>. Perhaps all oclXXX operations should have an explicitly defined semantics for OclVoid and OclInvalid, supporting rather than denying reflective usage of the values as in self.isTypeOf( OclVoid ). Resolution: Merged with Issue 18437. Disposition: See issue 18437 for disposition Revised Text: Actions taken: January 17, 2010: received issue December 23, 2013: closed issue Discussion: End of Annotations:===== ronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJIbVEtUXebi/2dsb2JhbADWPoQzBA Date: Mon, 18 Jan 2010 16:30:02 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 To: issues@omg.org Subject: OCL 2.1 11.2 Conflicting {OclVoid, OclInvalid}::{oclIsTypeOf, oclIsKindOf, oclAsType} semantics X-Plusnet-Relay: fd6912d678545cd82c3ad22053888461 Hi 11.2.3 states clearly that "Any property call applied on null results in OclInvalid, except for the operations oclIsUndefined() and oclIsInvalid()." This is being revised by Issue 14197 in OCL 2.3 to: "Any property call applied on OclVoid results in invalid, except for the operations oclIsUndefined(), oclIsInvalid(), =(OclAny) and <>(OclAny)." 11.2.4 states clearly that "Any property call applied on invalid results in OclInvalid, except for the operations oclIsUndefined() and oclIsInvalid()." This is being revised by Issue 14197 in OCL 2.3 to: "Any property call applied on OclInvalid results in invalid, except for the operations oclIsUndefined() and oclIsInvalid()." Therefore invalid.oclIsTypeOf(OclInvalid) => invalid and null.oclIsTypeOf(OclVoid) => invalid. But the above are widely used in the specification as for example: "oclIsUndefined() : Boolean Evaluates to true if the self is equal to OclInvalid or equal to null. post: result = self.isTypeOf( OclVoid ) or self.isTypeOf(OclInvalid)" clearly expecting isTypeOf (a typo) to return true/false, not invalid sometimes. Issue 14197 relaxed the OclVoid property list to allow = and <>. Perhaps all oclXXX operations should have an explicitly defined semantics for OclVoid and OclInvalid, supporting rather than denying reflective usage of the values as in self.isTypeOf( OclVoid ). Regards ' Sender: vsanchez@opencanarias.es Date: Wed, 20 Jan 2010 17:23:23 +0000 X-Google-Sender-Auth: 62bf96e3c1aee509 Subject: Re: issue 14985 -- OCL 2 RTF issue From: Victor Sanchez To: issues@omg.org, ocl2-rtf@omg.org Hello! Section 8.3.1, where "property call" is first mentioned, is confusing since relates OCL's FeatureCallExp with the UML's property call notion. From there on, property call is almost exclusively used in the scope of PropertyCallExp and related concepts. Since OperationCallExp does not inherit from PropertyCallExp, I would have expected to read "feature call" instead of "property call" in the following sentence: "Any property call applied on OclVoid results in invalid, except for the operations oclIsUndefined(), ..." It seems odd for an operation call to be treated like a property call. At least, an OperationCallExp is clearly not a PropertyCallExp from the abstract syntax perspective. Perhaps this might be treated as a separate issue. Regards, Victor Sáhez 2010/1/20 Juergen Boldt X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJIbVEtUXebi/2dsb2JhbADWPoQzBA Date: Mon, 18 Jan 2010 16:30:02 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 To: issues@omg.org Subject: OCL 2.1 11.2 Conflicting {OclVoid, OclInvalid}::{oclIsTypeOf, oclIsKindOf, oclAsType} semantics X-Plusnet-Relay: fd6912d678545cd82c3ad22053888461 Hi 11.2.3 states clearly that "Any property call applied on null results in OclInvalid, except for the operations oclIsUndefined() and oclIsInvalid()." This is being revised by Issue 14197 in OCL 2.3 to: "Any property call applied on OclVoid results in invalid, except for the operations oclIsUndefined(), oclIsInvalid(), =(OclAny) and <>(OclAny)." 11.2.4 states clearly that "Any property call applied on invalid results in OclInvalid, except for the operations oclIsUndefined() and oclIsInvalid()." This is being revised by Issue 14197 in OCL 2.3 to: "Any property call applied on OclInvalid results in invalid, except for the operations oclIsUndefined() and oclIsInvalid()." Therefore invalid.oclIsTypeOf(OclInvalid) => invalid and null.oclIsTypeOf(OclVoid) => invalid. But the above are widely used in the specification as for example: "oclIsUndefined() : Boolean Evaluates to true if the self is equal to OclInvalid or equal to null. post: result = self.isTypeOf( OclVoid ) or self.isTypeOf(OclInvalid)" clearly expecting isTypeOf (a typo) to return true/false, not invalid sometimes. Issue 14197 relaxed the OclVoid property list to allow = and <>. Perhaps all oclXXX operations should have an explicitly defined semantics for OclVoid and OclInvalid, supporting rather than denying reflective usage of the values as in self.isTypeOf( OclVoid ). 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 Ed Willink