Issue 15175: OCL 2.1 Navigation of opposites (ocl2-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Uncategorized Issue Severity: Summary: UML models may explicitly declare that a Property is not navigable in order to simplify the complexity of the run-time representation of that Property. In an EMOF representation, the non-navigable Property is missing and so an OCL constraint cannot use it, even though the OCL constraint is used at compile-time rather than run-time. In a UML direction, a Property may be unnamed in one direction and the implicit naming of such opposites may be inadequate to permit unambiguous usage. QVT Relations 1.1 partially works around this by introducing an opposite(Property) declaration that may be used for Keys and PropertyTemplateItems. OCL, rather than QVT, should provide an ability to navigate a Property in an opposite direction. In the Abstract Syntax, OppositePropertyCallExp is required to capture the inverse navigation semantics of PropertyCallExp. In the Concrete Syntax, some alternate navigation operator is required. Perhaps "a.~b" indicates that "b" is in an inverted direction. Resolution: Revised Text: Actions taken: April 13, 2010: received issue Discussion: End of Annotations:===== ronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0GAEadw0tUXebz/2dsb2JhbACPaotdcbsKhQwE Date: Tue, 13 Apr 2010 06:24:13 +0100 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 Navigation of opposites X-Plusnet-Relay: 7607d0fa464aa0b19816c7be8231ae4e Hi UML models may explicitly declare that a Property is not navigable in order to simplify the complexity of the run-time representation of that Property. In an EMOF representation, the non-navigable Property is missing and so an OCL constraint cannot use it, even though the OCL constraint is used at compile-time rather than run-time. In a UML direction, a Property may be unnamed in one direction and the implicit naming of such opposites may be inadequate to permit unambiguous usage. QVT Relations 1.1 partially works around this by introducing an opposite(Property) declaration that may be used for Keys and PropertyTemplateItems. OCL, rather than QVT, should provide an ability to navigate a Property in an opposite direction. In the Abstract Syntax, OppositePropertyCallExp is required to capture the inverse navigation semantics of PropertyCallExp. In the Concrete Syntax, some alternate navigation operator is required. Perhaps "a.~b" indicates that "b" is in an inverted direction. Regards From: "Uhl, Axel" To: "ocl2-rtf@omg.org" Date: Tue, 27 Apr 2010 14:35:14 +0200 Subject: [Issue 15175] Navigation of Opposites Thread-Topic: [Issue 15175] Navigation of Opposites Thread-Index: AcrmBhWyeZIa9bNyR4quTVtccPsJ0g== Accept-Language: en-US, de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o3RCOoUO007745 Ed, all, I explicitly support the OCL enhancement towards introducing OppositePropertyCallExp proposed by #15175. It makes reverse navigation explicit in the OCL AST and therefore allows for static analysis of the navigations performed by an expression. This in turn enables incremental re-evaluation based on change event notifications which is essential for OCL constraint re-enforcement in large models. Regarding the concrete syntax proposed by Ed, there has been a related discussion in https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 that contemplates ways to provide a name that can be used to identify the opposite navigation direction. If such annotations are used, the existing concrete syntax for property call expressions could still be used which in addition may provide better readability. In any case, for the EMOF case, metamodel query capabilities will be required to locate the property to be traversed in reverse, even if identified by the name of the forward property, because there is no standard way to navigate from the type of the source expression to the reference that refers to the source expression's type or any of its supertypes. Additionally, query capabilities will be required from the EMOF implementations to support the actual reverse navigation. It is instrumental to define a scope for such queries, similar to how a scope (extent) is defined for an allInstances() expression. In the EMF world, the query2 component (so far published as a prototype) could play this role, both, for metamodel and model queries. Best, -- Axel From: "Willink, Ed" To: "'Uhl, Axel'" , ocl2-rtf@omg.org Subject: RE: [Issue 15175] Navigation of Opposites Date: Tue, 27 Apr 2010 14:43:28 +0100 X-Mailer: Internet Mail Service (5.5.2657.72) Hi Axel OppositePropertyCallExp is obviously needed in the Abstract Syntax. -- A concrete syntax enhancement may be needed: a) to navigate opposite references that were never named and whose implicit name is ambiguous b) to navigate opposite references whose name is not available (and whose implicit name is ambiguous) Arguably a) was not intended to be navigated and it is rare for implicit names to be ambiguous, so this may not need a fix. b) is a problem for pure EMOF (or Ecore) models since non-navigable opposites are stripped. If the convention described in http://www.omg.org/issues/mof2core-rtf.open.html#Issue12800 is endorsed, then a concrete syntax fix for b) is not necessary. OCL tools will need to be modified either to support Issue 12800, or to support a changed concrete syntax, or both. Is the need for a concrete syntax to rescue the avoidable loss of meta-model information great enough to justify it? -- I'm not sure why anything needs to be said about query spaces. The opposite navigation is equivalent to a search of allInstances() that reference self through the 'forward' property. The domain of allInstances is an implementation detail. Efficient strategies for reverse navigation are an implementation issue. It is soluble, so the OCL specification can ignore this aspect of the problem. Regards Ed Willink > -----Original Message----- > From: Uhl, Axel [mailto:axel.uhl@sap.com] > Sent: 27 April 2010 13:35 > To: ocl2-rtf@omg.org > Subject: [Issue 15175] Navigation of Opposites > > Ed, all, > > I explicitly support the OCL enhancement towards introducing > OppositePropertyCallExp proposed by #15175. It makes reverse > navigation explicit in the OCL AST and therefore allows for > static analysis of the navigations performed by an > expression. This in turn enables incremental re-evaluation > based on change event notifications which is essential for > OCL constraint re-enforcement in large models. > > Regarding the concrete syntax proposed by Ed, there has been > a related discussion in > https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 that > contemplates ways to provide a name that can be used to > identify the opposite navigation direction. If such > annotations are used, the existing concrete syntax for > property call expressions could still be used which in > addition may provide better readability. > > In any case, for the EMOF case, metamodel query capabilities > will be required to locate the property to be traversed in > reverse, even if identified by the name of the forward > property, because there is no standard way to navigate from > the type of the source expression to the reference that > refers to the source expression's type or any of its supertypes. > > Additionally, query capabilities will be required from the > EMOF implementations to support the actual reverse > navigation. It is instrumental to define a scope for such > queries, similar to how a scope (extent) is defined for an > allInstances() expression. In the EMF world, the query2 > component (so far published as a prototype) could play this > role, both, for metamodel and model queries. > > Best, > -- Axel > **************************************************************************** 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. **************************************************************************** From: "Uhl, Axel" To: "Willink, Ed" , "ocl2-rtf@omg.org" Date: Tue, 27 Apr 2010 16:00:00 +0200 Subject: RE: [Issue 15175] Navigation of Opposites Thread-Topic: [Issue 15175] Navigation of Opposites Thread-Index: AcrmD6K2mSvrOvnHREChdyOJGs4WlQAAZF2g Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o3RDoLwO004465 Hi Ed, yes, scoping can be left as an implementation detail. It should be based on the scope of allInstances() to avoid inconsistencies. Maybe the spec should make explicit at least this consistency requirement. If Issue 12800 is supported, and furthermore the implicit names can be used in case they are unambiguous, I think the cost for introducing special concrete syntax to create an OppositePropertyCallExp by referring to the forward property is hardly justified by the few cases where it is for some reason not possible to provide an Issue 12800-style comment and the implicit name is ambiguous. The modifications for Issue 12800 we have prototypically implemented for EMF, based on the query2 prototype, with good success as far as it seems today. Best, -- Axel > -----Original Message----- > From: Willink, Ed [mailto:Ed.Willink@thalesgroup.com] > Sent: Tuesday, April 27, 2010 3:43 PM > To: Uhl, Axel; ocl2-rtf@omg.org > Subject: RE: [Issue 15175] Navigation of Opposites > > Hi Axel > > OppositePropertyCallExp is obviously needed in the Abstract Syntax. > > -- > > A concrete syntax enhancement may be needed: > > a) to navigate opposite references that were never named and whose > implicit name is ambiguous > b) to navigate opposite references whose name is not available (and > whose > implicit name is ambiguous) > > Arguably a) was not intended to be navigated and it is rare for > implicit > names > to be ambiguous, so this may not need a fix. > > b) is a problem for pure EMOF (or Ecore) models since non-navigable > opposites are stripped. > If the convention described in > http://www.omg.org/issues/mof2core-rtf.open.html#Issue12800 > is endorsed, then a concrete syntax fix for b) is not necessary. > > OCL tools will need to be modified either to support Issue 12800, or to > support a > changed concrete syntax, or both. Is the need for a concrete syntax to > rescue > the avoidable loss of meta-model information great enough to justify > it? > > -- > > I'm not sure why anything needs to be said about query spaces. > > The opposite navigation is equivalent to a search of allInstances() > that > reference self through the 'forward' property. > > The domain of allInstances is an implementation detail. Efficient > strategies > for reverse navigation are an implementation issue. It is soluble, so > the OCL specification can ignore this aspect of the problem. > > Regards > > Ed Willink > > > -----Original Message----- > > From: Uhl, Axel [mailto:axel.uhl@sap.com] > > Sent: 27 April 2010 13:35 > > To: ocl2-rtf@omg.org > > Subject: [Issue 15175] Navigation of Opposites > > > > Ed, all, > > > > I explicitly support the OCL enhancement towards introducing > > OppositePropertyCallExp proposed by #15175. It makes reverse > > navigation explicit in the OCL AST and therefore allows for > > static analysis of the navigations performed by an > > expression. This in turn enables incremental re-evaluation > > based on change event notifications which is essential for > > OCL constraint re-enforcement in large models. > > > > Regarding the concrete syntax proposed by Ed, there has been > > a related discussion in > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 that > > contemplates ways to provide a name that can be used to > > identify the opposite navigation direction. If such > > annotations are used, the existing concrete syntax for > > property call expressions could still be used which in > > addition may provide better readability. > > > > In any case, for the EMOF case, metamodel query capabilities > > will be required to locate the property to be traversed in > > reverse, even if identified by the name of the forward > > property, because there is no standard way to navigate from > > the type of the source expression to the reference that > > refers to the source expression's type or any of its supertypes. > > > > Additionally, query capabilities will be required from the > > EMOF implementations to support the actual reverse > > navigation. It is instrumental to define a scope for such > > queries, similar to how a scope (extent) is defined for an > > allInstances() expression. In the EMF world, the query2 > > component (so far published as a prototype) could play this > > role, both, for metamodel and model queries. > > > > Best, > > -- Axel > > > > *********************************************************************** > ***** > 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. > *********************************************************************** X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADTYskxUXebj/2dsb2JhbACiDnHCQYMNgjsE Date: Mon, 11 Oct 2010 17:29:29 +0100 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: "ocl2-rtf@omg.org" Subject: Fwd: Issue 15175 - Navigation of opposites (was RE: Issue 15270 - Definition for symmetric difference is wrong) Hi Juergen: 15175 is the correct location for this note. No need to add to 15270. The OCL 2.x spec should mention the availability of "org.omg.emof.oppositeRoleName" when discussing EMOF usage. Regards Ed Willink -------- Original Message -------- Subject: RE: Issue 15270 - Definition for symmetric difference is wrong Date: Mon, 11 Oct 2010 06:55:14 -0700 From: Pete Rivett To: Ed Willink , Note that Axel Uhl's proposed resolution to MOF2 Core issue 12800 was accepted. That should be reflected in this resolution. The essence of it as follows: Add a new Section, specifically Section 12.6 named "Predefined Tags" that reads as follows: This Section defines a predefined Tag whose name is "org.omg.emof.oppositeRoleName" which can be applied to instances of Property within instances of the EMOF model. Constraints context Tag inv: --The predefined Tag can only be applied to instances of Property whose "opposite" Property is empty name = "org.omg.emof.oppositeRoleName" implies element.oclIsKindOf(Property) and element.oclAsType(Property).opposite->isEmpty() Semantics If an instance of a Tag has "org.omg.emof.oppositeRoleName" as its "name", then its "value" specifies a role name that expressions can use to traverse in the opposite direction of the Property, such as OCL expressions and QVT expressions. If an expression uses a role name specified using a Tag with "name" "org.omg.emof.oppositeRoleName", and more than one Property has such a Tag with that role name, then it is up to the expression language to decide whether this is an error condition or represents a reverse navigation across all those Properties. An expression language should not choose to pick one such Property at random in case of ambiguity. .... It is beyond the scope of MOF Core to specify the concrete syntax that expressions use for traversal via the org.omg.emof.oppositeRoleName in languages such as OCL and QVT. Regards Pete -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: Saturday, October 09, 2010 7:39 AM To: ocl2-rtf@omg.org Subject: Re: Issue 15270 - Definition for symmetric difference is wrong Hi Attached is a proposed resolution. Regards Ed Willink Ed Willink X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPxupkzUnw4U/2dsb2JhbACiP3HEPIVEBA Date: Sat, 02 Oct 2010 07:32:04 +0100 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: "ocl2-rtf@omg.org" Subject: Re: [Issue 15175] Navigation of Opposites Hi Axel Just read your MODELS OCL workshop paper on OppositePropertyCallExp on Property.oppositeRoleName. Oddly it doesn't mention the evolution of MOF Issue 12800 to endorse an "org.omg.emof.oppositeRoleName" tag. After originally proposing a similar idea, I've now come round to opposing it. The tag does no harm, but will inevitably take time to be uniformly adopted. It is part of a bigger issue with a simple solution specification-wise; rather unpleasant implementation-wise. Complete OCL is a merging technology. It adds features to already existing classes. How, why and when it does this is an under-specified mystery. There is no reason why a Complete OCL syntax shouldn't define the opposite of an existing feature. This could be a full definition including multiplicities, and could name unnamed opposites. It is perhaps a different specification issue that Complete OCL can define two opposite features, but only declare them as opposites using invariants. A Complete OCL opposite syntax creates no new implementation issues, just highlights the old ones; additional operations and properties must already be added to an existing meta-model so that they are indistinguishable from pre-existing ones. Therefore, somehow, a metamodel (Ecore, EMOF, CMOF or UML) has one or more complementing Complete OCL documents that enhance its semantics. An implementation loads these complements to provide the complete environment for OCL execution. The OCL environment must support a 'run-time' meta-model that is different to the simple 'compile-time' one. Therefore, when a user's meta-model is trimmed to the minimum Essential EMOF representation, a Complete OCL document can be produced to capture all the lost declarations. We just need a Complete OCL syntax to define opposites. No need for a MOF tag. No need for an OppositePropertyCall because Complete OCL will reify the opposite Property. Perhaps MOF tags provide the URIs of known Complete OCL documents. Perhaps an independent registry binds Complete OCL documents to meta-models. Regards Ed Willink