Community
Participate
Working Groups
I was under the impression that similar to the http://schema.omg.org/spec/MOF/2.0/emof.xml#Property.oppositeRoleName annotations the upper, lower, unique and ordered attributes of the opposite property where to be defined using http://schema.omg.org/spec/MOF/2.0/emof.xml#Property.oppositeUpper, http://schema.omg.org/spec/MOF/2.0/emof.xml#Property.oppositeLower and such annotations, creating a new annotation for each value. However, looking at /org.eclipse.ocl.pivot/src/org/eclipse/ocl/pivot/internal/ecore/es2as/Ecore2ASReferenceSwitch.java it appears that the mentioned attributes should be specified as details in the #Property.oppositeRoleName annotation. Further, for example in line 260 the details for the lower value are queried using the key "lower". Same happens for other values at lines 266, 272 and 275. In all cases the single name of the property is uses as opposed to the complete Property.oppositeUpper key (although in lines 206-209 the full name is used). It will be useful if the name/method can be unified. Thanks!
I was the originator of the observation that UML opposites needed some persistence in EMOF/Ecore to fully support OCL. My OMG MOF issue, http://www.omg.org/issues/mof2core-rtf.html#Issue12800, sat on the shelf for a long time and eventually appeared with differently spelled Tag names. My add-on comment, oops, we may need opposite-ordered/unique/lower/upper was ignored. If/when, as a result of http://issues.omg.org/issues/MOF26-35, MOF endorses some more Tag spellings EMF should chase MOF, but I have no enthusiasm for doing anything until then. I have only limited influence on what appears in EMF or UML and so while UML2Ecore does now provide the annotations, the spelling is what it is. I see very little prospect of change for Eclipse spellings, and even if they changed the old names would have to be supported for legacy purposes. QVTc middle model navigation and QVTc middle synthesis from QVTr demonstrates the need for the further annotations. UMLXforEcore also needs the annotations. -- The current code is certainly confusing with different defaults depending on whether the opposite name is explicit or not. I fixed some odd corner cases in the last few weeks. But the bottom line is that if you are going to use an opposite you need to make sure it is declared fully. See /org.eclipse.qvtd.xtext.qvtcore.tests/src/org/eclipse/qvtd/xtext/qvtcore/tests/forward2reverse/List2List.ecore When I added the QVTr to middle synthesis, it became clear how many of the QVTc tests were working fortuitously with inadequate manually defined middle models.
