Issue 12800: Capturing Unnavigable Opposite Property Role Names (mof2core-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Uncategorized Issue Severity: Summary: EMOF does not support identification of the opposite role name for a non-navigable association, however QVT requires such role names to be used. OCL defines an implicit role name, but UML graphics supports arbitrary names. At the EclipseCon OMG symposium in February, it seemed appropriate to resolve the limitation in the following way. An opposite role name may be denoted by a Comment Comment with the inner Comment defining a formal function for the outer Comment. Thus in: <ownedAttribute name="forward" ...> <ownedComment body="backward"> <ownedComment body="http://schema.omg.org/spec/MOF/2.0/emof.xml#Property.oppositeRoleName"/> </ownedComment> </ownedAttribute> "backward" is defined as the oppositeRoleName of "forward". This practice makes the missing information available, and avoids any changes to the MOF meta-model and so avoids introducing any additional Property instances that might bloat existing usage. It would be helpful if a future MOF version, or an addendum to existing versions, endorse this practice. An equivalent Ecore EAnnotation and cross-conversion was introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede). Resolution: The use of ‘non-navigable’ is out-dated: the issue is where Property::opposite is empty and there is nothing to hang the name on. Further email exchanges on the RTF list discussed using an EMOF Tag instead of a Comment. So the proposed resolution is to introduce an EMOF Tag named “org.omg.emof.oppositeRoleName” that can be applied only to a Property whose “opposite” Property is empty. The “value” of this Tag specifies a role name that expressions (such as OCL expressions and QVT expressions) can use to traverse in the opposite direction of the Property. Revised Text: 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. Rationale Use of this Tag is lighter weight than using Property’s “opposite” Property. Use of the “opposite” Property in all cases where what is required is only the ability for expressions to traverse in the opposite direction would have the following negative consequences: • It would result in tighter coupling among Classes • It would add to the runtime burden that instances of the model place upon the underlying infrastructure that manages them, by: 1) increasing the overall footprint, since the opposite Property adds substantially to the contract of the Class that owns the additional Property designated as the opposite of the original Property; 2) requiring that storage be allocated for instances of the additional Property; and 3) requiring that referential integrity be maintained in storage among instances of the original Property and instances of the additional Property. 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. Actions taken: August 31, 2008: received issue April 25, 2011: closed issue Discussion: End of Annotations:===== m: "Ed Willink" To: Subject: Capturing Unnavigable Opposite Property Role Names Date: Sun, 31 Aug 2008 11:18:59 +0100 X-Mailer: Microsoft Outlook, Build 10.0.6838 Thread-Index: AckLUvtMI6L2FlmXTX+N8a5rHYAHvA== X-Plusnet-Relay: 8dbc72fff8934a620d21264dd85380f1 Hi EMOF does not support identification of the opposite role name for a non-navigable association, however QVT requires such role names to be used. OCL defines an implicit role name, but UML graphics supports arbitrary names. At the EclipseCon OMG symposium in February, it seemed appropriate to resolve the limitation in the following way. An opposite role name may be denoted by a Comment Comment with the inner Comment defining a formal function for the outer Comment. Thus in: "backward" is defined as the oppositeRoleName of "forward". This practice makes the missing information available, and avoids any changes to the MOF meta-model and so avoids introducing any additional Property instances that might bloat existing usage. It would be helpful if a future MOF version, or an addendum to existing versions, endorse this practice. An equivalent Ecore EAnnotation and cross-conversion was introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede). Regards Subject: Discussion on MOF2 Core Issue 12800 Date: Thu, 29 Apr 2010 14:32:25 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Discussion on MOF2 Core Issue 12800 Thread-Index: Acrn43YWv9trHr6NSi+PrQ6MsUczWQ== From: "Pete Rivett" To: , "Jim Amsden" Cc: "Ed Willink" , "Uhl, Axel" Below is the issue and my original response: I removed it from the ballot since Jim had raised a comment and I realized the proposal was not complete (e.g. did not define the name of the Tag) so it needed discussion. This email is intended to start such a discussion. I.m going on vacation for a week so hopefully you.ll all have it sorted by the time I get back J BTW Ed, EMOF (as well as CMOF) does include Tags . see Figure 12.1 in formal/06-06-01 where you can see that EMOF merges in the Extension package which defines Tag. Jim wrote: EMOF does not have associations. Rather it uses a notation option for properties that have non-primitive types that uses CMOF association notation. So there are no member or owned ends of the association. Rather QVT should treat these as properties which not non-navigable associations, and there would be no need to a name for the un-named end. Issue 12800: Capturing Unnavigable Opposite Property Role Names (mof2core-rtf) Click here for this issue's archive. Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@willink.me.uk) Nature: Uncategorized Issue Severity: Summary: EMOF does not support identification of the opposite role name for a non-navigable association, however QVT requires such role names to be used. OCL defines an implicit role name, but UML graphics supports arbitrary names. At the EclipseCon OMG symposium in February, it seemed appropriate to resolve the limitation in the following way. An opposite role name may be denoted by a Comment Comment with the inner Comment defining a formal function for the outer Comment. Thus in: "backward" is defined as the oppositeRoleName of "forward". This practice makes the missing information available, and avoids any changes to the MOF meta-model and so avoids introducing any additional Property instances that might bloat existing usage. It would be helpful if a future MOF version, or an addendum to existing versions, endorse this practice. An equivalent Ecore EAnnotation and cross-conversion was introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede). Resolution: The use of .non-navigable. is out-dated: the issue is where Property::opposite is empty and there is nothing to hang the name on. This would seem better addressed by the use of a MOF Tag rather than two nested Comments. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 tel: +1 949 330 7677, cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp From: "Uhl, Axel" To: "'pete.rivett@adaptive.com'" , "'mof2core-rtf@omg.org'" , "'jamsden@us.ibm.com'" CC: "'ed@willink.me.uk'" Date: Fri, 30 Apr 2010 00:20:11 +0200 Subject: Re: Discussion on MOF2 Core Issue 12800 Thread-Topic: Discussion on MOF2 Core Issue 12800 Thread-Index: Acrn43YWv9trHr6NSi+PrQ6MsUczWQABqwXF Accept-Language: en-US, de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Pete, thanks for kicking this off. At some other place Ed already proposed "Property.oppositeRoleName" as tag name which seemed to make sense to me. Jim, do you still have general objections to introducing such a standard tag? If so, look at OCL issue 15175 where with a naming tag for the non-existing opposite we can save a concrete syntax extension for OCL and make navigation in these directions more intuitive. Best, -- Axel ------------------ Sent from BB -------------------------------------------------------------------------------- From: Pete Rivett To: mof2core-rtf@omg.org ; Jim Amsden Cc: Ed Willink ; Uhl, Axel Sent: Thu Apr 29 23:32:25 2010 Subject: Discussion on MOF2 Core Issue 12800 Below is the issue and my original response: I removed it from the ballot since Jim had raised a comment and I realized the proposal was not complete (e.g. did not define the name of the Tag) so it needed discussion. This email is intended to start such a discussion. Iâm going on vacation for a week so hopefully youâll all have it sorted by the time I get back J BTW Ed, EMOF (as well as CMOF) does include Tags . see FFigure 12.1 in formal/06-06-01 where you can see that EMOF merges in the Extension package which defines Tag. Jim wrote: EMOF does not have associations. Rather it uses a notation option for properties that have non-primitive types that uses CMOF association notation. So there are no member or owned ends of the association. Rather QVT should treat these as properties which not non-navigable associations, and there would be no need to a name for the un-named end. Issue 12800: Capturing Unnavigable Opposite Property Role Names (mof2core-rtf) Click here for this issue's archive. Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@willink.me.uk) Nature: Uncategorized Issue Severity: Summary: EMOF does not support identification of the opposite role name for a non-navigable association, however QVT requires such role names to be used. OCL defines an implicit role name, but UML graphics supports arbitrary names. At the EclipseCon OMG symposium in February, it seemed appropriate to resolve the limitation in the following way. An opposite role name may be denoted by a Comment Comment with the inner Comment defining a formal function for the outer Comment. Thus in: "backward" is defined as the oppositeRoleName of "forward". This practice makes the missing information available, and avoids any changes to the MOF meta-model and so avoids introducing any additional Property instances that might bloat existing usage. It would be helpful if a future MOF version, or an addendum to existing versions, endorse this practice. An equivalent Ecore EAnnotation and cross-conversion was introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede). Resolution: The use of ânon-navigableâ is out-dated: the issue is where Property::opposite is empty and there is nothing to hang the name on. This would seem better addressed by the use of a MOF Tag rather than two nested Comments. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 tel: +1 949 330 7677, cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp Subject: RE: Discussion on MOF2 Core Issue 12800 Date: Thu, 29 Apr 2010 16:29:32 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Discussion on MOF2 Core Issue 12800 Thread-Index: Acrn43YWv9trHr6NSi+PrQ6MsUczWQABqwXFAAIZWyA= From: "Pete Rivett" To: "Uhl, Axel" Cc: , , I think to stick with the naming convention used for XMI, if we do this it should be org.omg.emof.oppositePropertyName. Another question: is an unqualified name sufficient? I.m assuming it is for OCL/QVT purposes but are there other potential uses? An even broader question: when mapping from a CMOF metamodel, such as UML, to EMOF, is it a good idea to assume that each Association maps directly to one, or a linked pair of, Properties? An alternative and more faithful (to the semantics) mapping would be to introduce an EMOF class for each CMOF Association with the same name as the association (yes, each association in the UML metamodel does have an explicit name in the normative XMI file for the metamodel). Pete From: Uhl, Axel [mailto:axel.uhl@sap.com] Sent: Thursday, April 29, 2010 3:20 PM To: Pete Rivett; 'mof2core-rtf@omg.org'; 'jamsden@us.ibm.com' Cc: 'ed@willink.me.uk' Subject: Re: Discussion on MOF2 Core Issue 12800 Pete, thanks for kicking this off. At some other place Ed already proposed "Property.oppositeRoleName" as tag name which seemed to make sense to me. Jim, do you still have general objections to introducing such a standard tag? If so, look at OCL issue 15175 where with a naming tag for the non-existing opposite we can save a concrete syntax extension for OCL and make navigation in these directions more intuitive. Best, -- Axel ------------------ Sent from BB -------------------------------------------------------------------------------- From: Pete Rivett To: mof2core-rtf@omg.org ; Jim Amsden Cc: Ed Willink ; Uhl, Axel Sent: Thu Apr 29 23:32:25 2010 Subject: Discussion on MOF2 Core Issue 12800 Below is the issue and my original response: I removed it from the ballot since Jim had raised a comment and I realized the proposal was not complete (e.g. did not define the name of the Tag) so it needed discussion. This email is intended to start such a discussion. I.m going on vacation for a week so hopefully you.ll all have it sorted by the time I get back J BTW Ed, EMOF (as well as CMOF) does include Tags . see Figure 12.1 in formal/06-06-011 where you can see that EMOF merges in the Extension package which defines Tag. Jim wrote: EMOF does not have associations. Rather it uses a notation option for properties that have non-primitive types that uses CMOF association notation. So there are no member or owned ends of the association. Rather QVT should treat these as properties which not non-navigable associations, and there would be no need to a name for the un-named end. Issue 12800: Capturing Unnavigable Opposite Property Role Names (mof2core-rtf) Click here for this issue's archive. Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@willink.me.uk) Nature: Uncategorized Issue Severity: Summary: EMOF does not support identification of the opposite role name for a non-navigable association, however QVT requires such role names to be used. OCL defines an implicit role name, but UML graphics supports arbitrary names. At the EclipseCon OMG symposium in February, it seemed appropriate to resolve the limitation in the following way. An opposite role name may be denoted by a Comment Comment with the inner Comment defining a formal function for the outer Comment. Thus in: "backward" is defined as the oppositeRoleName of "forward". This practice makes the missing information available, and avoids any changes to the MOF meta-model and so avoids introducing any additional Property instances that might bloat existing usage. It would be helpful if a future MOF version, or an addendum to existing versions, endorse this practice. An equivalent Ecore EAnnotation and cross-conversion was introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede). Resolution: The use of .non-navigable. is out-dated: the issue is where Property::opposite is empty and there is nothing to hang the name on. This would seem better addressed by the use of a MOF Tag rather than two nested Comments. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 tel: +1 949 330 7677, cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp From: "Rouquette, Nicolas F (316A)" To: Pete Rivett CC: Ed Willink , "mof2core-rtf@omg.org" , Jim Amsden Date: Thu, 29 Apr 2010 16:52:38 -0700 Subject: Re: Discussion on MOF2 Core Issue 12800 Thread-Topic: Discussion on MOF2 Core Issue 12800 Thread-Index: Acrn9w2hC5Qy9GRwTyKKvaSHpb0C+w== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Thanks Pete; I haven't seen this. I have a concern about 12800. Based on the Eclipse Bugzilla issue he referenced, I honestly don't understand what is the purpose of Property::oppositeRoleName. The example shown in the bugzilla issue involves a half-baked example in XMI that is difficult to understand. In particular, I would really like for someone to clearly explain why Property::oppositeRoleName is needed. I am suspicious that this issue may have arisen in the context of implementing OCL/QVTo in the Eclipse EMF architecture as if it were EMOF. This approximation breaks down in that Eclipse EMF doesn't have a 1st-class concept of Association corresponding to MOF2 Association. This has some subtle implications. Basically, support for associations in, e.g., Eclipse UML, is tightly coupled with the Eclipse EMF/UML code generation strategy. To get a better sense of this, compare the Eclipse UML API with the API of other UML tools that are based on JMI -- e.g., MagicDraw's open API. Code generation aside, from the MOF point of view, it seems to me that there is really no need for Property::oppositeRoleName. EMOF is pretty tight as it is about enforcing consistent management of properties & their opposite properties as evidenced below: 9.2 [12] Property: Bidirectional opposite ends must reference each other. 12.5 Property::isComposite=true Adding a container updates both the container and containment properties on the contained and containing objects, respectively. The opposite end is updated first. 12.5 Property::isComposite=false, Bidirectional The object is first removed from the opposite end of the property. If the new value.s opposite property is of multiplicity upper bound == 1, its old value is removed. This object is added to the new value.s opposite property. The new value is added to this property. Can someone then please clarify whether this issue is really necessary for MOF2? If it is not, then perhaps the Eclipse bugzilla 229998 should be re-opened to reconsider the strategy for supporting Association & association end properties & their opposites properly in Eclipse EMF. - Nicolas. On Apr 29, 2010, at 4:08 PM, Pete Rivett wrote: Hi Nicolas, not sure if you.re on the MOF Core RTF and thought you might be interested in this discussion . given your interest in OCL, QVT and EMF. Pete PS I.m going on vacation tomorrow, back on May 10th. From: Uhl, Axel [mailto:axel.uhl@sap.com] Sent: Thursday, April 29, 2010 3:20 PM To: Pete Rivett; 'mof2core-rtf@omg.org'; 'jamsden@us.ibm.com' Cc: 'ed@willink.me.uk' Subject: Re: Discussion on MOF2 Core Issue 12800 Pete, thanks for kicking this off. At some other place Ed already proposed "Property.oppositeRoleName" as tag name which seemed to make sense to me. Jim, do you still have general objections to introducing such a standard tag? If so, look at OCL issue 15175 where with a naming tag for the non-existing opposite we can save a concrete syntax extension for OCL and make navigation in these directions more intuitive. Best, -- Axel ------------------ Sent from BB -------------------------------------------------------------------------------- From: Pete Rivett To: mof2core-rtf@omg.org ; Jim Amsden Cc: Ed Willink ; Uhl, Axel Sent: Thu Apr 29 23:32:25 2010 Subject: Discussion on MOF2 Core Issue 12800 Below is the issue and my original response: I removed it from the ballot since Jim had raised a comment and I realized the proposal was not complete (e.g. did not define the name of the Tag) so it needed discussion. This email is intended to start such a discussion. I.m going on vacation for a week so hopefully you.ll all have it sorted by the time I get back J BTW Ed, EMOF (as well as CMOF) does include Tags . see Figure 12.1 in formal/06-06-01 where you can see that EMOF merges in the Extension package which defines Tag. Jim wrote: EMOF does not have associations. Rather it uses a notation option for properties that have non-primitive types that uses CMOF association notation. So there are no member or owned ends of the association. Rather QVT should treat these as properties which not non-navigable associations, and there would be no need to a name for the un-named end. Issue 12800: Capturing Unnavigable Opposite Property Role Names (mof2core-rtf) Click here for this issue's archive. Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@willink.me.uk) Nature: Uncategorized Issue Severity: Summary: EMOF does not support identification of the opposite role name for a non-navigable association, however QVT requires such role names to be used. OCL defines an implicit role name, but UML graphics supports arbitrary names. At the EclipseCon OMG symposium in February, it seemed appropriate to resolve the limitation in the following way. An opposite role name may be denoted by a Comment Comment with the inner Comment defining a formal function for the outer Comment. Thus in: "backward" is defined as the oppositeRoleName of "forward". This practice makes the missing information available, and avoids any changes to the MOF meta-model and so avoids introducing any additional Property instances that might bloat existing usage. It would be helpful if a future MOF version, or an addendum to existing versions, endorse this practice. An equivalent Ecore EAnnotation and cross-conversion was introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede). Resolution: The use of .non-navigable. is out-dated: the issue is where Property::opposite is empty and there is nothing to hang the name on. This would seem better addressed by the use of a MOF Tag rather than two nested Comments. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 tel: +1 949 330 7677, cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp X-Auth-ID: koethe Subject: Re: Discussion on MOF2 Core Issue 12800 From: "Manfred R. Koethe" Date: Thu, 29 Apr 2010 21:33:33 -0400 Cc: "'pete.rivett@adaptive.com'" , "'mof2core-rtf@omg.org'" , "'jamsden@us.ibm.com'" , "'ed@willink.me.uk'" To: "Uhl, Axel" X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1078) X-Junkmail-Status: score=10/50, host=mr02.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A020209.4BDA3395.00AE,ss=1,fgs=0, ip=207.172.4.11, so=2009-09-21 22:56:10, dmn=5.4.3/2007-10-18, mode=single engine X-Junkmail-IWF: false This tag would also assist EMOF implementations to preserve referential integrity. Manfred On Apr 29, 2010, at 18:20 , Uhl, Axel wrote: Pete, thanks for kicking this off. At some other place Ed already proposed "Property.oppositeRoleName" as tag name which seemed to make sense to me. Jim, do you still have general objections to introducing such a standard tag? If so, look at OCL issue 15175 where with a naming tag for the non-existing opposite we can save a concrete syntax extension for OCL and make navigation in these directions more intuitive. Best, -- Axel ------------------ Sent from BB -------------------------------------------------------------------------------- From: Pete Rivett To: mof2core-rtf@omg.org ; Jim Amsden Cc: Ed Willink ; Uhl, Axel Sent: Thu Apr 29 23:32:25 2010 Subject: Discussion on MOF2 Core Issue 12800 Below is the issue and my original response: I removed it from the ballot since Jim had raised a comment and I realized the proposal was not complete (e.g. did not define the name of the Tag) so it needed discussion. This email is intended to start such a discussion. I.m going on vacation for a week so hopefully you.ll all have it sorted by the time I get back J BTW Ed, EMOF (as well as CMOF) does include Tags . see Figure 12.1 in formal/06-06-01 where you can see that EMOF merges in the Extension package which defines Tag. Jim wrote: EMOF does not have associations. Rather it uses a notation option for properties that have non-primitive types that uses CMOF association notation. So there are no member or owned ends of the association. Rather QVT should treat these as properties which not non-navigable associations, and there would be no need to a name for the un-named end. Issue 12800: Capturing Unnavigable Opposite Property Role Names (mof2core-rtf) Click here for this issue's archive. Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@willink.me.uk) Nature: Uncategorized Issue Severity: Summary: EMOF does not support identification of the opposite role name for a non-navigable association, however QVT requires such role names to be used. OCL defines an implicit role name, but UML graphics supports arbitrary names. At the EclipseCon OMG symposium in February, it seemed appropriate to resolve the limitation in the following way. An opposite role name may be denoted by a Comment Comment with the inner Comment defining a formal function for the outer Comment. Thus in: "backward" is defined as the oppositeRoleName of "forward". This practice makes the missing information available, and avoids any changes to the MOF meta-model and so avoids introducing any additional Property instances that might bloat existing usage. It would be helpful if a future MOF version, or an addendum to existing versions, endorse this practice. An equivalent Ecore EAnnotation and cross-conversion was introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede). Resolution: The use of .non-navigable. is out-dated: the issue is where Property::opposite is empty and there is nothing to hang the name on. This would seem better addressed by the use of a MOF Tag rather than two nested Comments. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 tel: +1 949 330 7677, cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp --------------------------------------------------------------- ==> Please note our new FAX Number <== --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (617) 848 0525 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)-------- PGP4.sig To: "'mof2core-rtf@omg.org'" Subject: Re: Discussion on MOF2 Core Issue 12800 X-KeepSent: 24702DE0:B89D4BB4-85257715:000B39ED; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 From: Jim Amsden Date: Thu, 29 Apr 2010 22:10:39 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 04/29/2010 20:10:40, Serialize complete at 04/29/2010 20:10:40 I do object to this. EMF has been built on EMOF concepts for years. We have developed a large number of transforms that have not needed this extra property. If associations are needed by a tool, then it should use CMOF, not EMOF. If a modeler needs something like an association in EMOF/EMF, then they can use the mediator pattern reasonably effectively. I also do not believe EMOF should specify or require any tags to support structural modeling. Tags were for extensibility, not fundamental metamodel concepts. Such an addition would need to have compelling use cases that cannot be addressed by other means. The concept of association was explicitly kept out of EMOF. I do not believe we should graft something back in using tags to simulate association ends. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: "'pete.rivett@adaptive.com'" , "'mof2core-rtf@omg.org'" , Jim Amsden/Raleigh/IBM@IBMUS Cc: "'ed@willink.me.uk'" Date: 04/29/2010 06:21 PM Subject: Re: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Pete, thanks for kicking this off. At some other place Ed already proposed "Property.oppositeRoleName" as tag name which seemed to make sense to me. Jim, do you still have general objections to introducing such a standard tag? If so, look at OCL issue 15175 where with a naming tag for the non-existing opposite we can save a concrete syntax extension for OCL and make navigation in these directions more intuitive. Best, -- Axel ------------------ Sent from BB -------------------------------------------------------------------------------- From: Pete Rivett To: mof2core-rtf@omg.org ; Jim Amsden Cc: Ed Willink ; Uhl, Axel Sent: Thu Apr 29 23:32:25 2010 Subject: Discussion on MOF2 Core Issue 12800 Below is the issue and my original response: I removed it from the ballot since Jim had raised a comment and I realized the proposal was not complete (e.g. did not define the name of the Tag) so it needed discussion. This email is intended to start such a discussion. Iâm going on vacation for a week so hopefully youâll all have it sorted by the time I get back J BTW Ed, EMOF (as well as CMOF) does include Tags . see Figure 12..1 in formal/06-06-01 where you can see that EMOF merges in the Extension package which defines Tag. Jim wrote: EMOF does not have associations. Rather it uses a notation option for properties that have non-primitive types that uses CMOF association notation. So there are no member or owned ends of the association. Rather QVT should treat these as properties which not non-navigable associations, and there would be no need to a name for the un-named end. Issue 12800: Capturing Unnavigable Opposite Property Role Names (mof2core-rtf) Click here for this issue's archive. Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@willink.me.uk) Nature: Uncategorized Issue Severity: Summary: EMOF does not support identification of the opposite role name for a non-navigable association, however QVT requires such role names to be used. OCL defines an implicit role name, but UML graphics supports arbitrary names. At the EclipseCon OMG symposium in February, it seemed appropriate to resolve the limitation in the following way. An opposite role name may be denoted by a Comment Comment with the inner Comment defining a formal function for the outer Comment. Thus in: "backward" is defined as the oppositeRoleName of "forward". This practice makes the missing information available, and avoids any changes to the MOF meta-model and so avoids introducing any additional Property instances that might bloat existing usage. It would be helpful if a future MOF version, or an addendum to existing versions, endorse this practice. An equivalent Ecore EAnnotation and cross-conversion was introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede). Resolution: The use of ânon-navigableâ is out-dated: the issue is where Property::opposite is empty and there is nothing to hang the name on. This would seem better addressed by the use of a MOF Tag rather than two nested Comments. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 tel: +1 949 330 7677, cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp From: "Uhl, Axel" To: Jim Amsden , "'mof2core-rtf@omg.org'" Date: Fri, 30 Apr 2010 09:59:44 +0200 Subject: RE: Discussion on MOF2 Core Issue 12800 Thread-Topic: Discussion on MOF2 Core Issue 12800 Thread-Index: AcroCmVX4ivDvqbjRWa/qvz+6TZPmAALRbYQ Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {611B4D61-5507-4EE8-8F46-041D0A04733F} x-cr-hashedpuzzle: BXPd Dxcw FFBJ Fdnb GENY Gi8p Hgq9 KRob K1H9 Na6Y PUM0 Ph7v RjGZ Un9Q Vhem V3Aq;2;agBhAG0AcwBkAGUAbgBAAHUAcwAuAGkAYgBtAC4AYwBvAG0AOwBtAG8AZgAyAGMAbwByAGUALQByAHQAZgBAAG8AbQBnAC4AbwByAGcA;Sosha1_v1;7;{611B4D61-5507-4EE8-8F46-041D0A04733F};YQB4AGUAbAAuAHUAaABsAEAAcwBhAHAALgBjAG8AbQA=;Fri, 30 Apr 2010 07:59:44 GMT;UgBFADoAIABEAGkAcwBjAHUAcwBzAGkAbwBuACAAbwBuACAATQBPAEYAMgAgAEMAbwByAGUAIABJAHMAcwB1AGUAIAAxADIAOAAwADAA acceptlanguage: en-US Hi Jim, nobody doubts that a useful class of apps can be built without the tag proposed. Nobody doubts either that there are other ways to solve the problem. Neither seems to exist doubt among many of us that there are serious use cases for OCL-specified expressions that want to express something about a property that doesn't have an opposite, and in some of these cases the expression can compute only the referenced element e1 and then needs to make a statement about those elements referencing e1 using a certain property. Now you may argue that you can always write A.allInstances()->select(a | a.p = e1) to get a hold of all elements of type A or A's subtypes that reference e1 through property p. And yes, it is certainly possible for an OCL infrastructure to recognize such constructs and---given some querying infrastructure---provide performance-improved ways to evaluate such expressions. What we're discussing here is a convenience that would allow us to write an OCL expression e1.r instead, where "r" is the name provided in the tag under discussion on property p which then would lead to the creation of an OCL AST element of the class OppositePropertyCallExp requested by issue 15175 (http://www.omg.org/issues/issue15175.txt) where the OppositePropertyCallExp references the property p. This approach according to a PoC we have implemented at SAP significantly simplifies the OCL environment's job and allows OCL writers to use the very intuitive unchanged concrete syntax for navigation expressions. It simplifies the OCL evaluation environment's life because it doesn't have to do deep inspection and transformation of the OCL AST to recognize and efficiently execute an allInstances()->select(...) construct where the select's body compares exactly one property. In the sequel, with an OppositePropertyCallExp it becomes much simpler to trace back a change of the p property to the contexts on which the using OCL expression may have changed its value. This is much harder to accomplish for the allInstances()->select(...) approach. The tag proposed is already the light-weight and therefore EM(O)F spirit-compliant alternative to introducing a more heavyweight construct which we also PoC-ed, namely the possibility to let a Property (EReference) own its opposite Property (EReference). While this also works, it raises issues regarding enforcing the opposite property's multiplicity constraints and is more of a backward compatibility issue because it breaks code that so far assumes that an EM(O)F Property / EReference is always owned by a(n) (E)Class. The only simplication that a Property-owned opposite would have facilitated would have been that the OCL abstract syntax / metamodel would not need to change because the existing PropertyCallExp could have been used to refer to the property-owned opposite. But in addition to the difficult multiplicity enforcement, Ed Merks already commented that it would shift the cost away from where the benefit is (from OCL to EMOF/Ecore). Your comment regarding the use of CMOF does not seem pragmatic to me. We're trying to make good use of EMF as an almost compliant EMOF implementation. We can live with many of its limitations. The lack of true associations can be circumvented by introducing what EMF needs anyhow, namely good query infrastructure (see also the query2 EMF contribution SAP made which is in incubation status right now). OCL works great on EMF. The last significant stumbling block is this major inconvenience when it comes to OCL-constraining EM(O)F models. If getting this resolved in a standard way only takes the agreement on a tag, I have a hard time understanding the objections. The CMOF alternative would mean we can't use EMF which means we'd have to write or buy a completely different model management infrastructure which means we can't use a lot of the existing Eclipse tool sets around EMF which also means that contributions that SAP due to a finally relaxed open source policy will be making in the future would not be to the benefit of the community. Besides, beyond associations which certainly are the greatest benefit of CMOF over EMOF, CMOF introduces many things that we don't feel we need for our tasks. Best, -- Axel From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, April 30, 2010 4:11 AM To: 'mof2core-rtf@omg.org' Subject: Re: Discussion on MOF2 Core Issue 12800 I do object to this. EMF has been built on EMOF concepts for years. We have developed a large number of transforms that have not needed this extra property. If associations are needed by a tool, then it should use CMOF, not EMOF. If a modeler needs something like an association in EMOF/EMF, then they can use the mediator pattern reasonably effectively. I also do not believe EMOF should specify or require any tags to support structural modeling. Tags were for extensibility, not fundamental metamodel concepts. Such an addition would need to have compelling use cases that cannot be addressed by other means. The concept of association was explicitly kept out of EMOF. I do not believe we should graft something back in using tags to simulate association ends. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: "'pete.rivett@adaptive.com'" , "'mof2core-rtf@omg.org'" , Jim Amsden/Raleigh/IBM@IBMUS Cc: "'ed@willink.me.uk'" Date: 04/29/2010 06:21 PM Subject: Re: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Pete, thanks for kicking this off. At some other place Ed already proposed "Property.oppositeRoleName" as tag name which seemed to make sense to me. Jim, do you still have general objections to introducing such a standard tag? If so, look at OCL issue 15175 where with a naming tag for the non-existing opposite we can save a concrete syntax extension for OCL and make navigation in these directions more intuitive. Best, -- Axel ------------------ Sent from BB -------------------------------------------------------------------------------- From: Pete Rivett To: mof2core-rtf@omg.org ; Jim Amsden Cc: Ed Willink ; Uhl, Axel Sent: Thu Apr 29 23:32:25 2010 Subject: Discussion on MOF2 Core Issue 12800 Below is the issue and my original response: I removed it from the ballot since Jim had raised a comment and I realized the proposal was not complete (e.g. did not define the name of the Tag) so it needed discussion. This email is intended to start such a discussion. I.m going on vacation for a week so hopefully you.ll all have it sorted by the time I get back J BTW Ed, EMOF (as well as CMOF) does include Tags . see Figure 12.1 in formal/06-06-01 where you can see that EMOF merges in the Extension package which defines Tag. Jim wrote: EMOF does not have associations. Rather it uses a notation option for properties that have non-primitive types that uses CMOF association notation. So there are no member or owned ends of the association. Rather QVT should treat these as properties which not non-navigable associations, and there would be no need to a name for the un-named end. Issue 12800: Capturing Unnavigable Opposite Property Role Names (mof2core-rtf) Click here for this issue's archive. Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@willink.me.uk) Nature: Uncategorized Issue Severity: Summary: EMOF does not support identification of the opposite role name for a non-navigable association, however QVT requires such role names to be used. OCL defines an implicit role name, but UML graphics supports arbitrary names. At the EclipseCon OMG symposium in February, it seemed appropriate to resolve the limitation in the following way. An opposite role name may be denoted by a Comment Comment with the inner Comment defining a formal function for the outer Comment. Thus in: "backward" is defined as the oppositeRoleName of "forward". This practice makes the missing information available, and avoids any changes to the MOF meta-model and so avoids introducing any additional Property instances that might bloat existing usage. It would be helpful if a future MOF version, or an addendum to existing versions, endorse this practice. An equivalent Ecore EAnnotation and cross-conversion was introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede). Resolution: The use of .non-navigable. is out-dated: the issue is where Property::opposite is empty and there is nothing to hang the name on. This would seem better addressed by the use of a MOF Tag rather than two nested Comments. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 tel: +1 949 330 7677, cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp From: "Uhl, Axel" To: Jim Amsden , "'mof2core-rtf@omg.org'" Date: Fri, 30 Apr 2010 10:03:57 +0200 Subject: RE: Discussion on MOF2 Core Issue 12800 Thread-Topic: Discussion on MOF2 Core Issue 12800 Thread-Index: AcroCmVX4ivDvqbjRWa/qvz+6TZPmAAMOimg Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US What I forgot to mention: in case you argue that we could just use opposites in EM(O)F to solve the OCL problem, our answer is "no we can't." Opposites that are owned by the (E)Class at the other end always impact that other class's contract, storage and XMI serialization. When you think about model modularization / componentization, this quickly becomes a severe problem as you can't put elements that reference each other into separate components because it would lead to cyclic component dependencies. Therefore, bidirectional storage is often impossible, yet, OCL navigability required. Best, -- Axel From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, April 30, 2010 4:11 AM To: 'mof2core-rtf@omg.org' Subject: Re: Discussion on MOF2 Core Issue 12800 I do object to this. EMF has been built on EMOF concepts for years. We have developed a large number of transforms that have not needed this extra property. If associations are needed by a tool, then it should use CMOF, not EMOF. If a modeler needs something like an association in EMOF/EMF, then they can use the mediator pattern reasonably effectively. I also do not believe EMOF should specify or require any tags to support structural modeling. Tags were for extensibility, not fundamental metamodel concepts. Such an addition would need to have compelling use cases that cannot be addressed by other means. The concept of association was explicitly kept out of EMOF. I do not believe we should graft something back in using tags to simulate association ends. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: "'pete.rivett@adaptive.com'" , "'mof2core-rtf@omg.org'" , Jim Amsden/Raleigh/IBM@IBMUS Cc: "'ed@willink.me.uk'" Date: 04/29/2010 06:21 PM Subject: Re: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Pete, thanks for kicking this off. At some other place Ed already proposed "Property.oppositeRoleName" as tag name which seemed to make sense to me. Jim, do you still have general objections to introducing such a standard tag? If so, look at OCL issue 15175 where with a naming tag for the non-existing opposite we can save a concrete syntax extension for OCL and make navigation in these directions more intuitive. Best, -- Axel ------------------ Sent from BB -------------------------------------------------------------------------------- From: Pete Rivett To: mof2core-rtf@omg.org ; Jim Amsden Cc: Ed Willink ; Uhl, Axel Sent: Thu Apr 29 23:32:25 2010 Subject: Discussion on MOF2 Core Issue 12800 Below is the issue and my original response: I removed it from the ballot since Jim had raised a comment and I realized the proposal was not complete (e.g. did not define the name of the Tag) so it needed discussion. This email is intended to start such a discussion. I.m going on vacation for a week so hopefully you.ll all have it sorted by the time I get back J BTW Ed, EMOF (as well as CMOF) does include Tags . see Figure 12.1 in formal/06-06-01 where you can seee that EMOF merges in the Extension package which defines Tag. Jim wrote: EMOF does not have associations. Rather it uses a notation option for properties that have non-primitive types that uses CMOF association notation. So there are no member or owned ends of the association. Rather QVT should treat these as properties which not non-navigable associations, and there would be no need to a name for the un-named end. Issue 12800: Capturing Unnavigable Opposite Property Role Names (mof2core-rtf) Click here for this issue's archive. Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@willink.me.uk) Nature: Uncategorized Issue Severity: Summary: EMOF does not support identification of the opposite role name for a non-navigable association, however QVT requires such role names to be used. OCL defines an implicit role name, but UML graphics supports arbitrary names. At the EclipseCon OMG symposium in February, it seemed appropriate to resolve the limitation in the following way. An opposite role name may be denoted by a Comment Comment with the inner Comment defining a formal function for the outer Comment. Thus in: "backward" is defined as the oppositeRoleName of "forward". This practice makes the missing information available, and avoids any changes to the MOF meta-model and so avoids introducing any additional Property instances that might bloat existing usage. It would be helpful if a future MOF version, or an addendum to existing versions, endorse this practice. An equivalent Ecore EAnnotation and cross-conversion was introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede). Resolution: The use of .non-navigable. is out-dated: the issue is where Property::opposite is empty and there is nothing to hang the name on. This would seem better addressed by the use of a MOF Tag rather than two nested Comments. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 tel: +1 949 330 7677, cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANdQ2ktUXebi/2dsb2JhbACcP19xvTyFEgQ Date: Fri, 30 Apr 2010 11:40:57 +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: Pete Rivett CC: mof2core-rtf@omg.org, Jim Amsden , "Uhl, Axel" Subject: Re: Discussion on MOF2 Core Issue 12800 X-Plusnet-Relay: 4e881aaafc19044883a1915d935962e4 Hi BTW Ed, EMOF (as well as CMOF) does include Tags . see Figure 12.1 in formal/06-06-01 where you can see that EMOF merges in the Extension package which defines Tag. Ok. Tag is much better than Commented Comments. I was confused by the lack of a Fig 12.x counterpart to Fig 14.3 and, never having used them, the lack of an 'ownedTags' property. Independent orphan Tags are not very modular, but perhaps appropriate. org.omg.emof.oppositePropertyName is better than my suggestion of http://schema.omg.org/spec/MOF/2.0/emof.xml#Property.oppositeRoleName The intent of the proposal is to enable "a.b" to work for in OCL when b is a property role name that is lost when the meta-model is represented as EMOF. The problem, philosophically, is not in EMOF, but in OCL's (and QVT's) 'compile-time' use of a 'run-time' serialisation. Hence the request to endorse an 'annotation' policy to provide the information without needing to change EMOF at all. An even broader question: when mapping from a CMOF metamodel, such as UML, to EMOF, is it a good idea to assume that each Association maps directly to one, or a linked pair of, Properties? Ah, no! This is beyond my knowledge, but it makes good sense. If there is a three-way association between A, B and C with roles myA, myB and myC of which only myB is navigable, then anA.myB and aC.myB work regardless, since A::myB and C::myB are in an EMOF representation. If the obvious navigation opposites are provided: - B::myA is tagged as the org.omg.emof.oppositePropertyName of A::myB - B::myC is tagged as the org.omg.emof.oppositePropertyName of C::myB then aB.myA and aB.myC can work, but aC.myA and anA.myC are problematic. If instead - B::myA is tagged as the org.omg.emof.oppositePropertyName of both A::myB and C::myB - B::myC is tagged as the org.omg.emof.oppositePropertyName of both A::myB and C::myB this identifies the 3-way association with the three role names myA, myB and myC, allowing the existence of A::myC and C::myA to be inferred. aC.myA and anA.myC now work as well. When OCL persists this resolution in its AST, the OppositePropertyCallExp under discussion for Issue 15175 must reference a property owned by the navigation target that is part of the relevant association. Thus for aC.myA the OppositePropertyCallExp should reference A::myB so that the A:: identifies the target and the A::myB identifies the association of which C is also part via C::myB. The OCL AST element and the tagged EMOF meta-model provide the requisite control for an OCL evaluation. I hope my understanding is correct; thinking about this perhaps unlikely case seems to give a clearer association-based view of the necessary inferences. Another question: is an unqualified name sufficient? I.m assuming it is for OCL/QVT purposes but are there other potential uses? Yes/No, yes, yes (any analysis tool). The tag in EMOF is identifying the missing role name. The exact classes are provided by the opposite property's owner and target. When used in an OCL expression, a qualification may be needed as in "aDerivedA.A::myB", but this is an OCL concrete syntax to resolve ambiguities between multiple names in the same scope. But: 'is a name sufficient'? No. For an expression such as "a.b" OCL needs to know not only that "b" exists, but also what its type is. The element type is defined by the owner of the opposite. The multiplicity, ordering and unqueness is not. So org.omg.emof.oppositeLower org.omg.emof.oppositeUpper org.omg.emof.oppositeIsOrdered org.omg.emof.oppositeIsUnique (so perhaps org.omg.emof.oppositeName rather than org.omg.emof.oppositePropertyName) may also be needed (with sensible defaults) unless a better understanding of UML than mine can show that any are redundant. I suspect that oppositeIsUnique may be redundant. In the 3-way example above, defining these for B::myA and B::myC is sufficient, since the inferred A::myC and C::myA are fully defined by B::myC and B::myA. An alternative and more faithful (to the semantics) mapping would be to introduce an EMOF class for each CMOF Association with the same name as the association (yes, each association in the UML metamodel does have an explicit name in the normative XMI file for the metamodel). Introduction of Associations to EMOF seems to totally undermine its 'Essential' philosophy and will make the serialisation significantly larger and backwards surprising. As indicated above, the association is inferable from the tags. (Perhaps the association name could also be provided by an org.omg.emof.associationName tag on any one of the properties.) Regards Ed Willink X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAPd72kvUnw4U/2dsb2JhbACBPpsCYHG+JYJYgjoE Date: Fri, 30 Apr 2010 14:48:05 +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: "Uhl, Axel" CC: Pete Rivett , "mof2core-rtf@omg.org" , Jim Amsden Subject: Re: Discussion on MOF2 Core Issue 12800 X-Plusnet-Relay: 78db61198bd39485cb339d5c2f851793 Hi Axel If something can be specified in UML and apparently be represented in EMOF, I feel that the resulting behaviour should not differ from a UML representation. So OCL treating all tagged opposites as Bag(T) could lead to surprises, particularly when 0..1 is a common use case. Bag could be the default from which deviation needs the extra tags. It could be an obligation of an EMOF producing tool to warn when Bag(T) is incompatible with the UML. Better for the UML truth to appear in the tags, and for the EMOF consuming tool to warn if it is unable to realise the requirement. (The producing tool could also warn of the unwise requirement.) I'm not convinced that difficulties in representing n-ary associations in EMF are applicable. I don't doubt that an association-less representation is difficult, so I would expect an implementation to realise the need for an association object to linearise the exponential association end complexity. Provision of this object would be a hidden implementation detail. My observation that multi-tagging effectively defines associations could be taken a step further. But if CMOF only supports binary associations, further consideration of n-ary seems a distraction. Regards Ed Willink On 30/04/2010 13:07, Uhl, Axel wrote: Hi, a qualification IMHO is not necessary, by the same rationale that a regular property's name does not have to be qualified. It may well be, as Ed indicates, that the usage, e.g., in OCL, may need to be qualified to unambiguously identify which property to link the OppositePropertyCallExp to. Do we need to consider a mapping of n-ary associations to EMOF/EMF with n>2? I saw there was some discussion about an issue that asked for n>2 assocs in CMOF, but will that request succeed? Mapping an n-ary (n>2) association to EMOF will be even harder than it is for n=2 because with opposite's upper bound being 1 there is no good way of representing the n>2 case in EMOF, I think. Regarding the other multiplicity characteristics (ordered, unique, bounds), that was a discussion we had with Ed Merks. He suggested that particularly ordering for the reverse direction can't reasonably established and maintained given that usually the property owner stores the relationship, and there is no good way of storing the reverse direction's ordering. Similarly, there is no good way of checking and therefore enforcing the lower and upper multiplicity bounds, and neither can uniqueness be checked without performing a query and without knowing what the scope for that query would be. There seems to be little use in describing those characteristics in a metamodel if they can't be enforced or are scope-specific. Having said that, nothing but the name remains. OCL has to assume that an OppositePropertyCallExp, used in an EMOF environment, returns a Bag(T), so no ordering, no uniqueness, 0..* bounds. With this I argue that an unqualified name is sufficient. To Pete's suggestion to introduce a EMOF class for each CMOF association: If I understand this correctly, this would at least not solve the original problem, namely that of OCL navigation across non-existing properties because again the class representing the association would have two properties without opposites (if opposites could be used in all cases, we could just as well skip the in-between class and use two properties that are each other's opposite, but the componentization problems with that I tried to point out in my previous e-mail). Therefore, http://ed-merks.blogspot.com/2008/01/modeling-associations-with-ecore.html doesn't solve the componentization problem either because it requires references in both adjacent classes. Besides, adding the class in the middle would require two navigation expressions in OCL to navigate across the link class instance. This, IMO, would complicate matters too much, specifically compared to the rather lean approach using the tag. Best, -- Axel From: Ed Willink [mailto:ed@willink.me.uk] Sent: Friday, April 30, 2010 12:41 PM To: Pete Rivett Cc: mof2core-rtf@omg.org; Jim Amsden; Uhl, Axel Subject: Re: Discussion on MOF2 Core Issue 12800 Hi BTW Ed, EMOF (as well as CMOF) does include Tags . see Figure 12.1 in formal/06-06-01 where you can see that EMOF merges in the Extension package which defines Tag. Ok. Tag is much better than Commented Comments. I was confused by the lack of a Fig 12.x counterpart to Fig 14.3 and, never having used them, the lack of an 'ownedTags' property. Independent orphan Tags are not very modular, but perhaps appropriate. org.omg.emof.oppositePropertyName is better than my suggestion of http://schema.omg.org/spec/MOF/2.0/emof.xml#Property.oppositeRoleName The intent of the proposal is to enable "a.b" to work for in OCL when b is a property role name that is lost when the meta-model is represented as EMOF. The problem, philosophically, is not in EMOF, but in OCL's (and QVT's) 'compile-time' use of a 'run-time' serialisation. Hence the request to endorse an 'annotation' policy to provide the information without needing to change EMOF at all. An even broader question: when mapping from a CMOF metamodel, such as UML, to EMOF, is it a good idea to assume that each Association maps directly to one, or a linked pair of, Properties? Ah, no! This is beyond my knowledge, but it makes good sense. If there is a three-way association between A, B and C with roles myA, myB and myC of which only myB is navigable, then anA.myB and aC.myB work regardless, since A::myB and C::myB are in an EMOF representation. If the obvious navigation opposites are provided: - B::myA is tagged as the org.omg.emof.oppositePropertyName of A::myB - B::myC is tagged as the org.omg.emof.oppositePropertyName of C::myB then aB.myA and aB.myC can work, but aC.myA and anA.myC are problematic. If instead - B::myA is tagged as the org.omg.emof.oppositePropertyName of both A::myB and C::myB - B::myC is tagged as the org.omg.emof.oppositePropertyName of both A::myB and C::myB this identifies the 3-way association with the three role names myA, myB and myC, allowing the existence of A::myC and C::myA to be inferred. aC.myA and anA.myC now work as well. When OCL persists this resolution in its AST, the OppositePropertyCallExp under discussion for Issue 15175 must reference a property owned by the navigation target that is part of the relevant association. Thus for aC.myA the OppositePropertyCallExp should reference A::myB so that the A:: identifies the target and the A::myB identifies the association of which C is also part via C::myB. The OCL AST element and the tagged EMOF meta-model provide the requisite control for an OCL evaluation. I hope my understanding is correct; thinking about this perhaps unlikely case seems to give a clearer association-based view of the necessary inferences. Another question: is an unqualified name sufficient? I.m assuming it is for OCL/QVT purposes but are there other potential uses? Yes/No, yes, yes (any analysis tool). The tag in EMOF is identifying the missing role name. The exact classes are provided by the opposite property's owner and target. When used in an OCL expression, a qualification may be needed as in "aDerivedA.A::myB", but this is an OCL concrete syntax to resolve ambiguities between multiple names in the same scope. But: 'is a name sufficient'? No. For an expression such as "a.b" OCL needs to know not only that "b" exists, but also what its type is. The element type is defined by the owner of the opposite. The multiplicity, ordering and unqueness is not. So org.omg.emof.oppositeLower org.omg.emof.oppositeUpper org.omg.emof.oppositeIsOrdered org.omg.emof.oppositeIsUnique (so perhaps org.omg.emof.oppositeName rather than org.omg.emof.oppositePropertyName) may also be needed (with sensible defaults) unless a better understanding of UML than mine can show that any are redundant. I suspect that oppositeIsUnique may be redundant. In the 3-way example above, defining these for B::myA and B::myC is sufficient, since the inferred A::myC and C::myA are fully defined by B::myC and B::myA. An alternative and more faithful (to the semantics) mapping would be to introduce an EMOF class for each CMOF Association with the same name as the association (yes, each association in the UML metamodel does have an explicit name in the normative XMI file for the metamodel). Introduction of Associations to EMOF seems to totally undermine its 'Essential' philosophy and will make the serialisation significantly larger and backwards surprising. As indicated above, the association is inferable from the tags. (Perhaps the association name could also be provided by an org.omg.emof.associationName tag on any one of the properties.) Regards Ed Willink No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.814 / Virus Database: 271.1.1/2843 - Release Date: 04/29/10 19:27:00 To: "'mof2core-rtf@omg.org'" Cc: ed.merks@gmail.com, kenn.hussey@gmail.com Subject: RE: Discussion on MOF2 Core Issue 12800 X-KeepSent: 9394E5C4:C42023C5-85257715:004B99A3; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 From: Jim Amsden Date: Fri, 30 Apr 2010 10:08:05 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 04/30/2010 08:08:04, Serialize complete at 04/30/2010 08:08:04 Axel, I understand these arguments. However, EMOF (and EMF) were specifically designed to enable efficient specification and implementation of navigability. The design was not intended to use navigability to indicate "efficient access is desired in this direction" while also allowing some sort of less efficient access in the non-navigable direction. Rather navigability was intended to indicate what information is available from what context in order to model intended semantics and manage coupling. OCL does not follow these conventions, allowing one to ignore navigability (other then perhaps for efficiency purposes). This is inconsistent with the functional and non-functional objectives that drove the definition of EMOF. Now one could suggest those design goals were misguided, or have become out of date due to change in navigability in UML (which did not effect Basic), or changing requirements. If the issue is changing requirements EMOF, then I would think the EMF community would be driving this, so I would defer to that community for further comment. Ed? Kenn? Others? On the use of tags for the new property - this could have significant effect on EMOF and EMF. The effect on EMOF is that now tags are introduced into the EMOF structure model to provide "convenience" for some OCL operations. EMOF doen't include OCL, so that seems somewhat artificial. Additional semantics have to be added to EMOF to specify how this tag value is set when properties and opposites change, and how it is reflected. OCL would have to be extended to understand the special case where aClass.aProperty was referring to a tag rather than an actual property. Now any updates to properties and opposites would have to make the appropriate updates to the tag value in EMF. This could raise the very issues leaving associations out of EMF was intended to avoid. Again, I defer to the EMF experts. So how do we move forward: 1. We understand exactly the use cases driving this change - not in email exchanges but on a Wiki where they can be adequately captured, contributed to and reviewed 2. We explore options for supporting the use cases including making EMOF "associations" navigable in both directions (through property opposite) in cases where this is needed in the model, using the mediator pattern for cases were property opposite is not adequate, using convenience tags (that might be optional), merging CMOF associations to EMOF, etc. 3. We pick one or two of the explored options and write them up so they can be properly communicated, understood, reviewed, and evaluated. Any change to EMOF should get significant scrutiny since it results in changes to EMF which effects a lot of existing products. 4. Decide on an approach and include it in a ballot, assuming the approach is applicable to an RTF. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: Jim Amsden/Raleigh/IBM@IBMUS, "'mof2core-rtf@omg.org'" Date: 04/30/2010 04:00 AM Subject: RE: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Hi Jim, nobody doubts that a useful class of apps can be built without the tag proposed. Nobody doubts either that there are other ways to solve the problem. Neither seems to exist doubt among many of us that there are serious use cases for OCL-specified expressions that want to express something about a property that doesn't have an opposite, and in some of these cases the expression can compute only the referenced element e1 and then needs to make a statement about those elements referencing e1 using a certain property. Now you may argue that you can always write A.allInstances()->select(a | a.p = e1) to get a hold of all elements of type A or A's subtypes that reference e1 through property p. And yes, it is certainly possible for an OCL infrastructure to recognize such constructs and---given some querying infrastructure---provide performance-improved ways to evaluate such expressions. What we're discussing here is a convenience that would allow us to write an OCL expression e1.r instead, where "r" is the name provided in the tag under discussion on property p which then would lead to the creation of an OCL AST element of the class OppositePropertyCallExp requested by issue 15175 (http://www.omg.org/issues/issue15175.txt) where the OppositePropertyCallExp references the property p. This approach according to a PoC we have implemented at SAP significantly simplifies the OCL environment's job and allows OCL writers to use the very intuitive unchanged concrete syntax for navigation expressions. It simplifies the OCL evaluation environment's life because it doesn't have to do deep inspection and transformation of the OCL AST to recognize and efficiently execute an allInstances()->select(...) construct where the select's body compares exactly one property. In the sequel, with an OppositePropertyCallExp it becomes much simpler to trace back a change of the p property to the contexts on which the using OCL expression may have changed its value. This is much harder to accomplish for the allInstances()->select(...) approach. The tag proposed is already the light-weight and therefore EM(O)F spirit-compliant alternative to introducing a more heavyweight construct which we also PoC-ed, namely the possibility to let a Property (EReference) own its opposite Property (EReference). While this also works, it raises issues regarding enforcing the opposite property's multiplicity constraints and is more of a backward compatibility issue because it breaks code that so far assumes that an EM(O)F Property / EReference is always owned by a(n) (E)Class. The only simplication that a Property-owned opposite would have facilitated would have been that the OCL abstract syntax / metamodel would not need to change because the existing PropertyCallExp could have been used to refer to the property-owned opposite. But in addition to the difficult multiplicity enforcement, Ed Merks already commented that it would shift the cost away from where the benefit is (from OCL to EMOF/Ecore). Your comment regarding the use of CMOF does not seem pragmatic to me. We're trying to make good use of EMF as an almost compliant EMOF implementation. We can live with many of its limitations. The lack of true associations can be circumvented by introducing what EMF needs anyhow, namely good query infrastructure (see also the query2 EMF contribution SAP made which is in incubation status right now). OCL works great on EMF. The last significant stumbling block is this major inconvenience when it comes to OCL-constraining EM(O)F models. If getting this resolved in a standard way only takes the agreement on a tag, I have a hard time understanding the objections. The CMOF alternative would mean we can't use EMF which means we'd have to write or buy a completely different model management infrastructure which means we can't use a lot of the existing Eclipse tool sets around EMF which also means that contributions that SAP due to a finally relaxed open source policy will be making in the future would not be to the benefit of the community. Besides, beyond associations which certainly are the greatest benefit of CMOF over EMOF, CMOF introduces many things that we don't feel we need for our tasks. Best, -- Axel From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, April 30, 2010 4:11 AM To: 'mof2core-rtf@omg.org' Subject: Re: Discussion on MOF2 Core Issue 12800 I do object to this. EMF has been built on EMOF concepts for years. We have developed a large number of transforms that have not needed this extra property. If associations are needed by a tool, then it should use CMOF, not EMOF. If a modeler needs something like an association in EMOF/EMF, then they can use the mediator pattern reasonably effectively. I also do not believe EMOF should specify or require any tags to support structural modeling. Tags were for extensibility, not fundamental metamodel concepts. Such an addition would need to have compelling use cases that cannot be addressed by other means. The concept of association was explicitly kept out of EMOF. I do not believe we should graft something back in using tags to simulate association ends. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: "'pete.rivett@adaptive.com'" , "'mof2core-rtf@omg.org'" , Jim Amsden/Raleigh/IBM@IBMUS Cc: "'ed@willink.me.uk'" Date: 04/29/2010 06:21 PM Subject: Re: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Pete, thanks for kicking this off. At some other place Ed already proposed "Property.oppositeRoleName" as tag name which seemed to make sense to me. Jim, do you still have general objections to introducing such a standard tag? If so, look at OCL issue 15175 where with a naming tag for the non-existing opposite we can save a concrete syntax extension for OCL and make navigation in these directions more intuitive. Best, -- Axel ------------------ Sent from BB -------------------------------------------------------------------------------- From: Pete Rivett To: mof2core-rtf@omg.org ; Jim Amsden Cc: Ed Willink ; Uhl, Axel Sent: Thu Apr 29 23:32:25 2010 Subject: Discussion on MOF2 Core Issue 12800 Below is the issue and my original response: I removed it from the ballot since Jim had raised a comment and I realized the proposal was not complete (e.g. did not define the name of the Tag) so it needed discussion. This email is intended to start such a discussion. Iâm going on vacation for a week so hopefully youâll all have it sorted by the time I get back J BTW Ed, EMOF (as well as CMOF) does include Tags . see Figure 12.1 in formal/06-066-01 where you can see that EMOF merges in the Extension package which defines Tag. Jim wrote: EMOF does not have associations. Rather it uses a notation option for properties that have non-primitive types that uses CMOF association notation. So there are no member or owned ends of the association. Rather QVT should treat these as properties which not non-navigable associations, and there would be no need to a name for the un-named end. Issue 12800: Capturing Unnavigable Opposite Property Role Names (mof2core-rtf) Click here for this issue's archive. Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@willink.me.uk) Nature: Uncategorized Issue Severity: Summary: EMOF does not support identification of the opposite role name for a non-navigable association, however QVT requires such role names to be used. OCL defines an implicit role name, but UML graphics supports arbitrary names. At the EclipseCon OMG symposium in February, it seemed appropriate to resolve the limitation in the following way. An opposite role name may be denoted by a Comment Comment with the inner Comment defining a formal function for the outer Comment. Thus in: "backward" is defined as the oppositeRoleName of "forward". This practice makes the missing information available, and avoids any changes to the MOF meta-model and so avoids introducing any additional Property instances that might bloat existing usage. It would be helpful if a future MOF version, or an addendum to existing versions, endorse this practice. An equivalent Ecore EAnnotation and cross-conversion was introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede). Resolution: The use of ânon-navigableâ is out-dated: the issue is where Property::opposite is empty and there is nothing to hang the name on. This would seem better addressed by the use of a MOF Tag rather than two nested Comments. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 tel: +1 949 330 7677, cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp From: "Uhl, Axel" To: Ed Willink CC: Pete Rivett , "mof2core-rtf@omg.org" , Jim Amsden Date: Fri, 30 Apr 2010 16:10:54 +0200 Subject: RE: Discussion on MOF2 Core Issue 12800 Thread-Topic: Discussion on MOF2 Core Issue 12800 Thread-Index: Acroa8cLq7c8PeHkRWG+r1qaLqe9gAAAM4CA Accept-Language: en-US, de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {5D5F7025-4DBA-4A19-8941-40FFCAFEF33E} x-cr-hashedpuzzle: Ceyy EfBH ID5j SyZJ ThYe U7Vw VRee WqQT YfdJ hVpB k9c7 l3Ok nJxG o7ql pG7l sdKB;4;ZQBkAEAAdwBpAGwAbABpAG4AawAuAG0AZQAuAHUAawA7AGoAYQBtAHMAZABlAG4AQAB1AHMALgBpAGIAbQAuAGMAbwBtADsAbQBvAGYAMgBjAG8AcgBlAC0AcgB0AGYAQABvAG0AZwAuAG8AcgBnADsAcABlAHQAZQAuAHIAaQB2AGUAdAB0AEAAYQBkAGEAcAB0AGkAdgBlAC4AYwBvAG0A;Sosha1_v1;7;{5D5F7025-4DBA-4A19-8941-40FFCAFEF33E};YQB4AGUAbAAuAHUAaABsAEAAcwBhAHAALgBjAG8AbQA=;Fri, 30 Apr 2010 14:10:54 GMT;UgBFADoAIABEAGkAcwBjAHUAcwBzAGkAbwBuACAAbwBuACAATQBPAEYAMgAgAEMAbwByAGUAIABJAHMAcwB1AGUAIAAxADIAOAAwADAA acceptlanguage: en-US, de-DE Hi Ed, If something can be specified in UML and apparently be represented in EMOF, I feel that the resulting behaviour should not differ from a UML representation. So OCL treating all tagged opposites as Bag(T) could lead to surprises, particularly when 0..1 is a common use case. Bag could be the default from which deviation needs the extra tags. while I clearly see your point and would appreciate the convenience for the OCL writer, as Ed Merks said you cannot enforce the 0..1 multiplicity. Imagine this: class A { B b; // this is tagged with oppositeRoleName="a" with multiplicity 0..1 } Imagine we have elements a1 and a2 of type A, and b1 of type B. If I write a1.setB(b1); a2.setB(b1); what would the resulting model look like? What would I get if with context b1 I evaluated self.a in OCL? Would I get Bag{a1, a2}, or would I only get a2 or only a1? Would the "a2.setB(b1)" raise an exception? If I only got a2, what would a1.getB() return? It could be an obligation of an EMOF producing tool to warn when Bag(T) is incompatible with the UML. Better for the UML truth to appear in the tags, and for the EMOF consuming tool to warn if it is unable to realise the requirement. (The producing tool could also warn of the unwise requirement.) Not sure I undestand what you mean here. When I use OCL based on a UML model, I would have the opposite including all multiplicity settings, and the OCL parser would turn my self.a from above into a PropertyCallExp referencing the now existing a property instead of an OppositePropertyCallExp referencing the b property. I thought we were only discussing the case where there is no means to represent the opposite property in the metamodel. Best, -- Axel From: Ed Willink [mailto:ed@willink.me.uk] Sent: Friday, April 30, 2010 3:48 PM To: Uhl, Axel Cc: Pete Rivett; mof2core-rtf@omg.org; Jim Amsden Subject: Re: Discussion on MOF2 Core Issue 12800 Hi Axel If something can be specified in UML and apparently be represented in EMOF, I feel that the resulting behaviour should not differ from a UML representation. So OCL treating all tagged opposites as Bag(T) could lead to surprises, particularly when 0..1 is a common use case. Bag could be the default from which deviation needs the extra tags. It could be an obligation of an EMOF producing tool to warn when Bag(T) is incompatible with the UML. Better for the UML truth to appear in the tags, and for the EMOF consuming tool to warn if it is unable to realise the requirement. (The producing tool could also warn of the unwise requirement.) I'm not convinced that difficulties in representing n-ary associations in EMF are applicable. I don't doubt that an association-less representation is difficult, so I would expect an implementation to realise the need for an association object to linearise the exponential association end complexity. Provision of this object would be a hidden implementation detail. My observation that multi-tagging effectively defines associations could be taken a step further. But if CMOF only supports binary associations, further consideration of n-ary seems a distraction. Regards Ed Willink On 30/04/2010 13:07, Uhl, Axel wrote: Hi, a qualification IMHO is not necessary, by the same rationale that a regular property's name does not have to be qualified. It may well be, as Ed indicates, that the usage, e.g., in OCL, may need to be qualified to unambiguously identify which property to link the OppositePropertyCallExp to. Do we need to consider a mapping of n-ary associations to EMOF/EMF with n>2? I saw there was some discussion about an issue that asked for n>2 assocs in CMOF, but will that request succeed? Mapping an n-ary (n>2) association to EMOF will be even harder than it is for n=2 because with opposite's upper bound being 1 there is no good way of representing the n>2 case in EMOF, I think. Regarding the other multiplicity characteristics (ordered, unique, bounds), that was a discussion we had with Ed Merks. He suggested that particularly ordering for the reverse direction can't reasonably established and maintained given that usually the property owner stores the relationship, and there is no good way of storing the reverse direction's ordering. Similarly, there is no good way of checking and therefore enforcing the lower and upper multiplicity bounds, and neither can uniqueness be checked without performing a query and without knowing what the scope for that query would be. There seems to be little use in describing those characteristics in a metamodel if they can't be enforced or are scope-specific. Having said that, nothing but the name remains. OCL has to assume that an OppositePropertyCallExp, used in an EMOF environment, returns a Bag(T), so no ordering, no uniqueness, 0..* bounds. With this I argue that an unqualified name is sufficient. To Pete's suggestion to introduce a EMOF class for each CMOF association: If I understand this correctly, this would at least not solve the original problem, namely that of OCL navigation across non-existing properties because again the class representing the association would have two properties without opposites (if opposites could be used in all cases, we could just as well skip the in-between class and use two properties that are each other's opposite, but the componentization problems with that I tried to point out in my previous e-mail). Therefore, http://ed-merks.blogspot.com/2008/01/modeling-associations-with-ecore.html doesn't solve the componentization problem either because it requires references in both adjacent classes. Besides, adding the class in the middle would require two navigation expressions in OCL to navigate across the link class instance. This, IMO, would complicate matters too much, specifically compared to the rather lean approach using the tag. Best, -- Axel From: Ed Willink [mailto:ed@willink.me.uk] Sent: Friday, April 30, 2010 12:41 PM To: Pete Rivett Cc: mof2core-rtf@omg.org; Jim Amsden; Uhl, Axel Subject: Re: Discussion on MOF2 Core Issue 12800 Hi BTW Ed, EMOF (as well as CMOF) does include Tags . see Figure 12.1 in formal/06-06-01 where you can see that EMOF merges in the Extension package which defines Tag. Ok. Tag is much better than Commented Comments. I was confused by the lack of a Fig 12.x counterpart to Fig 14.3 and, never having used them, the lack of an 'ownedTags' property. Independent orphan Tags are not very modular, but perhaps appropriate. org.omg.emof.oppositePropertyName is better than my suggestion of http://schema.omg.org/spec/MOF/2.0/emof.xml#Property.oppositeRoleName The intent of the proposal is to enable "a.b" to work for in OCL when b is a property role name that is lost when the meta-model is represented as EMOF. The problem, philosophically, is not in EMOF, but in OCL's (and QVT's) 'compile-time' use of a 'run-time' serialisation. Hence the request to endorse an 'annotation' policy to provide the information without needing to change EMOF at all. An even broader question: when mapping from a CMOF metamodel, such as UML, to EMOF, is it a good idea to assume that each Association maps directly to one, or a linked pair of, Properties? Ah, no! This is beyond my knowledge, but it makes good sense. If there is a three-way association between A, B and C with roles myA, myB and myC of which only myB is navigable, then anA.myB and aC.myB work regardless, since A::myB and C::myB are in an EMOF representation. If the obvious navigation opposites are provided: - B::myA is tagged as the org.omg.emof.oppositePropertyName of A::myB - B::myC is tagged as the org.omg.emof.oppositePropertyName of C::myB then aB.myA and aB.myC can work, but aC.myA and anA.myC are problematic. If instead - B::myA is tagged as the org.omg.emof.oppositePropertyName of both A::myB and C::myB - B::myC is tagged as the org.omg.emof.oppositePropertyName of both A::myB and C::myB this identifies the 3-way association with the three role names myA, myB and myC, allowing the existence of A::myC and C::myA to be inferred. aC.myA and anA.myC now work as well. When OCL persists this resolution in its AST, the OppositePropertyCallExp under discussion for Issue 15175 must reference a property owned by the navigation target that is part of the relevant association. Thus for aC.myA the OppositePropertyCallExp should reference A::myB so that the A:: identifies the target and the A::myB identifies the association of which C is also part via C::myB. The OCL AST element and the tagged EMOF meta-model provide the requisite control for an OCL evaluation. I hope my understanding is correct; thinking about this perhaps unlikely case seems to give a clearer association-based view of the necessary inferences. Another question: is an unqualified name sufficient? I.m assuming it is for OCL/QVT purposes but are there other potential uses? Yes/No, yes, yes (any analysis tool). The tag in EMOF is identifying the missing role name. The exact classes are provided by the opposite property's owner and target. When used in an OCL expression, a qualification may be needed as in "aDerivedA.A::myB", but this is an OCL concrete syntax to resolve ambiguities between multiple names in the same scope. But: 'is a name sufficient'? No. For an expression such as "a.b" OCL needs to know not only that "b" exists, but also what its type is. The element type is defined by the owner of the opposite. The multiplicity, ordering and unqueness is not. So org.omg.emof.oppositeLower org.omg.emof.oppositeUpper org.omg.emof.oppositeIsOrdered org.omg.emof.oppositeIsUnique (so perhaps org.omg.emof.oppositeName rather than org.omg.emof.oppositePropertyName) may also be needed (with sensible defaults) unless a better understanding of UML than mine can show that any are redundant. I suspect that oppositeIsUnique may be redundant. In the 3-way example above, defining these for B::myA and B::myC is sufficient, since the inferred A::myC and C::myA are fully defined by B::myC and B::myA. An alternative and more faithful (to the semantics) mapping would be to introduce an EMOF class for each CMOF Association with the same name as the association (yes, each association in the UML metamodel does have an explicit name in the normative XMI file for the metamodel). Introduction of Associations to EMOF seems to totally undermine its 'Essential' philosophy and will make the serialisation significantly larger and backwards surprising. As indicated above, the association is inferable from the tags. (Perhaps the association name could also be provided by an org.omg.emof.associationName tag on any one of the properties.) Regards Ed Willink No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.814 / Virus Database: 271.1.1/2843 - Release Date: 04/29/10 19:27:00 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAJuM2kvUnw4U/2dsb2JhbACBPpsCYHG+fIJYgjoE Date: Fri, 30 Apr 2010 15:56:05 +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: "Uhl, Axel" CC: Pete Rivett , "mof2core-rtf@omg.org" , Jim Amsden Subject: Re: Discussion on MOF2 Core Issue 12800 X-Plusnet-Relay: 2c231a4e0a390db9b62ea12061e11e02 Hi Axel On 30/04/2010 15:10, Uhl, Axel wrote: If something can be specified in UML and apparently be represented in EMOF, I feel that the resulting behaviour should not differ from a UML representation. So OCL treating all tagged opposites as Bag(T) could lead to surprises, particularly when 0..1 is a common use case. Bag could be the default from which deviation needs the extra tags. while I clearly see your point and would appreciate the convenience for the OCL writer, as Ed Merks said you cannot enforce the 0..1 multiplicity. This is an EMF/implementation issue. If the UML diagram specifies 0..1 multiplicity, any model that violates this is not well-formed. At some point, ideally immediately (on the second setB below), an implementation should use an appropriate (Exception) mechanism to alert to the lack of well-formedness. EMF has many such alerts already, e.g the no-null-constraint-is-violated. Perhaps the implementation allows for a transient lack of well-formedness, only checking when a validation is requested. You can enforce a 0..1 multiplicity. EMF does so and UML mandates it for containment. The unexpected migration, rather than sharing, of ambiguously owned list elements is a nasty surprise that EMF programmers encounter before too long. Imagine this: class A { B b; // this is tagged with oppositeRoleName="a" with multiplicity 0..1 } Imagine we have elements a1 and a2 of type A, and b1 of type B. If I write a1.setB(b1); a2.setB(b1); what would the resulting model look like? What would I get if with context b1 I evaluated self.a in OCL? Would I get Bag{a1, a2}, or would I only get a2 or only a1? Would the "a2.setB(b1)" raise an exception? If I only got a2, what would a1.getB() return? How an implementation behaves for a non-well-formed model, is an implementation issue. (Ecore deviates from EMOF equivalence a little by having more 0..1 rather than 1 multiplicities so that the transient status during model construction is valid.) I don't think that UML specifies the dynamics of setB. OCL certainly doesn't because setB has a side-effect. Your questions are all good ones but they do not need answers. It could be an obligation of an EMOF producing tool to warn when Bag(T) is incompatible with the UML. Better for the UML truth to appear in the tags, and for the EMOF consuming tool to warn if it is unable to realise the requirement. (The producing tool could also warn of the unwise requirement.) Not sure I undestand what you mean here. When I use OCL based on a UML model, I would have the opposite including all multiplicity settings, and the OCL parser would turn my self.a from above into a PropertyCallExp referencing the now existing a property instead of an OppositePropertyCallExp referencing the b property. I thought we were only discussing the case where there is no means to represent the opposite property in the metamodel. I mean that: Scenario EMOF: I produce an EMOF representation of my UML class diagrams and execute it in some way. Scenario UML: I produce a UML representation of my UML class diagrams and execute it in some way. If my tools give me no warnings, I do not expect observably different results between the two scenarios. If the results could be different, the tools must warn, and I favour putting the obligation on the consumer rather than producer whenever possible, so that programmers using a really good EMOF producer and consumer are able to model without any spurious warnings. [Whether a PropertyCallExp is allowed to use a non-navigable opposite is a detail for Issue 15175.] My suggestion that the tags provide (unless they default to) the full multiplicities ensures that the direct use of the non-navigable UML property or the inferred EMOF opposite yield the same results. Regards Ed Willink Best, -- Axel From: Ed Willink [mailto:ed@willink.me.uk] Sent: Friday, April 30, 2010 3:48 PM To: Uhl, Axel Cc: Pete Rivett; mof2core-rtf@omg.org; Jim Amsden Subject: Re: Discussion on MOF2 Core Issue 12800 Hi Axel If something can be specified in UML and apparently be represented in EMOF, I feel that the resulting behaviour should not differ from a UML representation. So OCL treating all tagged opposites as Bag(T) could lead to surprises, particularly when 0..1 is a common use case. Bag could be the default from which deviation needs the extra tags. It could be an obligation of an EMOF producing tool to warn when Bag(T) is incompatible with the UML. Better for the UML truth to appear in the tags, and for the EMOF consuming tool to warn if it is unable to realise the requirement. (The producing tool could also warn of the unwise requirement.) I'm not convinced that difficulties in representing n-ary associations in EMF are applicable. I don't doubt that an association-less representation is difficult, so I would expect an implementation to realise the need for an association object to linearise the exponential association end complexity. Provision of this object would be a hidden implementation detail. My observation that multi-tagging effectively defines associations could be taken a step further. But if CMOF only supports binary associations, further consideration of n-ary seems a distraction. Regards Ed Willink On 30/04/2010 13:07, Uhl, Axel wrote: Hi, a qualification IMHO is not necessary, by the same rationale that a regular property's name does not have to be qualified. It may well be, as Ed indicates, that the usage, e.g., in OCL, may need to be qualified to unambiguously identify which property to link the OppositePropertyCallExp to. Do we need to consider a mapping of n-ary associations to EMOF/EMF with n>2? I saw there was some discussion about an issue that asked for n>2 assocs in CMOF, but will that request succeed? Mapping an n-ary (n>2) association to EMOF will be even harder than it is for n=2 because with opposite's upper bound being 1 there is no good way of representing the n>2 case in EMOF, I think. Regarding the other multiplicity characteristics (ordered, unique, bounds), that was a discussion we had with Ed Merks. He suggested that particularly ordering for the reverse direction can't reasonably established and maintained given that usually the property owner stores the relationship, and there is no good way of storing the reverse direction's ordering. Similarly, there is no good way of checking and therefore enforcing the lower and upper multiplicity bounds, and neither can uniqueness be checked without performing a query and without knowing what the scope for that query would be. There seems to be little use in describing those characteristics in a metamodel if they can't be enforced or are scope-specific. Having said that, nothing but the name remains. OCL has to assume that an OppositePropertyCallExp, used in an EMOF environment, returns a Bag(T), so no ordering, no uniqueness, 0..* bounds. With this I argue that an unqualified name is sufficient. To Pete's suggestion to introduce a EMOF class for each CMOF association: If I understand this correctly, this would at least not solve the original problem, namely that of OCL navigation across non-existing properties because again the class representing the association would have two properties without opposites (if opposites could be used in all cases, we could just as well skip the in-between class and use two properties that are each other's opposite, but the componentization problems with that I tried to point out in my previous e-mail). Therefore, http://ed-merks.blogspot.com/2008/01/modeling-associations-with-ecore.html doesn't solve the componentization problem either because it requires references in both adjacent classes. Besides, adding the class in the middle would require two navigation expressions in OCL to navigate across the link class instance. This, IMO, would complicate matters too much, specifically compared to the rather lean approach using the tag. Best, -- Axel From: Ed Willink [mailto:ed@willink.me.uk] Sent: Friday, April 30, 2010 12:41 PM To: Pete Rivett Cc: mof2core-rtf@omg.org; Jim Amsden; Uhl, Axel Subject: Re: Discussion on MOF2 Core Issue 12800 Hi BTW Ed, EMOF (as well as CMOF) does include Tags . see Figure 12.1 in formal/06-06-01 where you can see that EMOF merges in the Extension package which defines Tag. Ok. Tag is much better than Commented Comments. I was confused by the lack of a Fig 12.x counterpart to Fig 14.3 and, never having used them, the lack of an 'ownedTags' property. Independent orphan Tags are not very modular, but perhaps appropriate. org.omg.emof.oppositePropertyName is better than my suggestion of http://schema.omg.org/spec/MOF/2.0/emof.xml#Property.oppositeRoleName The intent of the proposal is to enable "a.b" to work for in OCL when b is a property role name that is lost when the meta-model is represented as EMOF. The problem, philosophically, is not in EMOF, but in OCL's (and QVT's) 'compile-time' use of a 'run-time' serialisation. Hence the request to endorse an 'annotation' policy to provide the information without needing to change EMOF at all. An even broader question: when mapping from a CMOF metamodel, such as UML, to EMOF, is it a good idea to assume that each Association maps directly to one, or a linked pair of, Properties? Ah, no! This is beyond my knowledge, but it makes good sense. If there is a three-way association between A, B and C with roles myA, myB and myC of which only myB is navigable, then anA.myB and aC.myB work regardless, since A::myB and C::myB are in an EMOF representation. If the obvious navigation opposites are provided: - B::myA is tagged as the org.omg.emof.oppositePropertyName of A::myB - B::myC is tagged as the org.omg.emof.oppositePropertyName of C::myB then aB.myA and aB.myC can work, but aC.myA and anA.myC are problematic. If instead - B::myA is tagged as the org.omg.emof.oppositePropertyName of both A::myB and C::myB - B::myC is tagged as the org.omg.emof.oppositePropertyName of both A::myB and C::myB this identifies the 3-way association with the three role names myA, myB and myC, allowing the existence of A::myC and C::myA to be inferred. aC.myA and anA.myC now work as well. When OCL persists this resolution in its AST, the OppositePropertyCallExp under discussion for Issue 15175 must reference a property owned by the navigation target that is part of the relevant association. Thus for aC.myA the OppositePropertyCallExp should reference A::myB so that the A:: identifies the target and the A::myB identifies the association of which C is also part via C::myB. The OCL AST element and the tagged EMOF meta-model provide the requisite control for an OCL evaluation. I hope my understanding is correct; thinking about this perhaps unlikely case seems to give a clearer association-based view of the necessary inferences. Another question: is an unqualified name sufficient? I.m assuming it is for OCL/QVT purposes but are there other potential uses? Yes/No, yes, yes (any analysis tool). The tag in EMOF is identifying the missing role name. The exact classes are provided by the opposite property's owner and target. When used in an OCL expression, a qualification may be needed as in "aDerivedA.A::myB", but this is an OCL concrete syntax to resolve ambiguities between multiple names in the same scope. But: 'is a name sufficient'? No. For an expression such as "a.b" OCL needs to know not only that "b" exists, but also what its type is. The element type is defined by the owner of the opposite. The multiplicity, ordering and unqueness is not. So org.omg.emof.oppositeLower org.omg.emof.oppositeUpper org.omg.emof.oppositeIsOrdered org.omg.emof.oppositeIsUnique (so perhaps org.omg.emof.oppositeName rather than org.omg.emof.oppositePropertyName) may also be needed (with sensible defaults) unless a better understanding of UML than mine can show that any are redundant. I suspect that oppositeIsUnique may be redundant. In the 3-way example above, defining these for B::myA and B::myC is sufficient, since the inferred A::myC and C::myA are fully defined by B::myC and B::myA. An alternative and more faithful (to the semantics) mapping would be to introduce an EMOF class for each CMOF Association with the same name as the association (yes, each association in the UML metamodel does have an explicit name in the normative XMI file for the metamodel). Introduction of Associations to EMOF seems to totally undermine its 'Essential' philosophy and will make the serialisation significantly larger and backwards surprising. As indicated above, the association is inferable from the tags. (Perhaps the association name could also be provided by an org.omg.emof.associationName tag on any one of the properties.) Regards Ed Willink No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.814 / Virus Database: 271.1.1/2843 - Release Date: 04/29/10 19:27:00 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.814 / Virus Database: 271.1.1/2843 - Release Date: 04/29/10 19:27:00 From: "Uhl, Axel" To: Jim Amsden , "'mof2core-rtf@omg.org'" CC: "ed.merks@gmail.com" , "kenn.hussey@gmail.com" Date: Mon, 3 May 2010 18:21:15 +0200 Subject: RE: Discussion on MOF2 Core Issue 12800 Thread-Topic: Discussion on MOF2 Core Issue 12800 Thread-Index: AcrobqIGPUBVEtZEQlWqSuERV5tiGQCaUcwQ Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {8457A262-896B-43E1-8319-5280C93DC733} x-cr-hashedpuzzle: FOnP GFm0 LrlJ Luus M2sQ PGL3 RUY2 XSCE XUA8 ZidI b18T iuM+ kEpc qBR+ sv7a s0BJ;4;ZQBkAC4AbQBlAHIAawBzAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBqAGEAbQBzAGQAZQBuAEAAdQBzAC4AaQBiAG0ALgBjAG8AbQA7AGsAZQBuAG4ALgBoAHUAcwBzAGUAeQBAAGcAbQBhAGkAbAAuAGMAbwBtADsAbQBvAGYAMgBjAG8AcgBlAC0AcgB0AGYAQABvAG0AZwAuAG8AcgBnAA==;Sosha1_v1;7;{8457A262-896B-43E1-8319-5280C93DC733};YQB4AGUAbAAuAHUAaABsAEAAcwBhAHAALgBjAG8AbQA=;Mon, 03 May 2010 16:21:15 GMT;UgBFADoAIABEAGkAcwBjAHUAcwBzAGkAbwBuACAAbwBuACAATQBPAEYAMgAgAEMAbwByAGUAIABJAHMAcwB1AGUAIAAxADIAOAAwADAA acceptlanguage: en-US Hi Jim, I see that EMOF makes explicit where things are stored. I fully agree that the bidirectional coupling of model components needs to be avoided; more so, BTW, than the bidirectional coupling of metamodel components, I think. By this token, opposite properties are evil because EMOF decided to tie the presence of properties to storage and serialization aspects, if I understand this correctly, because properties can only be owned by classes, as there is no association to hold them and hide them from the opposite class's contract. In addition to that I see that queries over a well-defined scope of EMOF models are very useful. Use cases include model validation, metrics and tool functionality such as cross-referencers for models ("show referenced by"). Some queries are semantically equivalent to traversing references backwards. We discussed the alternative for OCL that uses allInstances()->select(...) already. With CMOF there's a powerful way to separate storage/serialization aspects from the specification of multiplicity constraints and the provisioning of a name for the opposite end. Multiplicity constraints for the opposite direction can easily be added by using OCL constraints for EMOF models that don't use opposites. The only remaining problem is the lack of a convenient name so OCL or query languages can use it as a shorthand for expressions/queries that otherwise are really clumsy and lengthy to write. I'm not convinced that this breaks with the functional / non-functional objectives driving the EMOF design because the same functionality can be expressed with a query mechanism, only that the intent gets harder to see and maintain. On the use of tags for the new property - this could have significant effect on EMOF and EMF. The effect on EMOF is that now tags are introduced into the EMOF structure model to provide "convenience" for some OCL operations. EMOF doen't include OCL, so that seems somewhat artificial. Additional semantics have to be added to EMOF to specify how this tag value is set when properties and opposites change, and how it is reflected. OCL would have to be extended to understand the special case where aClass.aProperty was referring to a tag rather than an actual property. If we choose an OCL-like tag name instead of an EMOF tag name, I'm also happy with it, although I would presume that there may be other use cases for, e.g., other query languages that may also be interested in this piece of metadata. The question here is just whether or not we forsee other future uses of such a tag that go beyond OCL. Regarding your request for additional semantics, I suggest we define a constraint that says this tag is only permissible if the property tagged by it does not have an opposite defined. This in particular covers the CMOF case as well, so this remains something useful in the EMOF world only. I would additionally find it useful to introduce an operation on Property that returns the name of the other "end" which encapsulates the meaning of this tag and resorts to the real opposite if defined. This, of course, only is an option if the tag is defined as an EMOF and not as an OCL tag. I don't think that semantics are needed for propagating any changes of properties and opposites, based on what I wrote above regarding constraining the use of the tag. And yes, OCL would need to be extended, as described earlier in this thread, using an additional AST class OppositePropertyCallExp that is sibling to PropertyCallExp and refers to the "real" property. This is an OCL change, not an EMOF change, obviously. When you mention a Wiki, could you set one up? I had thought that an OMG-hosted archive of this e-mail exchange may be sufficient for everyone to follow, though. If nobody else volunteers, I can draft a piece describing the relationships between the tag proposed and the respective OCL extension around OppositePropertyCallExp if that's considered helpful. Best, -- Axel From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, April 30, 2010 4:08 PM To: 'mof2core-rtf@omg.org' Cc: ed.merks@gmail.com; kenn.hussey@gmail.com Subject: RE: Discussion on MOF2 Core Issue 12800 Axel, I understand these arguments. However, EMOF (and EMF) were specifically designed to enable efficient specification and implementation of navigability. The design was not intended to use navigability to indicate "efficient access is desired in this direction" while also allowing some sort of less efficient access in the non-navigable direction. Rather navigability was intended to indicate what information is available from what context in order to model intended semantics and manage coupling. OCL does not follow these conventions, allowing one to ignore navigability (other then perhaps for efficiency purposes). This is inconsistent with the functional and non-functional objectives that drove the definition of EMOF. Now one could suggest those design goals were misguided, or have become out of date due to change in navigability in UML (which did not effect Basic), or changing requirements. If the issue is changing requirements EMOF, then I would think the EMF community would be driving this, so I would defer to that community for further comment. Ed? Kenn? Others? On the use of tags for the new property - this could have significant effect on EMOF and EMF. The effect on EMOF is that now tags are introduced into the EMOF structure model to provide "convenience" for some OCL operations. EMOF doen't include OCL, so that seems somewhat artificial. Additional semantics have to be added to EMOF to specify how this tag value is set when properties and opposites change, and how it is reflected. OCL would have to be extended to understand the special case where aClass.aProperty was referring to a tag rather than an actual property. Now any updates to properties and opposites would have to make the appropriate updates to the tag value in EMF. This could raise the very issues leaving associations out of EMF was intended to avoid. Again, I defer to the EMF experts. So how do we move forward: 1. We understand exactly the use cases driving this change - not in email exchanges but on a Wiki where they can be adequately captured, contributed to and reviewed 2. We explore options for supporting the use cases including making EMOF "associations" navigable in both directions (through property opposite) in cases where this is needed in the model, using the mediator pattern for cases were property opposite is not adequate, using convenience tags (that might be optional), merging CMOF associations to EMOF, etc. 3. We pick one or two of the explored options and write them up so they can be properly communicated, understood, reviewed, and evaluated. Any change to EMOF should get significant scrutiny since it results in changes to EMF which effects a lot of existing products. 4. Decide on an approach and include it in a ballot, assuming the approach is applicable to an RTF. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: Jim Amsden/Raleigh/IBM@IBMUS, "'mof2core-rtf@omg.org'" Date: 04/30/2010 04:00 AM Subject: RE: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Hi Jim, nobody doubts that a useful class of apps can be built without the tag proposed. Nobody doubts either that there are other ways to solve the problem. Neither seems to exist doubt among many of us that there are serious use cases for OCL-specified expressions that want to express something about a property that doesn't have an opposite, and in some of these cases the expression can compute only the referenced element e1 and then needs to make a statement about those elements referencing e1 using a certain property. Now you may argue that you can always write A.allInstances()->select(a | a.p = e1) to get a hold of all elements of type A or A's subtypes that reference e1 through property p. And yes, it is certainly possible for an OCL infrastructure to recognize such constructs and---given some querying infrastructure---provide performance-improved ways to evaluate such expressions. What we're discussing here is a convenience that would allow us to write an OCL expression e1.r instead, where "r" is the name provided in the tag under discussion on property p which then would lead to the creation of an OCL AST element of the class OppositePropertyCallExp requested by issue 15175 (http://www.omg.org/issues/issue15175.txt) where the OppositePropertyCallExp references the property p. This approach according to a PoC we have implemented at SAP significantly simplifies the OCL environment's job and allows OCL writers to use the very intuitive unchanged concrete syntax for navigation expressions. It simplifies the OCL evaluation environment's life because it doesn't have to do deep inspection and transformation of the OCL AST to recognize and efficiently execute an allInstances()->select(...) construct where the select's body compares exactly one property. In the sequel, with an OppositePropertyCallExp it becomes much simpler to trace back a change of the p property to the contexts on which the using OCL expression may have changed its value. This is much harder to accomplish for the allInstances()->select(...) approach. The tag proposed is already the light-weight and therefore EM(O)F spirit-compliant alternative to introducing a more heavyweight construct which we also PoC-ed, namely the possibility to let a Property (EReference) own its opposite Property (EReference). While this also works, it raises issues regarding enforcing the opposite property's multiplicity constraints and is more of a backward compatibility issue because it breaks code that so far assumes that an EM(O)F Property / EReference is always owned by a(n) (E)Class. The only simplication that a Property-owned opposite would have facilitated would have been that the OCL abstract syntax / metamodel would not need to change because the existing PropertyCallExp could have been used to refer to the property-owned opposite. But in addition to the difficult multiplicity enforcement, Ed Merks already commented that it would shift the cost away from where the benefit is (from OCL to EMOF/Ecore). Your comment regarding the use of CMOF does not seem pragmatic to me. We're trying to make good use of EMF as an almost compliant EMOF implementation. We can live with many of its limitations. The lack of true associations can be circumvented by introducing what EMF needs anyhow, namely good query infrastructure (see also the query2 EMF contribution SAP made which is in incubation status right now). OCL works great on EMF. The last significant stumbling block is this major inconvenience when it comes to OCL-constraining EM(O)F models. If getting this resolved in a standard way only takes the agreement on a tag, I have a hard time understanding the objections. The CMOF alternative would mean we can't use EMF which means we'd have to write or buy a completely different model management infrastructure which means we can't use a lot of the existing Eclipse tool sets around EMF which also means that contributions that SAP due to a finally relaxed open source policy will be making in the future would not be to the benefit of the community. Besides, beyond associations which certainly are the greatest benefit of CMOF over EMOF, CMOF introduces many things that we don't feel we need for our tasks. Best, -- Axel From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, April 30, 2010 4:11 AM To: 'mof2core-rtf@omg.org' Subject: Re: Discussion on MOF2 Core Issue 12800 I do object to this. EMF has been built on EMOF concepts for years. We have developed a large number of transforms that have not needed this extra property. If associations are needed by a tool, then it should use CMOF, not EMOF. If a modeler needs something like an association in EMOF/EMF, then they can use the mediator pattern reasonably effectively. I also do not believe EMOF should specify or require any tags to support structural modeling. Tags were for extensibility, not fundamental metamodel concepts. Such an addition would need to have compelling use cases that cannot be addressed by other means. The concept of association was explicitly kept out of EMOF. I do not believe we should graft something back in using tags to simulate association ends. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: "'pete.rivett@adaptive.com'" , "'mof2core-rtf@omg.org'" , Jim Amsden/Raleigh/IBM@IBMUS Cc: "'ed@willink.me.uk'" Date: 04/29/2010 06:21 PM Subject: Re: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Pete, thanks for kicking this off. At some other place Ed already proposed "Property.oppositeRoleName" as tag name which seemed to make sense to me. Jim, do you still have general objections to introducing such a standard tag? If so, look at OCL issue 15175 where with a naming tag for the non-existing opposite we can save a concrete syntax extension for OCL and make navigation in these directions more intuitive. Best, -- Axel ------------------ Sent from BB -------------------------------------------------------------------------------- From: Pete Rivett To: mof2core-rtf@omg.org ; Jim Amsden Cc: Ed Willink ; Uhl, Axel Sent: Thu Apr 29 23:32:25 2010 Subject: Discussion on MOF2 Core Issue 12800 Below is the issue and my original response: I removed it from the ballot since Jim had raised a comment and I realized the proposal was not complete (e.g. did not define the name of the Tag) so it needed discussion. This email is intended to start such a discussion. I.m going on vacation for a week so hopefully you.ll all have it sorted by the time I get back J BTW Ed, EMOF (as well as CMOF) does include Tags . see Figure 12.1 in formall/06-06-01 where you can see that EMOF merges in the Extension package which defines Tag. Jim wrote: EMOF does not have associations. Rather it uses a notation option for properties that have non-primitive types that uses CMOF association notation. So there are no member or owned ends of the association. Rather QVT should treat these as properties which not non-navigable associations, and there would be no need to a name for the un-named end. Issue 12800: Capturing Unnavigable Opposite Property Role Names (mof2core-rtf) Click here for this issue's archive. Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@willink.me.uk) Nature: Uncategorized Issue Severity: Summary: EMOF does not support identification of the opposite role name for a non-navigable association, however QVT requires such role names to be used. OCL defines an implicit role name, but UML graphics supports arbitrary names. At the EclipseCon OMG symposium in February, it seemed appropriate to resolve the limitation in the following way. An opposite role name may be denoted by a Comment Comment with the inner Comment defining a formal function for the outer Comment. Thus in: "backward" is defined as the oppositeRoleName of "forward". This practice makes the missing information available, and avoids any changes to the MOF meta-model and so avoids introducing any additional Property instances that might bloat existing usage. It would be helpful if a future MOF version, or an addendum to existing versions, endorse this practice. An equivalent Ecore EAnnotation and cross-conversion was introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede). Resolution: The use of .non-navigable. is out-dated: the issue is where Property::opposite is empty and there is nothing to hang the name on. This would seem better addressed by the use of a MOF Tag rather than two nested Comments. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 tel: +1 949 330 7677, cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp To: "Uhl, Axel" , Juergen Boldt Cc: "ed.merks@gmail.com" , "kenn.hussey@gmail.com" , "'mof2core-rtf@omg.org'" Subject: RE: Discussion on MOF2 Core Issue 12800 X-KeepSent: 1B92DEF2:50AA1B62-85257718:0078D1E1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 From: Jim Amsden Date: Mon, 3 May 2010 16:05:52 -0600 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 05/03/2010 16:05:54, Serialize complete at 05/03/2010 16:05:54 Axel, I'm having trouble understanding the motivation for the approach. I understand there will be EMOF properties without opposites. I do not understand why a tag is required to provide the opposite when one wasn't intended. I realize this limits what is accessible at runtime from the object, and limits OCL queries - but that seems to be the point. I still think we should do the following: 1. We understand exactly the use cases driving this change: captured, contributed to and reviewed 2. We explore options for supporting the use cases including making EMOF "associations" navigable in both directions (through property opposite) in cases where this is needed in the model, using the mediator pattern for cases were property opposite is not adequate, using convenience tags (that might be optional), merging CMOF associations to EMOF, etc. 3. We pick one or two of the explored options and write them up so they can be properly communicated, understood, reviewed, and evaluated. Any change to EMOF should get significant scrutiny since it results in changes to EMF which effects a lot of existing products. 4. Decide on an approach and include it in a ballot, assuming the approach is applicable to an RTF. Juergen, Can you setup a MOF Wiki, including at least the recipients of this email, and anyone else on the MOF RTF? Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: Jim Amsden/Raleigh/IBM@IBMUS, "'mof2core-rtf@omg.org'" Cc: "ed.merks@gmail.com" , "kenn.hussey@gmail.com" Date: 05/03/2010 12:25 PM Subject: RE: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Hi Jim, I see that EMOF makes explicit where things are stored. I fully agree that the bidirectional coupling of model components needs to be avoided; more so, BTW, than the bidirectional coupling of metamodel components, I think. By this token, opposite properties are evil because EMOF decided to tie the presence of properties to storage and serialization aspects, if I understand this correctly, because properties can only be owned by classes, as there is no association to hold them and hide them from the opposite class's contract. In addition to that I see that queries over a well-defined scope of EMOF models are very useful. Use cases include model validation, metrics and tool functionality such as cross-referencers for models ("show referenced by"). Some queries are semantically equivalent to traversing references backwards. We discussed the alternative for OCL that uses allInstances()->select(...) already. With CMOF there's a powerful way to separate storage/serialization aspects from the specification of multiplicity constraints and the provisioning of a name for the opposite end. Multiplicity constraints for the opposite direction can easily be added by using OCL constraints for EMOF models that don't use opposites. The only remaining problem is the lack of a convenient name so OCL or query languages can use it as a shorthand for expressions/queries that otherwise are really clumsy and lengthy to write. I'm not convinced that this breaks with the functional / non-functional objectives driving the EMOF design because the same functionality can be expressed with a query mechanism, only that the intent gets harder to see and maintain. On the use of tags for the new property - this could have significant effect on EMOF and EMF. The effect on EMOF is that now tags are introduced into the EMOF structure model to provide "convenience" for some OCL operations. EMOF doen't include OCL, so that seems somewhat artificial. Additional semantics have to be added to EMOF to specify how this tag value is set when properties and opposites change, and how it is reflected. OCL would have to be extended to understand the special case where aClass.aProperty was referring to a tag rather than an actual property. If we choose an OCL-like tag name instead of an EMOF tag name, I'm also happy with it, although I would presume that there may be other use cases for, e.g., other query languages that may also be interested in this piece of metadata. The question here is just whether or not we forsee other future uses of such a tag that go beyond OCL. Regarding your request for additional semantics, I suggest we define a constraint that says this tag is only permissible if the property tagged by it does not have an opposite defined. This in particular covers the CMOF case as well, so this remains something useful in the EMOF world only. I would additionally find it useful to introduce an operation on Property that returns the name of the other "end" which encapsulates the meaning of this tag and resorts to the real opposite if defined. This, of course, only is an option if the tag is defined as an EMOF and not as an OCL tag. I don't think that semantics are needed for propagating any changes of properties and opposites, based on what I wrote above regarding constraining the use of the tag. And yes, OCL would need to be extended, as described earlier in this thread, using an additional AST class OppositePropertyCallExp that is sibling to PropertyCallExp and refers to the "real" property. This is an OCL change, not an EMOF change, obviously. When you mention a Wiki, could you set one up? I had thought that an OMG-hosted archive of this e-mail exchange may be sufficient for everyone to follow, though. If nobody else volunteers, I can draft a piece describing the relationships between the tag proposed and the respective OCL extension around OppositePropertyCallExp if that's considered helpful. Best, -- Axel From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, April 30, 2010 4:08 PM To: 'mof2core-rtf@omg.org' Cc: ed.merks@gmail.com; kenn.hussey@gmail.com Subject: RE: Discussion on MOF2 Core Issue 12800 Axel, I understand these arguments. However, EMOF (and EMF) were specifically designed to enable efficient specification and implementation of navigability. The design was not intended to use navigability to indicate "efficient access is desired in this direction" while also allowing some sort of less efficient access in the non-navigable direction. Rather navigability was intended to indicate what information is available from what context in order to model intended semantics and manage coupling. OCL does not follow these conventions, allowing one to ignore navigability (other then perhaps for efficiency purposes). This is inconsistent with the functional and non-functional objectives that drove the definition of EMOF. Now one could suggest those design goals were misguided, or have become out of date due to change in navigability in UML (which did not effect Basic), or changing requirements. If the issue is changing requirements EMOF, then I would think the EMF community would be driving this, so I would defer to that community for further comment. Ed? Kenn? Others? On the use of tags for the new property - this could have significant effect on EMOF and EMF. The effect on EMOF is that now tags are introduced into the EMOF structure model to provide "convenience" for some OCL operations. EMOF doen't include OCL, so that seems somewhat artificial. Additional semantics have to be added to EMOF to specify how this tag value is set when properties and opposites change, and how it is reflected. OCL would have to be extended to understand the special case where aClass.aProperty was referring to a tag rather than an actual property. Now any updates to properties and opposites would have to make the appropriate updates to the tag value in EMF. This could raise the very issues leaving associations out of EMF was intended to avoid. Again, I defer to the EMF experts. So how do we move forward: 1. We understand exactly the use cases driving this change - not in email exchanges but on a Wiki where they can be adequately captured, contributed to and reviewed 2. We explore options for supporting the use cases including making EMOF "associations" navigable in both directions (through property opposite) in cases where this is needed in the model, using the mediator pattern for cases were property opposite is not adequate, using convenience tags (that might be optional), merging CMOF associations to EMOF, etc. 3. We pick one or two of the explored options and write them up so they can be properly communicated, understood, reviewed, and evaluated. Any change to EMOF should get significant scrutiny since it results in changes to EMF which effects a lot of existing products. 4. Decide on an approach and include it in a ballot, assuming the approach is applicable to an RTF. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: Jim Amsden/Raleigh/IBM@IBMUS, "'mof2core-rtf@omg.org'" Date: 04/30/2010 04:00 AM Subject: RE: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Hi Jim, nobody doubts that a useful class of apps can be built without the tag proposed. Nobody doubts either that there are other ways to solve the problem. Neither seems to exist doubt among many of us that there are serious use cases for OCL-specified expressions that want to express something about a property that doesn't have an opposite, and in some of these cases the expression can compute only the referenced element e1 and then needs to make a statement about those elements referencing e1 using a certain property. Now you may argue that you can always write A.allInstances()->select(a | a.p = e1) to get a hold of all elements of type A or A's subtypes that reference e1 through property p. And yes, it is certainly possible for an OCL infrastructure to recognize such constructs and---given some querying infrastructure---provide performance-improved ways to evaluate such expressions. What we're discussing here is a convenience that would allow us to write an OCL expression e1.r instead, where "r" is the name provided in the tag under discussion on property p which then would lead to the creation of an OCL AST element of the class OppositePropertyCallExp requested by issue 15175 (http://www.omg.org/issues/issue15175.txt) where the OppositePropertyCallExp references the property p. This approach according to a PoC we have implemented at SAP significantly simplifies the OCL environment's job and allows OCL writers to use the very intuitive unchanged concrete syntax for navigation expressions. It simplifies the OCL evaluation environment's life because it doesn't have to do deep inspection and transformation of the OCL AST to recognize and efficiently execute an allInstances()->select(...) construct where the select's body compares exactly one property. In the sequel, with an OppositePropertyCallExp it becomes much simpler to trace back a change of the p property to the contexts on which the using OCL expression may have changed its value. This is much harder to accomplish for the allInstances()->select(...) approach. The tag proposed is already the light-weight and therefore EM(O)F spirit-compliant alternative to introducing a more heavyweight construct which we also PoC-ed, namely the possibility to let a Property (EReference) own its opposite Property (EReference). While this also works, it raises issues regarding enforcing the opposite property's multiplicity constraints and is more of a backward compatibility issue because it breaks code that so far assumes that an EM(O)F Property / EReference is always owned by a(n) (E)Class. The only simplication that a Property-owned opposite would have facilitated would have been that the OCL abstract syntax / metamodel would not need to change because the existing PropertyCallExp could have been used to refer to the property-owned opposite. But in addition to the difficult multiplicity enforcement, Ed Merks already commented that it would shift the cost away from where the benefit is (from OCL to EMOF/Ecore). Your comment regarding the use of CMOF does not seem pragmatic to me. We're trying to make good use of EMF as an almost compliant EMOF implementation. We can live with many of its limitations. The lack of true associations can be circumvented by introducing what EMF needs anyhow, namely good query infrastructure (see also the query2 EMF contribution SAP made which is in incubation status right now). OCL works great on EMF. The last significant stumbling block is this major inconvenience when it comes to OCL-constraining EM(O)F models. If getting this resolved in a standard way only takes the agreement on a tag, I have a hard time understanding the objections. The CMOF alternative would mean we can't use EMF which means we'd have to write or buy a completely different model management infrastructure which means we can't use a lot of the existing Eclipse tool sets around EMF which also means that contributions that SAP due to a finally relaxed open source policy will be making in the future would not be to the benefit of the community. Besides, beyond associations which certainly are the greatest benefit of CMOF over EMOF, CMOF introduces many things that we don't feel we need for our tasks. Best, -- Axel From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, April 30, 2010 4:11 AM To: 'mof2core-rtf@omg.org' Subject: Re: Discussion on MOF2 Core Issue 12800 I do object to this. EMF has been built on EMOF concepts for years. We have developed a large number of transforms that have not needed this extra property. If associations are needed by a tool, then it should use CMOF, not EMOF. If a modeler needs something like an association in EMOF/EMF, then they can use the mediator pattern reasonably effectively. I also do not believe EMOF should specify or require any tags to support structural modeling. Tags were for extensibility, not fundamental metamodel concepts. Such an addition would need to have compelling use cases that cannot be addressed by other means. The concept of association was explicitly kept out of EMOF. I do not believe we should graft something back in using tags to simulate association ends. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: "'pete.rivett@adaptive.com'" , "'mof2core-rtf@omg.org'" , Jim Amsden/Raleigh/IBM@IBMUS Cc: "'ed@willink.me.uk'" Date: 04/29/2010 06:21 PM Subject: Re: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Pete, thanks for kicking this off. At some other place Ed already proposed "Property.oppositeRoleName" as tag name which seemed to make sense to me. Jim, do you still have general objections to introducing such a standard tag? If so, look at OCL issue 15175 where with a naming tag for the non-existing opposite we can save a concrete syntax extension for OCL and make navigation in these directions more intuitive. Best, -- Axel ------------------ Sent from BB -------------------------------------------------------------------------------- From: Pete Rivett To: mof2core-rtf@omg.org ; Jim Amsden Cc: Ed Willink ; Uhl, Axel Sent: Thu Apr 29 23:32:25 2010 Subject: Discussion on MOF2 Core Issue 12800 Below is the issue and my original response: I removed it from the ballot since Jim had raised a comment and I realized the proposal was not complete (e.g. did not define the name of the Tag) so it needed discussion. This email is intended to start such a discussion. Iâm going on vacation for a week so hopefully youâll all have it sorted by the time I get back J BTW Ed, EMOF (as well as CMOF) does include Tags . see Figure 12.11 in formal/06-06-01 where you can see that EMOF merges in the Extension package which defines Tag. Jim wrote: EMOF does not have associations. Rather it uses a notation option for properties that have non-primitive types that uses CMOF association notation. So there are no member or owned ends of the association. Rather QVT should treat these as properties which not non-navigable associations, and there would be no need to a name for the un-named end. Issue 12800: Capturing Unnavigable Opposite Property Role Names (mof2core-rtf) Click here for this issue's archive. Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@willink.me.uk) Nature: Uncategorized Issue Severity: Summary: EMOF does not support identification of the opposite role name for a non-navigable association, however QVT requires such role names to be used. OCL defines an implicit role name, but UML graphics supports arbitrary names. At the EclipseCon OMG symposium in February, it seemed appropriate to resolve the limitation in the following way. An opposite role name may be denoted by a Comment Comment with the inner Comment defining a formal function for the outer Comment. Thus in: "backward" is defined as the oppositeRoleName of "forward". This practice makes the missing information available, and avoids any changes to the MOF meta-model and so avoids introducing any additional Property instances that might bloat existing usage. It would be helpful if a future MOF version, or an addendum to existing versions, endorse this practice. An equivalent Ecore EAnnotation and cross-conversion was introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede). Resolution: The use of ânon-navigableâ is out-dated: the issue is where Property::opposite is empty and there is nothing to hang the name on. This would seem better addressed by the use of a MOF Tag rather than two nested Comments. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 tel: +1 949 330 7677, cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp From: "Uhl, Axel" To: "'jamsden@us.ibm.com'" , "'juergen@omg.org'" CC: "'ed.merks@gmail.com'" , "'kenn.hussey@gmail.com'" , "'mof2core-rtf@omg.org'" Date: Tue, 4 May 2010 08:56:18 +0200 Subject: Re: Discussion on MOF2 Core Issue 12800 Thread-Topic: Discussion on MOF2 Core Issue 12800 Thread-Index: AcrrDNuu4L+OzMaxQV2HSGmaoQ3ZKgASgltJ Accept-Language: en-US, de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Jim, you mentioned the most important use case for not having true opposite properties yourself. It strongly couples the resulting resources and may require updates to two resources for what should be an atomic change, thus incurring its own class of problems (diff, merge for example). OCL navigability (and for that matter probably also queriability with other query languages) should IMO be kept independent of the question whether or not and where the reference is stored. Yes, CMOF has all that, and it's as easy as adding an annotation to an EMOF Property to get to a similar level of convenience in EMOF. The annotation doesn't---as you're suggesting---mean that an opposite was intended. The opposite would add much more than named navigability which, as you observed, is often not desired. Best, -- Axel ------------------ Sent from BB -------------------------------------------------------------------------------- From: Jim Amsden To: Uhl, Axel; Juergen Boldt Cc: ed.merks@gmail.com ; kenn.hussey@gmail.com ; 'mof2core-rtf@omg.org' Sent: Tue May 04 00:05:52 2010 Subject: RE: Discussion on MOF2 Core Issue 12800 Axel, I'm having trouble understanding the motivation for the approach. I understand there will be EMOF properties without opposites. I do not understand why a tag is required to provide the opposite when one wasn't intended. I realize this limits what is accessible at runtime from the object, and limits OCL queries - but that seems to be the point. I still think we should do the following: 1. We understand exactly the use cases driving this change: captured, contributed to and reviewed 2. We explore options for supporting the use cases including making EMOF "associations" navigable in both directions (through property opposite) in cases where this is needed in the model, using the mediator pattern for cases were property opposite is not adequate, using convenience tags (that might be optional), merging CMOF associations to EMOF, etc. 3. We pick one or two of the explored options and write them up so they can be properly communicated, understood, reviewed, and evaluated. Any change to EMOF should get significant scrutiny since it results in changes to EMF which effects a lot of existing products. 4. Decide on an approach and include it in a ballot, assuming the approach is applicable to an RTF. Juergen, Can you setup a MOF Wiki, including at least the recipients of this email, and anyone else on the MOF RTF? Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: Jim Amsden/Raleigh/IBM@IBMUS, "'mof2core-rtf@omg.org'" Cc: "ed.merks@gmail.com" , "kenn.hussey@gmail.com" Date: 05/03/2010 12:25 PM Subject: RE: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Hi Jim, I see that EMOF makes explicit where things are stored. I fully agree that the bidirectional coupling of model components needs to be avoided; more so, BTW, than the bidirectional coupling of metamodel components, I think. By this token, opposite properties are evil because EMOF decided to tie the presence of properties to storage and serialization aspects, if I understand this correctly, because properties can only be owned by classes, as there is no association to hold them and hide them from the opposite class's contract. In addition to that I see that queries over a well-defined scope of EMOF models are very useful. Use cases include model validation, metrics and tool functionality such as cross-referencers for models ("show referenced by"). Some queries are semantically equivalent to traversing references backwards. We discussed the alternative for OCL that uses allInstances()->select(...) already. With CMOF there's a powerful way to separate storage/serialization aspects from the specification of multiplicity constraints and the provisioning of a name for the opposite end. Multiplicity constraints for the opposite direction can easily be added by using OCL constraints for EMOF models that don't use opposites. The only remaining problem is the lack of a convenient name so OCL or query languages can use it as a shorthand for expressions/queries that otherwise are really clumsy and lengthy to write. I'm not convinced that this breaks with the functional / non-functional objectives driving the EMOF design because the same functionality can be expressed with a query mechanism, only that the intent gets harder to see and maintain. On the use of tags for the new property - this could have significant effect on EMOF and EMF. The effect on EMOF is that now tags are introduced into the EMOF structure model to provide "convenience" for some OCL operations. EMOF doen't include OCL, so that seems somewhat artificial. Additional semantics have to be added to EMOF to specify how this tag value is set when properties and opposites change, and how it is reflected. OCL would have to be extended to understand the special case where aClass.aProperty was referring to a tag rather than an actual property. If we choose an OCL-like tag name instead of an EMOF tag name, I'm also happy with it, although I would presume that there may be other use cases for, e.g., other query languages that may also be interested in this piece of metadata. The question here is just whether or not we forsee other future uses of such a tag that go beyond OCL. Regarding your request for additional semantics, I suggest we define a constraint that says this tag is only permissible if the property tagged by it does not have an opposite defined. This in particular covers the CMOF case as well, so this remains something useful in the EMOF world only. I would additionally find it useful to introduce an operation on Property that returns the name of the other "end" which encapsulates the meaning of this tag and resorts to the real opposite if defined. This, of course, only is an option if the tag is defined as an EMOF and not as an OCL tag. I don't think that semantics are needed for propagating any changes of properties and opposites, based on what I wrote above regarding constraining the use of the tag. And yes, OCL would need to be extended, as described earlier in this thread, using an additional AST class OppositePropertyCallExp that is sibling to PropertyCallExp and refers to the "real" property. This is an OCL change, not an EMOF change, obviously. When you mention a Wiki, could you set one up? I had thought that an OMG-hosted archive of this e-mail exchange may be sufficient for everyone to follow, though. If nobody else volunteers, I can draft a piece describing the relationships between the tag proposed and the respective OCL extension around OppositePropertyCallExp if that's considered helpful. Best, -- Axel From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, April 30, 2010 4:08 PM To: 'mof2core-rtf@omg.org' Cc: ed.merks@gmail.com; kenn.hussey@gmail.com Subject: RE: Discussion on MOF2 Core Issue 12800 Axel, I understand these arguments. However, EMOF (and EMF) were specifically designed to enable efficient specification and implementation of navigability. The design was not intended to use navigability to indicate "efficient access is desired in this direction" while also allowing some sort of less efficient access in the non-navigable direction. Rather navigability was intended to indicate what information is available from what context in order to model intended semantics and manage coupling. OCL does not follow these conventions, allowing one to ignore navigability (other then perhaps for efficiency purposes). This is inconsistent with the functional and non-functional objectives that drove the definition of EMOF. Now one could suggest those design goals were misguided, or have become out of date due to change in navigability in UML (which did not effect Basic), or changing requirements. If the issue is changing requirements EMOF, then I would think the EMF community would be driving this, so I would defer to that community for further comment. Ed? Kenn? Others? On the use of tags for the new property - this could have significant effect on EMOF and EMF. The effect on EMOF is that now tags are introduced into the EMOF structure model to provide "convenience" for some OCL operations. EMOF doen't include OCL, so that seems somewhat artificial. Additional semantics have to be added to EMOF to specify how this tag value is set when properties and opposites change, and how it is reflected. OCL would have to be extended to understand the special case where aClass.aProperty was referring to a tag rather than an actual property. Now any updates to properties and opposites would have to make the appropriate updates to the tag value in EMF. This could raise the very issues leaving associations out of EMF was intended to avoid. Again, I defer to the EMF experts. So how do we move forward: 1. We understand exactly the use cases driving this change - not in email exchanges but on a Wiki where they can be adequately captured, contributed to and reviewed 2. We explore options for supporting the use cases including making EMOF "associations" navigable in both directions (through property opposite) in cases where this is needed in the model, using the mediator pattern for cases were property opposite is not adequate, using convenience tags (that might be optional), merging CMOF associations to EMOF, etc. 3. We pick one or two of the explored options and write them up so they can be properly communicated, understood, reviewed, and evaluated. Any change to EMOF should get significant scrutiny since it results in changes to EMF which effects a lot of existing products. 4. Decide on an approach and include it in a ballot, assuming the approach is applicable to an RTF. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: Jim Amsden/Raleigh/IBM@IBMUS, "'mof2core-rtf@omg.org'" Date: 04/30/2010 04:00 AM Subject: RE: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Hi Jim, nobody doubts that a useful class of apps can be built without the tag proposed. Nobody doubts either that there are other ways to solve the problem. Neither seems to exist doubt among many of us that there are serious use cases for OCL-specified expressions that want to express something about a property that doesn't have an opposite, and in some of these cases the expression can compute only the referenced element e1 and then needs to make a statement about those elements referencing e1 using a certain property. Now you may argue that you can always write A.allInstances()->select(a | a.p = e1) to get a hold of all elements of type A or A's subtypes that reference e1 through property p. And yes, it is certainly possible for an OCL infrastructure to recognize such constructs and---given some querying infrastructure---provide performance-improved ways to evaluate such expressions. What we're discussing here is a convenience that would allow us to write an OCL expression e1.r instead, where "r" is the name provided in the tag under discussion on property p which then would lead to the creation of an OCL AST element of the class OppositePropertyCallExp requested by issue 15175 (http://www.omg.org/issues/issue15175.txt) where the OppositePropertyCallExp references the property p. This approach according to a PoC we have implemented at SAP significantly simplifies the OCL environment's job and allows OCL writers to use the very intuitive unchanged concrete syntax for navigation expressions. It simplifies the OCL evaluation environment's life because it doesn't have to do deep inspection and transformation of the OCL AST to recognize and efficiently execute an allInstances()->select(...) construct where the select's body compares exactly one property. In the sequel, with an OppositePropertyCallExp it becomes much simpler to trace back a change of the p property to the contexts on which the using OCL expression may have changed its value. This is much harder to accomplish for the allInstances()->select(...) approach. The tag proposed is already the light-weight and therefore EM(O)F spirit-compliant alternative to introducing a more heavyweight construct which we also PoC-ed, namely the possibility to let a Property (EReference) own its opposite Property (EReference). While this also works, it raises issues regarding enforcing the opposite property's multiplicity constraints and is more of a backward compatibility issue because it breaks code that so far assumes that an EM(O)F Property / EReference is always owned by a(n) (E)Class. The only simplication that a Property-owned opposite would have facilitated would have been that the OCL abstract syntax / metamodel would not need to change because the existing PropertyCallExp could have been used to refer to the property-owned opposite. But in addition to the difficult multiplicity enforcement, Ed Merks already commented that it would shift the cost away from where the benefit is (from OCL to EMOF/Ecore). Your comment regarding the use of CMOF does not seem pragmatic to me. We're trying to make good use of EMF as an almost compliant EMOF implementation. We can live with many of its limitations. The lack of true associations can be circumvented by introducing what EMF needs anyhow, namely good query infrastructure (see also the query2 EMF contribution SAP made which is in incubation status right now). OCL works great on EMF. The last significant stumbling block is this major inconvenience when it comes to OCL-constraining EM(O)F models. If getting this resolved in a standard way only takes the agreement on a tag, I have a hard time understanding the objections. The CMOF alternative would mean we can't use EMF which means we'd have to write or buy a completely different model management infrastructure which means we can't use a lot of the existing Eclipse tool sets around EMF which also means that contributions that SAP due to a finally relaxed open source policy will be making in the future would not be to the benefit of the community. Besides, beyond associations which certainly are the greatest benefit of CMOF over EMOF, CMOF introduces many things that we don't feel we need for our tasks. Best, -- Axel From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, April 30, 2010 4:11 AM To: 'mof2core-rtf@omg.org' Subject: Re: Discussion on MOF2 Core Issue 12800 I do object to this. EMF has been built on EMOF concepts for years. We have developed a large number of transforms that have not needed this extra property. If associations are needed by a tool, then it should use CMOF, not EMOF. If a modeler needs something like an association in EMOF/EMF, then they can use the mediator pattern reasonably effectively. I also do not believe EMOF should specify or require any tags to support structural modeling. Tags were for extensibility, not fundamental metamodel concepts. Such an addition would need to have compelling use cases that cannot be addressed by other means. The concept of association was explicitly kept out of EMOF. I do not believe we should graft something back in using tags to simulate association ends. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: "'pete.rivett@adaptive.com'" , "'mof2core-rtf@omg.org'" , Jim Amsden/Raleigh/IBM@IBMUS Cc: "'ed@willink.me.uk'" Date: 04/29/2010 06:21 PM Subject: Re: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Pete, thanks for kicking this off. At some other place Ed already proposed "Property.oppositeRoleName" as tag name which seemed to make sense to me. Jim, do you still have general objections to introducing such a standard tag? If so, look at OCL issue 15175 where with a naming tag for the non-existing opposite we can save a concrete syntax extension for OCL and make navigation in these directions more intuitive. Best, -- Axel ------------------ Sent from BB -------------------------------------------------------------------------------- From: Pete Rivett To: mof2core-rtf@omg.org ; Jim Amsden Cc: Ed Willink ; Uhl, Axel Sent: Thu Apr 29 23:32:25 2010 Subject: Discussion on MOF2 Core Issue 12800 Below is the issue and my original response: I removed it from the ballot since Jim had raised a comment and I realized the proposal was not complete (e.g. did not define the name of the Tag) so it needed discussion. This email is intended to start such a discussion. Iâm going on vacation for a week so hopefully youâll all have it sorted by the time I get back J BTW Ed, EMOF (as well as CMOF) does include Tags . see Figure 122.1 in formal/06-06-01 where you can see that EMOF merges in the Extension package which defines Tag. Jim wrote: EMOF does not have associations. Rather it uses a notation option for properties that have non-primitive types that uses CMOF association notation. So there are no member or owned ends of the association. Rather QVT should treat these as properties which not non-navigable associations, and there would be no need to a name for the un-named end. Issue 12800: Capturing Unnavigable Opposite Property Role Names (mof2core-rtf) Click here for this issue's archive. Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@willink.me.uk) Nature: Uncategorized Issue Severity: Summary: EMOF does not support identification of the opposite role name for a non-navigable association, however QVT requires such role names to be used. OCL defines an implicit role name, but UML graphics supports arbitrary names. At the EclipseCon OMG symposium in February, it seemed appropriate to resolve the limitation in the following way. An opposite role name may be denoted by a Comment Comment with the inner Comment defining a formal function for the outer Comment. Thus in: "backward" is defined as the oppositeRoleName of "forward". This practice makes the missing information available, and avoids any changes to the MOF meta-model and so avoids introducing any additional Property instances that might bloat existing usage. It would be helpful if a future MOF version, or an addendum to existing versions, endorse this practice. An equivalent Ecore EAnnotation and cross-conversion was introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede). Resolution: The use of ânon-navigableâ is out-dated: the issue is where Property::opposite is empty and there is nothing to hang the name on. This would seem better addressed by the use of a MOF Tag rather than two nested Comments. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 tel: +1 949 330 7677, cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp From: "Uhl, Axel" To: Jim Amsden , Juergen Boldt CC: "ed.merks@gmail.com" , "kenn.hussey@gmail.com" , "'mof2core-rtf@omg.org'" Date: Tue, 4 May 2010 11:09:31 +0200 Subject: RE: Discussion on MOF2 Core Issue 12800 Thread-Topic: Discussion on MOF2 Core Issue 12800 Thread-Index: AcrrDNuu4L+OzMaxQV2HSGmaoQ3ZKgAW/qLA Accept-Language: en-US, de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {3A7CD987-B9B0-4592-B672-CCFDE0F89551} x-cr-hashedpuzzle: FP4n FRCf JkBy Lypb MNAr PO3b XRi/ ZAso l3Ic nXrE pBNk sdPn w579 xOWC 3SF8 30me;5;ZQBkAC4AbQBlAHIAawBzAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBqAGEAbQBzAGQAZQBuAEAAdQBzAC4AaQBiAG0ALgBjAG8AbQA7AGoAdQBlAHIAZwBlAG4AQABvAG0AZwAuAG8AcgBnADsAawBlAG4AbgAuAGgAdQBzAHMAZQB5AEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBtAG8AZgAyAGMAbwByAGUALQByAHQAZgBAAG8AbQBnAC4AbwByAGcA;Sosha1_v1;7;{3A7CD987-B9B0-4592-B672-CCFDE0F89551};YQB4AGUAbAAuAHUAaABsAEAAcwBhAHAALgBjAG8AbQA=;Tue, 04 May 2010 09:09:31 GMT;UgBFADoAIABEAGkAcwBjAHUAcwBzAGkAbwBuACAAbwBuACAATQBPAEYAMgAgAEMAbwByAGUAIABJAHMAcwB1AGUAIAAxADIAOAAwADAA acceptlanguage: en-US, de-DE Hi all, for clarification and towards Jim's request to list options, here goes a list of options I see, together with some reasoning. This may be included in the Wiki once we have it. An association is way more than what is being asked here. It's the combination of multiplicity and navigability constraints as well as names for both ends (in case we're talking about CMOF where the number of ends is limited to two). We're only asking the name, and that only as an annotation, and only in order to be able to conveniently phrase the query that we would also be able to express otherwise. So we're not really adding new capabilities to EMOF nor EMF. The real new capabilities are the availability of a query facility such as SAP is trying to contribute to EMF in the form of query2. The question is only how we make this available in the best possible way. Options: - no change to EMOF/EMF, no tag. class A { B b; }. Let x be an instance of class B. OCL will have to write A.allInstances()->select(i | i.b = x) For other query / expression languages this would work similarly. An OCL evaluator could try to identify such constructs and map them to a query facility. This is fairly complicated, and the expressions are clumsy to write. - introduce tag: class A { B b {org.omg.emof.oppositeRoleName="a"}; }. Again, let x be an instance of class B. OCL can now write x.a which parses into an OppositePropertyCallExp with A.b being the referred property. The OCL parser/analyzer matches "a" against the tag and then binds the opposite property call to the forward property A.b. This is convenient to write and doesn't require the declaration of an opposite, in particular not necessitating storage on the B side and not impacting B's XMI serialization and class contract. - introduce opposite: class A { B b opposite B.a; }; class B { A a opposite A.b; }; Again, x is an element of class B. OCL again can write x.a which parses as a PropertyCallExp referring to the B.a property. Establishing a reference between an A and a B element residing in two separate resources changes both resources. The resources can't live in different components because it would lead to cyclic dependencies between these components. B's serialization is changed by the existence of the B.a property, as is B's contract which includes a getter and a setter for B.a. As Jim pointed out, this is often not possible or not desirable. Therefore, this approach is impractical for most purposes. - introduce associations in EMOF: class A { B b exposes A2B.b; }; class B {}; association A2B { A a; B b; }. OCL as above. The association could own those properties that are not owned by a class, in this case the A2B.a property. The properties would be mutual opposites. We'd need a new metaclass in EMOF (and subsequently Ecore) for the association. Associations would probably be owned by a package. The problems with this type of association in the light of the EMOF/EMF spirit have been pointed out by Jim and Ed Merks. It's often impractical and undesirable to enforce the multiplicity constraints on the A a property. Ordering can't reasonably be implemented without storage. From a compatibility point of view, one problem with this type of approach is that a Property / EReference can no longer only be owned by a Class/EClass but also by an association. This will break some code here and there where people relied on the Class/Property composition to be the only composition for Property. - introduce opposite property as a Property/EReference element owned by the forward Property/EReference. This leads to the same OCL as above, using a PropertyCallExp referring to the nested Property/EReference. No OppositePropertyCallExp would be required. While this would not have to introduce a new class to EMOF/Ecore, it may go against the conformance with CMOF where a property is either owned by a class or by an association but not by another property. The same arguments regarding enforcing the multiplicity constraints apply as for the introduction of an Association metaclass described above. Also, the same argument regarding backward compatibiliy apply because then a Property/EReference still no longer could be owned only by a Class/EClass element which breaks the same code as described above. With these options, for reasons of backward compatiblity, amount of changes and EMOF/CMOF conformance, the tag-based approach seems best. Initially, we prototyped a solution based on nesting a Property/EReference inside another Property/EReference, making them opposites (last option described above). While this also worked and required fewer changes to OCL (in particular no OppositePropertyCallExp), Ed Merks made two points that I find very valid. He said that the cost should be where the benefit is (that's OCL in our case, so it may be ok to require a new AST class for OCL if in OCL we get the main benefit); additionally, he pointed me at the issues with enforcing the multiplicity characteristics of the opposite property, in particular orderedness. Looking forward to seeing other options and the discussion about those. Best, -- Axel From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, May 04, 2010 12:06 AM To: Uhl, Axel; Juergen Boldt Cc: ed.merks@gmail.com; kenn.hussey@gmail.com; 'mof2core-rtf@omg.org' Subject: RE: Discussion on MOF2 Core Issue 12800 Axel, I'm having trouble understanding the motivation for the approach. I understand there will be EMOF properties without opposites. I do not understand why a tag is required to provide the opposite when one wasn't intended. I realize this limits what is accessible at runtime from the object, and limits OCL queries - but that seems to be the point. I still think we should do the following: 1. We understand exactly the use cases driving this change: captured, contributed to and reviewed 2. We explore options for supporting the use cases including making EMOF "associations" navigable in both directions (through property opposite) in cases where this is needed in the model, using the mediator pattern for cases were property opposite is not adequate, using convenience tags (that might be optional), merging CMOF associations to EMOF, etc. 3. We pick one or two of the explored options and write them up so they can be properly communicated, understood, reviewed, and evaluated. Any change to EMOF should get significant scrutiny since it results in changes to EMF which effects a lot of existing products. 4. Decide on an approach and include it in a ballot, assuming the approach is applicable to an RTF. Juergen, Can you setup a MOF Wiki, including at least the recipients of this email, and anyone else on the MOF RTF? Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: Jim Amsden/Raleigh/IBM@IBMUS, "'mof2core-rtf@omg.org'" Cc: "ed.merks@gmail.com" , "kenn.hussey@gmail.com" Date: 05/03/2010 12:25 PM Subject: RE: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Hi Jim, I see that EMOF makes explicit where things are stored. I fully agree that the bidirectional coupling of model components needs to be avoided; more so, BTW, than the bidirectional coupling of metamodel components, I think. By this token, opposite properties are evil because EMOF decided to tie the presence of properties to storage and serialization aspects, if I understand this correctly, because properties can only be owned by classes, as there is no association to hold them and hide them from the opposite class's contract. In addition to that I see that queries over a well-defined scope of EMOF models are very useful. Use cases include model validation, metrics and tool functionality such as cross-referencers for models ("show referenced by"). Some queries are semantically equivalent to traversing references backwards. We discussed the alternative for OCL that uses allInstances()->select(...) already. With CMOF there's a powerful way to separate storage/serialization aspects from the specification of multiplicity constraints and the provisioning of a name for the opposite end. Multiplicity constraints for the opposite direction can easily be added by using OCL constraints for EMOF models that don't use opposites. The only remaining problem is the lack of a convenient name so OCL or query languages can use it as a shorthand for expressions/queries that otherwise are really clumsy and lengthy to write. I'm not convinced that this breaks with the functional / non-functional objectives driving the EMOF design because the same functionality can be expressed with a query mechanism, only that the intent gets harder to see and maintain. On the use of tags for the new property - this could have significant effect on EMOF and EMF. The effect on EMOF is that now tags are introduced into the EMOF structure model to provide "convenience" for some OCL operations. EMOF doen't include OCL, so that seems somewhat artificial. Additional semantics have to be added to EMOF to specify how this tag value is set when properties and opposites change, and how it is reflected. OCL would have to be extended to understand the special case where aClass.aProperty was referring to a tag rather than an actual property. If we choose an OCL-like tag name instead of an EMOF tag name, I'm also happy with it, although I would presume that there may be other use cases for, e.g., other query languages that may also be interested in this piece of metadata. The question here is just whether or not we forsee other future uses of such a tag that go beyond OCL. Regarding your request for additional semantics, I suggest we define a constraint that says this tag is only permissible if the property tagged by it does not have an opposite defined. This in particular covers the CMOF case as well, so this remains something useful in the EMOF world only. I would additionally find it useful to introduce an operation on Property that returns the name of the other "end" which encapsulates the meaning of this tag and resorts to the real opposite if defined. This, of course, only is an option if the tag is defined as an EMOF and not as an OCL tag. I don't think that semantics are needed for propagating any changes of properties and opposites, based on what I wrote above regarding constraining the use of the tag. And yes, OCL would need to be extended, as described earlier in this thread, using an additional AST class OppositePropertyCallExp that is sibling to PropertyCallExp and refers to the "real" property. This is an OCL change, not an EMOF change, obviously. When you mention a Wiki, could you set one up? I had thought that an OMG-hosted archive of this e-mail exchange may be sufficient for everyone to follow, though. If nobody else volunteers, I can draft a piece describing the relationships between the tag proposed and the respective OCL extension around OppositePropertyCallExp if that's considered helpful. Best, -- Axel From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, April 30, 2010 4:08 PM To: 'mof2core-rtf@omg.org' Cc: ed.merks@gmail.com; kenn.hussey@gmail.com Subject: RE: Discussion on MOF2 Core Issue 12800 Axel, I understand these arguments. However, EMOF (and EMF) were specifically designed to enable efficient specification and implementation of navigability. The design was not intended to use navigability to indicate "efficient access is desired in this direction" while also allowing some sort of less efficient access in the non-navigable direction. Rather navigability was intended to indicate what information is available from what context in order to model intended semantics and manage coupling. OCL does not follow these conventions, allowing one to ignore navigability (other then perhaps for efficiency purposes). This is inconsistent with the functional and non-functional objectives that drove the definition of EMOF. Now one could suggest those design goals were misguided, or have become out of date due to change in navigability in UML (which did not effect Basic), or changing requirements. If the issue is changing requirements EMOF, then I would think the EMF community would be driving this, so I would defer to that community for further comment. Ed? Kenn? Others? On the use of tags for the new property - this could have significant effect on EMOF and EMF. The effect on EMOF is that now tags are introduced into the EMOF structure model to provide "convenience" for some OCL operations. EMOF doen't include OCL, so that seems somewhat artificial. Additional semantics have to be added to EMOF to specify how this tag value is set when properties and opposites change, and how it is reflected. OCL would have to be extended to understand the special case where aClass.aProperty was referring to a tag rather than an actual property. Now any updates to properties and opposites would have to make the appropriate updates to the tag value in EMF. This could raise the very issues leaving associations out of EMF was intended to avoid. Again, I defer to the EMF experts. So how do we move forward: 1. We understand exactly the use cases driving this change - not in email exchanges but on a Wiki where they can be adequately captured, contributed to and reviewed 2. We explore options for supporting the use cases including making EMOF "associations" navigable in both directions (through property opposite) in cases where this is needed in the model, using the mediator pattern for cases were property opposite is not adequate, using convenience tags (that might be optional), merging CMOF associations to EMOF, etc. 3. We pick one or two of the explored options and write them up so they can be properly communicated, understood, reviewed, and evaluated. Any change to EMOF should get significant scrutiny since it results in changes to EMF which effects a lot of existing products. 4. Decide on an approach and include it in a ballot, assuming the approach is applicable to an RTF. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: Jim Amsden/Raleigh/IBM@IBMUS, "'mof2core-rtf@omg.org'" Date: 04/30/2010 04:00 AM Subject: RE: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Hi Jim, nobody doubts that a useful class of apps can be built without the tag proposed. Nobody doubts either that there are other ways to solve the problem. Neither seems to exist doubt among many of us that there are serious use cases for OCL-specified expressions that want to express something about a property that doesn't have an opposite, and in some of these cases the expression can compute only the referenced element e1 and then needs to make a statement about those elements referencing e1 using a certain property. Now you may argue that you can always write A.allInstances()->select(a | a.p = e1) to get a hold of all elements of type A or A's subtypes that reference e1 through property p. And yes, it is certainly possible for an OCL infrastructure to recognize such constructs and---given some querying infrastructure---provide performance-improved ways to evaluate such expressions. What we're discussing here is a convenience that would allow us to write an OCL expression e1.r instead, where "r" is the name provided in the tag under discussion on property p which then would lead to the creation of an OCL AST element of the class OppositePropertyCallExp requested by issue 15175 (http://www.omg.org/issues/issue15175.txt) where the OppositePropertyCallExp references the property p. This approach according to a PoC we have implemented at SAP significantly simplifies the OCL environment's job and allows OCL writers to use the very intuitive unchanged concrete syntax for navigation expressions. It simplifies the OCL evaluation environment's life because it doesn't have to do deep inspection and transformation of the OCL AST to recognize and efficiently execute an allInstances()->select(...) construct where the select's body compares exactly one property. In the sequel, with an OppositePropertyCallExp it becomes much simpler to trace back a change of the p property to the contexts on which the using OCL expression may have changed its value. This is much harder to accomplish for the allInstances()->select(...) approach. The tag proposed is already the light-weight and therefore EM(O)F spirit-compliant alternative to introducing a more heavyweight construct which we also PoC-ed, namely the possibility to let a Property (EReference) own its opposite Property (EReference). While this also works, it raises issues regarding enforcing the opposite property's multiplicity constraints and is more of a backward compatibility issue because it breaks code that so far assumes that an EM(O)F Property / EReference is always owned by a(n) (E)Class. The only simplication that a Property-owned opposite would have facilitated would have been that the OCL abstract syntax / metamodel would not need to change because the existing PropertyCallExp could have been used to refer to the property-owned opposite. But in addition to the difficult multiplicity enforcement, Ed Merks already commented that it would shift the cost away from where the benefit is (from OCL to EMOF/Ecore). Your comment regarding the use of CMOF does not seem pragmatic to me. We're trying to make good use of EMF as an almost compliant EMOF implementation. We can live with many of its limitations. The lack of true associations can be circumvented by introducing what EMF needs anyhow, namely good query infrastructure (see also the query2 EMF contribution SAP made which is in incubation status right now). OCL works great on EMF. The last significant stumbling block is this major inconvenience when it comes to OCL-constraining EM(O)F models. If getting this resolved in a standard way only takes the agreement on a tag, I have a hard time understanding the objections. The CMOF alternative would mean we can't use EMF which means we'd have to write or buy a completely different model management infrastructure which means we can't use a lot of the existing Eclipse tool sets around EMF which also means that contributions that SAP due to a finally relaxed open source policy will be making in the future would not be to the benefit of the community. Besides, beyond associations which certainly are the greatest benefit of CMOF over EMOF, CMOF introduces many things that we don't feel we need for our tasks. Best, -- Axel From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, April 30, 2010 4:11 AM To: 'mof2core-rtf@omg.org' Subject: Re: Discussion on MOF2 Core Issue 12800 I do object to this. EMF has been built on EMOF concepts for years. We have developed a large number of transforms that have not needed this extra property. If associations are needed by a tool, then it should use CMOF, not EMOF. If a modeler needs something like an association in EMOF/EMF, then they can use the mediator pattern reasonably effectively. I also do not believe EMOF should specify or require any tags to support structural modeling. Tags were for extensibility, not fundamental metamodel concepts. Such an addition would need to have compelling use cases that cannot be addressed by other means. The concept of association was explicitly kept out of EMOF. I do not believe we should graft something back in using tags to simulate association ends. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: "'pete.rivett@adaptive.com'" , "'mof2core-rtf@omg.org'" , Jim Amsden/Raleigh/IBM@IBMUS Cc: "'ed@willink.me.uk'" Date: 04/29/2010 06:21 PM Subject: Re: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Pete, thanks for kicking this off. At some other place Ed already proposed "Property.oppositeRoleName" as tag name which seemed to make sense to me. Jim, do you still have general objections to introducing such a standard tag? If so, look at OCL issue 15175 where with a naming tag for the non-existing opposite we can save a concrete syntax extension for OCL and make navigation in these directions more intuitive. Best, -- Axel ------------------ Sent from BB -------------------------------------------------------------------------------- From: Pete Rivett To: mof2core-rtf@omg.org ; Jim Amsden Cc: Ed Willink ; Uhl, Axel Sent: Thu Apr 29 23:32:25 2010 Subject: Discussion on MOF2 Core Issue 12800 Below is the issue and my original response: I removed it from the ballot since Jim had raised a comment and I realized the proposal was not complete (e.g. did not define the name of the Tag) so it needed discussion. This email is intended to start such a discussion. I.m going on vacation for a week so hopefully you.ll all have it sorted by the time I get back J BTW Ed, EMOF (as well as CMOF) does include Tags . see Figure 122.1 in formal/06-06-01 where you can see that EMOF merges in the Extension package which defines Tag. Jim wrote: EMOF does not have associations. Rather it uses a notation option for properties that have non-primitive types that uses CMOF association notation. So there are no member or owned ends of the association. Rather QVT should treat these as properties which not non-navigable associations, and there would be no need to a name for the un-named end. Issue 12800: Capturing Unnavigable Opposite Property Role Names (mof2core-rtf) Click here for this issue's archive. Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@willink.me.uk) Nature: Uncategorized Issue Severity: Summary: EMOF does not support identification of the opposite role name for a non-navigable association, however QVT requires such role names to be used. OCL defines an implicit role name, but UML graphics supports arbitrary names. At the EclipseCon OMG symposium in February, it seemed appropriate to resolve the limitation in the following way. An opposite role name may be denoted by a Comment Comment with the inner Comment defining a formal function for the outer Comment. Thus in: "backward" is defined as the oppositeRoleName of "forward". This practice makes the missing information available, and avoids any changes to the MOF meta-model and so avoids introducing any additional Property instances that might bloat existing usage. It would be helpful if a future MOF version, or an addendum to existing versions, endorse this practice. An equivalent Ecore EAnnotation and cross-conversion was introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede). Resolution: The use of .non-navigable. is out-dated: the issue is where Property::opposite is empty and there is nothing to hang the name on. This would seem better addressed by the use of a MOF Tag rather than two nested Comments. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 tel: +1 949 330 7677, cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=V1jd8xnWsiIi0nThPT2Rqgu0wT+tdGHcsRHcsK07YwQ=; b=O6KMUYf8UzUmVULlxQHAePwKfa7tPem3X5A6j8oJzoCZ4/5WAd3A/QuA6JDgRFts9B 0oqHSyYMpzHOIBAcHQo4M7sd+2ZiVXd8C9bxKVTyz2LLwMpTRhapZjanbCAiWSblJ+jX ibELuaKv0GkuXedybDEBr3BWpe/k0OoontR9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=FvmFXS/PmHjvg7Lxt3WBNLf6qA1+q7OUrD+vgbe3xNwFXYic6n8BzRkJnBKuqTRUR1 jhp0D8jrHN/dXO6T2jtj30Eluthx3NOv86Y1c4uWkRaON1Qrkul8IyjvlkAWbl7RziwX Nood1RDxDHo2jgkLwO/NlpU5o716kaN83ZMTM= Date: Tue, 04 May 2010 13:23:03 +0200 From: Ed Merks User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) To: "Uhl, Axel" CC: Jim Amsden , Juergen Boldt , "kenn.hussey@gmail.com" , "'mof2core-rtf@omg.org'" Subject: Re: Discussion on MOF2 Core Issue 12800 Axel, With respect option 2: - introduce tag: class A { B b {org.omg.emof.oppositeRoleName="a"}; }. Again, let x be an instance of class B. OCL can now write x.a Given only the knowledge that x is of type B it will need to be possible to find all references b of all classes A to determine those b's that allow a B instance and then to look for a tag on each such reference. Presumably it will be necessary to enforce that tag to be unique across all possibles b's. Perhaps some other notation that's less ambiguous and requires less searching of all meta models would make more sense, i.e., one that directly indicates A's b reference's opposite, and is effectively more like a short hand notation for option 1. Regards, Ed Uhl, Axel wrote: Hi all, for clarification and towards Jim's request to list options, here goes a list of options I see, together with some reasoning. This may be included in the Wiki once we have it. An association is way more than what is being asked here. It's the combination of multiplicity and navigability constraints as well as names for both ends (in case we're talking about CMOF where the number of ends is limited to two). We're only asking the name, and that only as an annotation, and only in order to be able to conveniently phrase the query that we would also be able to express otherwise. So we're not really adding new capabilities to EMOF nor EMF. The real new capabilities are the availability of a query facility such as SAP is trying to contribute to EMF in the form of query2. The question is only how we make this available in the best possible way. Options: - no change to EMOF/EMF, no tag. class A { B b; }. Let x be an instance of class B. OCL will have to write A.allInstances()->select(i | i.b = x) For other query / expression languages this would work similarly. An OCL evaluator could try to identify such constructs and map them to a query facility. This is fairly complicated, and the expressions are clumsy to write. - introduce tag: class A { B b {org.omg.emof.oppositeRoleName="a"}; }. Again, let x be an instance of class B. OCL can now write x.a which parses into an OppositePropertyCallExp with A.b being the referred property. The OCL parser/analyzer matches "a" against the tag and then binds the opposite property call to the forward property A.b. This is convenient to write and doesn't require the declaration of an opposite, in particular not necessitating storage on the B side and not impacting B's XMI serialization and class contract. - introduce opposite: class A { B b opposite B.a; }; class B { A a opposite A.b; }; Again, x is an element of class B. OCL again can write x.a which parses as a PropertyCallExp referring to the B.a property. Establishing a reference between an A and a B element residing in two separate resources changes both resources. The resources can't live in different components because it would lead to cyclic dependencies between these components. B's serialization is changed by the existence of the B.a property, as is B's contract which includes a getter and a setter for B.a. As Jim pointed out, this is often not possible or not desirable. Therefore, this approach is impractical for most purposes. - introduce associations in EMOF: class A { B b exposes A2B.b; }; class B {}; association A2B { A a; B b; }. OCL as above. The association could own those properties that are not owned by a class, in this case the A2B.a property. The properties would be mutual opposites. We'd need a new metaclass in EMOF (and subsequently Ecore) for the association. Associations would probably be owned by a package. The problems with this type of association in the light of the EMOF/EMF spirit have been pointed out by Jim and Ed Merks. It's often impractical and undesirable to enforce the multiplicity constraints on the A a property. Ordering can't reasonably be implemented without storage. From a compatibility point of view, one problem with this type of approach is that a Property / EReference can no longer only be owned by a Class/EClass but also by an association. This will break some code here and there where people relied on the Class/Property composition to be the only composition for Property. - introduce opposite property as a Property/EReference element owned by the forward Property/EReference. This leads to the same OCL as above, using a PropertyCallExp referring to the nested Property/EReference. No OppositePropertyCallExp would be required. While this would not have to introduce a new class to EMOF/Ecore, it may go against the conformance with CMOF where a property is either owned by a class or by an association but not by another property. The same arguments regarding enforcing the multiplicity constraints apply as for the introduction of an Association metaclass described above. Also, the same argument regarding backward compatibiliy apply because then a Property/EReference still no longer could be owned only by a Class/EClass element which breaks the same code as described above. With these options, for reasons of backward compatiblity, amount of changes and EMOF/CMOF conformance, the tag-based approach seems best. Initially, we prototyped a solution based on nesting a Property/EReference inside another Property/EReference, making them opposites (last option described above). While this also worked and required fewer changes to OCL (in particular no OppositePropertyCallExp), Ed Merks made two points that I find very valid. He said that the cost should be where the benefit is (that's OCL in our case, so it may be ok to require a new AST class for OCL if in OCL we get the main benefit); additionally, he pointed me at the issues with enforcing the multiplicity characteristics of the opposite property, in particular orderedness. Looking forward to seeing other options and the discussion about those. Best, -- Axel From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, May 04, 2010 12:06 AM To: Uhl, Axel; Juergen Boldt Cc: ed.merks@gmail.com; kenn.hussey@gmail.com; 'mof2core-rtf@omg.org' Subject: RE: Discussion on MOF2 Core Issue 12800 Axel, I'm having trouble understanding the motivation for the approach. I understand there will be EMOF properties without opposites. I do not understand why a tag is required to provide the opposite when one wasn't intended. I realize this limits what is accessible at runtime from the object, and limits OCL queries - but that seems to be the point. I still think we should do the following: 1. We understand exactly the use cases driving this change: captured, contributed to and reviewed 2. We explore options for supporting the use cases including making EMOF "associations" navigable in both directions (through property opposite) in cases where this is needed in the model, using the mediator pattern for cases were property opposite is not adequate, using convenience tags (that might be optional), merging CMOF associations to EMOF, etc. 3. We pick one or two of the explored options and write them up so they can be properly communicated, understood, reviewed, and evaluated. Any change to EMOF should get significant scrutiny since it results in changes to EMF which effects a lot of existing products. 4. Decide on an approach and include it in a ballot, assuming the approach is applicable to an RTF. Juergen, Can you setup a MOF Wiki, including at least the recipients of this email, and anyone else on the MOF RTF? Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: Jim Amsden/Raleigh/IBM@IBMUS, "'mof2core-rtf@omg.org'" Cc: "ed.merks@gmail.com" , "kenn.hussey@gmail.com" Date: 05/03/2010 12:25 PM Subject: RE: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Hi Jim, I see that EMOF makes explicit where things are stored. I fully agree that the bidirectional coupling of model components needs to be avoided; more so, BTW, than the bidirectional coupling of metamodel components, I think. By this token, opposite properties are evil because EMOF decided to tie the presence of properties to storage and serialization aspects, if I understand this correctly, because properties can only be owned by classes, as there is no association to hold them and hide them from the opposite class's contract. In addition to that I see that queries over a well-defined scope of EMOF models are very useful. Use cases include model validation, metrics and tool functionality such as cross-referencers for models ("show referenced by"). Some queries are semantically equivalent to traversing references backwards. We discussed the alternative for OCL that uses allInstances()->select(...) already. With CMOF there's a powerful way to separate storage/serialization aspects from the specification of multiplicity constraints and the provisioning of a name for the opposite end. Multiplicity constraints for the opposite direction can easily be added by using OCL constraints for EMOF models that don't use opposites. The only remaining problem is the lack of a convenient name so OCL or query languages can use it as a shorthand for expressions/queries that otherwise are really clumsy and lengthy to write. I'm not convinced that this breaks with the functional / non-functional objectives driving the EMOF design because the same functionality can be expressed with a query mechanism, only that the intent gets harder to see and maintain. On the use of tags for the new property - this could have significant effect on EMOF and EMF. The effect on EMOF is that now tags are introduced into the EMOF structure model to provide "convenience" for some OCL operations. EMOF doen't include OCL, so that seems somewhat artificial. Additional semantics have to be added to EMOF to specify how this tag value is set when properties and opposites change, and how it is reflected. OCL would have to be extended to understand the special case where aClass.aProperty was referring to a tag rather than an actual property. If we choose an OCL-like tag name instead of an EMOF tag name, I'm also happy with it, although I would presume that there may be other use cases for, e.g., other query languages that may also be interested in this piece of metadata. The question here is just whether or not we forsee other future uses of such a tag that go beyond OCL. Regarding your request for additional semantics, I suggest we define a constraint that says this tag is only permissible if the property tagged by it does not have an opposite defined. This in particular covers the CMOF case as well, so this remains something useful in the EMOF world only. I would additionally find it useful to introduce an operation on Property that returns the name of the other "end" which encapsulates the meaning of this tag and resorts to the real opposite if defined. This, of course, only is an option if the tag is defined as an EMOF and not as an OCL tag. I don't think that semantics are needed for propagating any changes of properties and opposites, based on what I wrote above regarding constraining the use of the tag. And yes, OCL would need to be extended, as described earlier in this thread, using an additional AST class OppositePropertyCallExp that is sibling to PropertyCallExp and refers to the "real" property. This is an OCL change, not an EMOF change, obviously. When you mention a Wiki, could you set one up? I had thought that an OMG-hosted archive of this e-mail exchange may be sufficient for everyone to follow, though. If nobody else volunteers, I can draft a piece describing the relationships between the tag proposed and the respective OCL extension around OppositePropertyCallExp if that's considered helpful. Best, -- Axel From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, April 30, 2010 4:08 PM To: 'mof2core-rtf@omg.org' Cc: ed.merks@gmail.com; kenn.hussey@gmail.com Subject: RE: Discussion on MOF2 Core Issue 12800 Axel, I understand these arguments. However, EMOF (and EMF) were specifically designed to enable efficient specification and implementation of navigability. The design was not intended to use navigability to indicate "efficient access is desired in this direction" while also allowing some sort of less efficient access in the non-navigable direction. Rather navigability was intended to indicate what information is available from what context in order to model intended semantics and manage coupling. OCL does not follow these conventions, allowing one to ignore navigability (other then perhaps for efficiency purposes). This is inconsistent with the functional and non-functional objectives that drove the definition of EMOF. Now one could suggest those design goals were misguided, or have become out of date due to change in navigability in UML (which did not effect Basic), or changing requirements. If the issue is changing requirements EMOF, then I would think the EMF community would be driving this, so I would defer to that community for further comment. Ed? Kenn? Others? On the use of tags for the new property - this could have significant effect on EMOF and EMF. The effect on EMOF is that now tags are introduced into the EMOF structure model to provide "convenience" for some OCL operations. EMOF doen't include OCL, so that seems somewhat artificial. Additional semantics have to be added to EMOF to specify how this tag value is set when properties and opposites change, and how it is reflected. OCL would have to be extended to understand the special case where aClass.aProperty was referring to a tag rather than an actual property. Now any updates to properties and opposites would have to make the appropriate updates to the tag value in EMF. This could raise the very issues leaving associations out of EMF was intended to avoid. Again, I defer to the EMF experts. So how do we move forward: 1. We understand exactly the use cases driving this change - not in email exchanges but on a Wiki where they can be adequately captured, contributed to and reviewed 2. We explore options for supporting the use cases including making EMOF "associations" navigable in both directions (through property opposite) in cases where this is needed in the model, using the mediator pattern for cases were property opposite is not adequate, using convenience tags (that might be optional), merging CMOF associations to EMOF, etc. 3. We pick one or two of the explored options and write them up so they can be properly communicated, understood, reviewed, and evaluated. Any change to EMOF should get significant scrutiny since it results in changes to EMF which effects a lot of existing products. 4. Decide on an approach and include it in a ballot, assuming the approach is applicable to an RTF. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: Jim Amsden/Raleigh/IBM@IBMUS, "'mof2core-rtf@omg.org'" Date: 04/30/2010 04:00 AM Subject: RE: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Hi Jim, nobody doubts that a useful class of apps can be built without the tag proposed. Nobody doubts either that there are other ways to solve the problem. Neither seems to exist doubt among many of us that there are serious use cases for OCL-specified expressions that want to express something about a property that doesn't have an opposite, and in some of these cases the expression can compute only the referenced element e1 and then needs to make a statement about those elements referencing e1 using a certain property. Now you may argue that you can always write A.allInstances()->select(a | a.p = e1) to get a hold of all elements of type A or A's subtypes that reference e1 through property p. And yes, it is certainly possible for an OCL infrastructure to recognize such constructs and---given some querying infrastructure---provide performance-improved ways to evaluate such expressions. What we're discussing here is a convenience that would allow us to write an OCL expression e1.r instead, where "r" is the name provided in the tag under discussion on property p which then would lead to the creation of an OCL AST element of the class OppositePropertyCallExp requested by issue 15175 (http://www.omg.org/issues/issue15175.txt) where the OppositePropertyCallExp references the property p. This approach according to a PoC we have implemented at SAP significantly simplifies the OCL environment's job and allows OCL writers to use the very intuitive unchanged concrete syntax for navigation expressions. It simplifies the OCL evaluation environment's life because it doesn't have to do deep inspection and transformation of the OCL AST to recognize and efficiently execute an allInstances()->select(...) construct where the select's body compares exactly one property. In the sequel, with an OppositePropertyCallExp it becomes much simpler to trace back a change of the p property to the contexts on which the using OCL expression may have changed its value. This is much harder to accomplish for the allInstances()->select(...) approach. The tag proposed is already the light-weight and therefore EM(O)F spirit-compliant alternative to introducing a more heavyweight construct which we also PoC-ed, namely the possibility to let a Property (EReference) own its opposite Property (EReference). While this also works, it raises issues regarding enforcing the opposite property's multiplicity constraints and is more of a backward compatibility issue because it breaks code that so far assumes that an EM(O)F Property / EReference is always owned by a(n) (E)Class. The only simplication that a Property-owned opposite would have facilitated would have been that the OCL abstract syntax / metamodel would not need to change because the existing PropertyCallExp could have been used to refer to the property-owned opposite. But in addition to the difficult multiplicity enforcement, Ed Merks already commented that it would shift the cost away from where the benefit is (from OCL to EMOF/Ecore). Your comment regarding the use of CMOF does not seem pragmatic to me. We're trying to make good use of EMF as an almost compliant EMOF implementation. We can live with many of its limitations. The lack of true associations can be circumvented by introducing what EMF needs anyhow, namely good query infrastructure (see also the query2 EMF contribution SAP made which is in incubation status right now). OCL works great on EMF. The last significant stumbling block is this major inconvenience when it comes to OCL-constraining EM(O)F models. If getting this resolved in a standard way only takes the agreement on a tag, I have a hard time understanding the objections. The CMOF alternative would mean we can't use EMF which means we'd have to write or buy a completely different model management infrastructure which means we can't use a lot of the existing Eclipse tool sets around EMF which also means that contributions that SAP due to a finally relaxed open source policy will be making in the future would not be to the benefit of the community. Besides, beyond associations which certainly are the greatest benefit of CMOF over EMOF, CMOF introduces many things that we don't feel we need for our tasks. Best, -- Axel From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, April 30, 2010 4:11 AM To: 'mof2core-rtf@omg.org' Subject: Re: Discussion on MOF2 Core Issue 12800 I do object to this. EMF has been built on EMOF concepts for years. We have developed a large number of transforms that have not needed this extra property. If associations are needed by a tool, then it should use CMOF, not EMOF. If a modeler needs something like an association in EMOF/EMF, then they can use the mediator pattern reasonably effectively. I also do not believe EMOF should specify or require any tags to support structural modeling. Tags were for extensibility, not fundamental metamodel concepts. Such an addition would need to have compelling use cases that cannot be addressed by other means. The concept of association was explicitly kept out of EMOF. I do not believe we should graft something back in using tags to simulate association ends. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: "'pete.rivett@adaptive.com'" , "'mof2core-rtf@omg.org'" , Jim Amsden/Raleigh/IBM@IBMUS Cc: "'ed@willink.me.uk'" Date: 04/29/2010 06:21 PM Subject: Re: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Pete, thanks for kicking this off. At some other place Ed already proposed "Property.oppositeRoleName" as tag name which seemed to make sense to me. Jim, do you still have general objections to introducing such a standard tag? If so, look at OCL issue 15175 where with a naming tag for the non-existing opposite we can save a concrete syntax extension for OCL and make navigation in these directions more intuitive. Best, -- Axel ------------------ Sent from BB -------------------------------------------------------------------------------- From: Pete Rivett To: mof2core-rtf@omg.org ; Jim Amsden Cc: Ed Willink ; Uhl, Axel Sent: Thu Apr 29 23:32:25 2010 Subject: Discussion on MOF2 Core Issue 12800 Below is the issue and my original response: I removed it from the ballot since Jim had raised a comment and I realized the proposal was not complete (e.g. did not define the name of the Tag) so it needed discussion. This email is intended to start such a discussion. I.m going on vacation for a week so hopefully you.ll all have it sorted by the time I get back J BTW Ed, EMOF (as well as CMOF) does include Tags . see Figure 12.1 in formal/06-06-01 where you can see that EMOF merges in the Extension package which defines Tag. Jim wrote: EMOF does not have associations. Rather it uses a notation option for properties that have non-primitive types that uses CMOF association notation. So there are no member or owned ends of the association. Rather QVT should treat these as properties which not non-navigable associations, and there would be no need to a name for the un-named end. Issue 12800: Capturing Unnavigable Opposite Property Role Names (mof2core-rtf) Click here for this issue's archive. Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@willink.me.uk) Nature: Uncategorized Issue Severity: Summary: EMOF does not support identification of the opposite role name for a non-navigable association, however QVT requires such role names to be used. OCL defines an implicit role name, but UML graphics supports arbitrary names. At the EclipseCon OMG symposium in February, it seemed appropriate to resolve the limitation in the following way. An opposite role name may be denoted by a Comment Comment with the inner Comment defining a formal function for the outer Comment. Thus in: "backward" is defined as the oppositeRoleName of "forward". This practice makes the missing information available, and avoids any changes to the MOF meta-model and so avoids introducing any additional Property instances that might bloat existing usage. It would be helpful if a future MOF version, or an addendum to existing versions, endorse this practice. An equivalent Ecore EAnnotation and cross-conversion was introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede). Resolution: The use of .non-navigable. is out-dated: the issue is where Property::opposite is empty and there is nothing to hang the name on. This would seem better addressed by the use of a MOF Tag rather than two nested Comments. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 tel: +1 949 330 7677, cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp To: "Uhl, Axel" Cc: "'ed.merks@gmail.com'" , "'juergen@omg.org'" , "'kenn.hussey@gmail.com'" , "'mof2core-rtf@omg.org'" Subject: Re: Discussion on MOF2 Core Issue 12800 X-KeepSent: 0791C70E:6B4D2738-85257719:00437ABC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 From: Jim Amsden Date: Tue, 4 May 2010 08:28:36 -0600 X-MIMETrack: Serialize by Router on D03MC007/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 05/04/2010 08:28:38, Serialize complete at 05/04/2010 08:28:38 I don't follow. What's the semantic difference between the opposite and the tag? I realize multiplicity isn't supported by the tag - but it seems the point of navigability was to prevent the references the tag is enabling. The use cases I'm looking for is to motivate why is this access needed, not what is it. And in those cases where it is needed, that opposite can't be used to support the need explicitly. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: Jim Amsden/Raleigh/IBM@IBMUS, "'juergen@omg.org'" Cc: "'ed.merks@gmail.com'" , "'kenn.hussey@gmail.com'" , "'mof2core-rtf@omg.org'" Date: 05/04/2010 02:57 AM Subject: Re: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Jim, you mentioned the most important use case for not having true opposite properties yourself. It strongly couples the resulting resources and may require updates to two resources for what should be an atomic change, thus incurring its own class of problems (diff, merge for example). OCL navigability (and for that matter probably also queriability with other query languages) should IMO be kept independent of the question whether or not and where the reference is stored. Yes, CMOF has all that, and it's as easy as adding an annotation to an EMOF Property to get to a similar level of convenience in EMOF. The annotation doesn't---as you're suggesting---mean that an opposite was intended. The opposite would add much more than named navigability which, as you observed, is often not desired. Best, -- Axel ------------------ Sent from BB -------------------------------------------------------------------------------- From: Jim Amsden To: Uhl, Axel; Juergen Boldt Cc: ed.merks@gmail.com ; kenn.hussey@gmail.com ; 'mof2core-rtf@omg.org' Sent: Tue May 04 00:05:52 2010 Subject: RE: Discussion on MOF2 Core Issue 12800 Axel, I'm having trouble understanding the motivation for the approach. I understand there will be EMOF properties without opposites. I do not understand why a tag is required to provide the opposite when one wasn't intended. I realize this limits what is accessible at runtime from the object, and limits OCL queries - but that seems to be the point. I still think we should do the following: 1. We understand exactly the use cases driving this change: captured, contributed to and reviewed 2. We explore options for supporting the use cases including making EMOF "associations" navigable in both directions (through property opposite) in cases where this is needed in the model, using the mediator pattern for cases were property opposite is not adequate, using convenience tags (that might be optional), merging CMOF associations to EMOF, etc. 3. We pick one or two of the explored options and write them up so they can be properly communicated, understood, reviewed, and evaluated. Any change to EMOF should get significant scrutiny since it results in changes to EMF which effects a lot of existing products. 4. Decide on an approach and include it in a ballot, assuming the approach is applicable to an RTF. Juergen, Can you setup a MOF Wiki, including at least the recipients of this email, and anyone else on the MOF RTF? Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: Jim Amsden/Raleigh/IBM@IBMUS, "'mof2core-rtf@omg.org'" Cc: "ed.merks@gmail.com" , "kenn.hussey@gmail.com" Date: 05/03/2010 12:25 PM Subject: RE: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Hi Jim, I see that EMOF makes explicit where things are stored. I fully agree that the bidirectional coupling of model components needs to be avoided; more so, BTW, than the bidirectional coupling of metamodel components, I think. By this token, opposite properties are evil because EMOF decided to tie the presence of properties to storage and serialization aspects, if I understand this correctly, because properties can only be owned by classes, as there is no association to hold them and hide them from the opposite class's contract. In addition to that I see that queries over a well-defined scope of EMOF models are very useful. Use cases include model validation, metrics and tool functionality such as cross-referencers for models ("show referenced by"). Some queries are semantically equivalent to traversing references backwards. We discussed the alternative for OCL that uses allInstances()->select(...) already. With CMOF there's a powerful way to separate storage/serialization aspects from the specification of multiplicity constraints and the provisioning of a name for the opposite end. Multiplicity constraints for the opposite direction can easily be added by using OCL constraints for EMOF models that don't use opposites. The only remaining problem is the lack of a convenient name so OCL or query languages can use it as a shorthand for expressions/queries that otherwise are really clumsy and lengthy to write. I'm not convinced that this breaks with the functional / non-functional objectives driving the EMOF design because the same functionality can be expressed with a query mechanism, only that the intent gets harder to see and maintain. On the use of tags for the new property - this could have significant effect on EMOF and EMF. The effect on EMOF is that now tags are introduced into the EMOF structure model to provide "convenience" for some OCL operations. EMOF doen't include OCL, so that seems somewhat artificial. Additional semantics have to be added to EMOF to specify how this tag value is set when properties and opposites change, and how it is reflected. OCL would have to be extended to understand the special case where aClass.aProperty was referring to a tag rather than an actual property. If we choose an OCL-like tag name instead of an EMOF tag name, I'm also happy with it, although I would presume that there may be other use cases for, e.g., other query languages that may also be interested in this piece of metadata. The question here is just whether or not we forsee other future uses of such a tag that go beyond OCL. Regarding your request for additional semantics, I suggest we define a constraint that says this tag is only permissible if the property tagged by it does not have an opposite defined. This in particular covers the CMOF case as well, so this remains something useful in the EMOF world only. I would additionally find it useful to introduce an operation on Property that returns the name of the other "end" which encapsulates the meaning of this tag and resorts to the real opposite if defined. This, of course, only is an option if the tag is defined as an EMOF and not as an OCL tag. I don't think that semantics are needed for propagating any changes of properties and opposites, based on what I wrote above regarding constraining the use of the tag. And yes, OCL would need to be extended, as described earlier in this thread, using an additional AST class OppositePropertyCallExp that is sibling to PropertyCallExp and refers to the "real" property. This is an OCL change, not an EMOF change, obviously. When you mention a Wiki, could you set one up? I had thought that an OMG-hosted archive of this e-mail exchange may be sufficient for everyone to follow, though. If nobody else volunteers, I can draft a piece describing the relationships between the tag proposed and the respective OCL extension around OppositePropertyCallExp if that's considered helpful. Best, -- Axel From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, April 30, 2010 4:08 PM To: 'mof2core-rtf@omg.org' Cc: ed.merks@gmail.com; kenn.hussey@gmail.com Subject: RE: Discussion on MOF2 Core Issue 12800 Axel, I understand these arguments. However, EMOF (and EMF) were specifically designed to enable efficient specification and implementation of navigability. The design was not intended to use navigability to indicate "efficient access is desired in this direction" while also allowing some sort of less efficient access in the non-navigable direction. Rather navigability was intended to indicate what information is available from what context in order to model intended semantics and manage coupling. OCL does not follow these conventions, allowing one to ignore navigability (other then perhaps for efficiency purposes). This is inconsistent with the functional and non-functional objectives that drove the definition of EMOF. Now one could suggest those design goals were misguided, or have become out of date due to change in navigability in UML (which did not effect Basic), or changing requirements. If the issue is changing requirements EMOF, then I would think the EMF community would be driving this, so I would defer to that community for further comment. Ed? Kenn? Others? On the use of tags for the new property - this could have significant effect on EMOF and EMF. The effect on EMOF is that now tags are introduced into the EMOF structure model to provide "convenience" for some OCL operations. EMOF doen't include OCL, so that seems somewhat artificial. Additional semantics have to be added to EMOF to specify how this tag value is set when properties and opposites change, and how it is reflected. OCL would have to be extended to understand the special case where aClass.aProperty was referring to a tag rather than an actual property. Now any updates to properties and opposites would have to make the appropriate updates to the tag value in EMF. This could raise the very issues leaving associations out of EMF was intended to avoid. Again, I defer to the EMF experts. So how do we move forward: 1. We understand exactly the use cases driving this change - not in email exchanges but on a Wiki where they can be adequately captured, contributed to and reviewed 2. We explore options for supporting the use cases including making EMOF "associations" navigable in both directions (through property opposite) in cases where this is needed in the model, using the mediator pattern for cases were property opposite is not adequate, using convenience tags (that might be optional), merging CMOF associations to EMOF, etc. 3. We pick one or two of the explored options and write them up so they can be properly communicated, understood, reviewed, and evaluated. Any change to EMOF should get significant scrutiny since it results in changes to EMF which effects a lot of existing products. 4. Decide on an approach and include it in a ballot, assuming the approach is applicable to an RTF. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: Jim Amsden/Raleigh/IBM@IBMUS, "'mof2core-rtf@omg.org'" Date: 04/30/2010 04:00 AM Subject: RE: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Hi Jim, nobody doubts that a useful class of apps can be built without the tag proposed. Nobody doubts either that there are other ways to solve the problem. Neither seems to exist doubt among many of us that there are serious use cases for OCL-specified expressions that want to express something about a property that doesn't have an opposite, and in some of these cases the expression can compute only the referenced element e1 and then needs to make a statement about those elements referencing e1 using a certain property. Now you may argue that you can always write A.allInstances()->select(a | a.p = e1) to get a hold of all elements of type A or A's subtypes that reference e1 through property p. And yes, it is certainly possible for an OCL infrastructure to recognize such constructs and---given some querying infrastructure---provide performance-improved ways to evaluate such expressions. What we're discussing here is a convenience that would allow us to write an OCL expression e1.r instead, where "r" is the name provided in the tag under discussion on property p which then would lead to the creation of an OCL AST element of the class OppositePropertyCallExp requested by issue 15175 (http://www.omg.org/issues/issue15175.txt) where the OppositePropertyCallExp references the property p. This approach according to a PoC we have implemented at SAP significantly simplifies the OCL environment's job and allows OCL writers to use the very intuitive unchanged concrete syntax for navigation expressions. It simplifies the OCL evaluation environment's life because it doesn't have to do deep inspection and transformation of the OCL AST to recognize and efficiently execute an allInstances()->select(...) construct where the select's body compares exactly one property. In the sequel, with an OppositePropertyCallExp it becomes much simpler to trace back a change of the p property to the contexts on which the using OCL expression may have changed its value. This is much harder to accomplish for the allInstances()->select(...) approach. The tag proposed is already the light-weight and therefore EM(O)F spirit-compliant alternative to introducing a more heavyweight construct which we also PoC-ed, namely the possibility to let a Property (EReference) own its opposite Property (EReference). While this also works, it raises issues regarding enforcing the opposite property's multiplicity constraints and is more of a backward compatibility issue because it breaks code that so far assumes that an EM(O)F Property / EReference is always owned by a(n) (E)Class. The only simplication that a Property-owned opposite would have facilitated would have been that the OCL abstract syntax / metamodel would not need to change because the existing PropertyCallExp could have been used to refer to the property-owned opposite. But in addition to the difficult multiplicity enforcement, Ed Merks already commented that it would shift the cost away from where the benefit is (from OCL to EMOF/Ecore). Your comment regarding the use of CMOF does not seem pragmatic to me. We're trying to make good use of EMF as an almost compliant EMOF implementation. We can live with many of its limitations. The lack of true associations can be circumvented by introducing what EMF needs anyhow, namely good query infrastructure (see also the query2 EMF contribution SAP made which is in incubation status right now). OCL works great on EMF. The last significant stumbling block is this major inconvenience when it comes to OCL-constraining EM(O)F models. If getting this resolved in a standard way only takes the agreement on a tag, I have a hard time understanding the objections. The CMOF alternative would mean we can't use EMF which means we'd have to write or buy a completely different model management infrastructure which means we can't use a lot of the existing Eclipse tool sets around EMF which also means that contributions that SAP due to a finally relaxed open source policy will be making in the future would not be to the benefit of the community. Besides, beyond associations which certainly are the greatest benefit of CMOF over EMOF, CMOF introduces many things that we don't feel we need for our tasks. Best, -- Axel From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, April 30, 2010 4:11 AM To: 'mof2core-rtf@omg.org' Subject: Re: Discussion on MOF2 Core Issue 12800 I do object to this. EMF has been built on EMOF concepts for years. We have developed a large number of transforms that have not needed this extra property. If associations are needed by a tool, then it should use CMOF, not EMOF. If a modeler needs something like an association in EMOF/EMF, then they can use the mediator pattern reasonably effectively. I also do not believe EMOF should specify or require any tags to support structural modeling. Tags were for extensibility, not fundamental metamodel concepts. Such an addition would need to have compelling use cases that cannot be addressed by other means. The concept of association was explicitly kept out of EMOF. I do not believe we should graft something back in using tags to simulate association ends. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Uhl, Axel" To: "'pete.rivett@adaptive.com'" , "'mof2core-rtf@omg.org'" , Jim Amsden/Raleigh/IBM@IBMUS Cc: "'ed@willink.me.uk'" Date: 04/29/2010 06:21 PM Subject: Re: Discussion on MOF2 Core Issue 12800 -------------------------------------------------------------------------------- Pete, thanks for kicking this off. At some other place Ed already proposed "Property.oppositeRoleName" as tag name which seemed to make sense to me. Jim, do you still have general objections to introducing such a standard tag? If so, look at OCL issue 15175 where with a naming tag for the non-existing opposite we can save a concrete syntax extension for OCL and make navigation in these directions more intuitive. Best, -- Axel ------------------ Sent from BB -------------------------------------------------------------------------------- From: Pete Rivett To: mof2core-rtf@omg.org ; Jim Amsden Cc: Ed Willink ; Uhl, Axel Sent: Thu Apr 29 23:32:25 2010 Subject: Discussion on MOF2 Core Issue 12800 Below is the issue and my original response: I removed it from the ballot since Jim had raised a comment and I realized the proposal was not complete (e.g. did not define the name of the Tag) so it needed discussion. This email is intended to start such a discussion. Iâm going on vacation for a week so hopefully youâll all have it sorted by the time I get back J BTW Ed, EMOF (as well as CMOF) does include Tags . see Figure 12.1 iin formal/06-06-01 where you can see that EMOF merges in the Extension package which defines Tag. Jim wrote: EMOF does not have associations. Rather it uses a notation option for properties that have non-primitive types that uses CMOF association notation. So there are no member or owned ends of the association. Rather QVT should treat these as properties which not non-navigable associations, and there would be no need to a name for the un-named end. Issue 12800: Capturing Unnavigable Opposite Property Role Names (mof2core-rtf) Click here for this issue's archive. Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@willink.me.uk) Nature: Uncategorized Issue Severity: Summary: EMOF does not support identification of the opposite role name for a non-navigable association, however QVT requires such role names to be used. OCL defines an implicit role name, but UML graphics supports arbitrary names. At the EclipseCon OMG symposium in February, it seemed appropriate to resolve the limitation in the following way. An opposite role name may be denoted by a Comment Comment with the inner Comment defining a formal function for the outer Comment. Thus in: "backward" is defined as the oppositeRoleName of "forward". This practice makes the missing information available, and avoids any changes to the MOF meta-model and so avoids introducing any additional Property instances that might bloat existing usage. It would be helpful if a future MOF version, or an addendum to existing versions, endorse this practice. An equivalent Ecore EAnnotation and cross-conversion was introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede). Resolution: The use of ânon-navigableâ is out-dated: the issue is where Property::opposite is empty and there is nothing to hang the name on. This would seem better addressed by the use of a MOF Tag rather than two nested Comments. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 tel: +1 949 330 7677, cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp From: "Frankel, David" To: "issues@omg.org" CC: "mof2core-rtf@omg.org" Date: Mon, 30 Aug 2010 14:29:26 -0400 Subject: MOF2Core RTF issue 12800 Resolution and Thread-Topic: MOF2Core RTF issue 12800 Resolution and Thread-Index: ActIcUbUq0QbuHaxQRWWHfCX7eVphg== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MOF 2 Core RTF members, On behalf of Axel Uhl, who has been on vacation, I.m submitting an updated issue 12800, which preserves untouched Ed Willink.s issue .Summary. section and fills in the .Resolution. and .Revised Text. sections of the issue template. Regards, --Dave David S. Frankel Standards and Open Source Strategy Technology and Innovation Platform Group SAP Labs LLC; Palo Alto, California USA Phone & Cell +1 530 591-0212 Email: david.frankel@sap.com Issue 12800: Capturing Unnavigable Opposite Property Role Names (mof2core-rtf) Click here for this issue's archive. Source: THALES (Dr. Edward Willink, ed(at)willink.me.uk) with Resolution and Revised Text supplied by Axel Uhl Nature: Uncategorized Issue Severity: Summary: EMOF does not support identification of the opposite role name for a non-navigable association, however QVT requires such role names to be used. OCL defines an implicit role name, but UML graphics supports arbitrary names. At the EclipseCon OMG symposium in February, it seemed appropriate to resolve the limitation in the following way. An opposite role name may be denoted by a Comment Comment with the inner Comment defining a formal function for the outer Comment. Thus in: "backward" is defined as the oppositeRoleName of "forward". This practice makes the missing information available, and avoids any changes to the MOF meta-model and so avoids introducing any additional Property instances that might bloat existing usage. It would be helpful if a future MOF version, or an addendum to existing versions, endorse this practice. An equivalent Ecore EAnnotation and cross-conversion was introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede). Resolution: Further email exchanges on the RTF list discussed using an EMOF Tag instead of a Comment. So the proposed resolution is to introduce an EMOF Tag named .org.omg.emof.oppositeRoleName. that can be applied only to a Property whose .opposite. Property is empty. The .value. of this Tag specifies a role name that expressions (such as OCL expressions and QVT expressions) can use to traverse in the opposite direction of the Property. Revised Text: 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. Rationale This resolution introduces a facility that is lighter weight than using Property.s .opposite. Property. Use of the .opposite. Property in all cases where what is required is only the ability for expressions to traverse in the opposite direction would have the following negative consequences: · It would result in tighter coupling among Classes · It would add to the runtime burden that instances of the model place upon the underlying infrastructure that manages them, by: 1) increasing the overall footprint, since the opposite Property adds substantially to the contract of the Class that owns the additional Property designated as the opposite of the original Property; 2) requiring that storage be allocated for instances of the additional Property; and 3) requiring that referential integrity be maintained in storage among instances of the original Property and instances of the additional Property. 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. (Issue subitter.s note: The Revised Text ends here) From: "Frankel, David" To: "mof2core-rtf@omg.org" Date: Mon, 30 Aug 2010 14:41:31 -0400 Subject: Explanation re issue 12800 Thread-Topic: Explanation re issue 12800 Thread-Index: ActIcvaoORr5InrpQf6kvUo/lsk/Jw== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Colleagues, Regarding the issue 12800 resolution proposal that I submitted a few minutes ago on behalf of Axel Uhl: We realize that there are people who have reservations about this, and Axel told me he would be happy to have a phone call, if it pleases the co-chairs, to give people an opportunity to discuss their reservations and to try to work through this. Regards, --Dave David S. Frankel Standards and Open Source Strategy Technology and Innovation Platform Group SAP Labs LLC; Palo Alto, California USA Phone & Cell +1 530 591-0212 Email: david.frankel@sap.com Ed Willink