Community
Participate
Working Groups
Saving a synthesized QVTr trace model as *.ecore.oclas revealed that implicit opposites are serialized as traditional @x/@y URI fragments since no LUSSID and consequently no short xmi:id is allocated for them. Implicit opposites should never be referenced since they do not exist outside the normalized in-memory Pivot model. The need for such external references is eliminated by e.g. OCL's OppositePropertyCallExp and QVTc's OppositePropertyAssignment. (We cannot allocate referenceable LUSSIDs since the implicit opposites are an external modification and we cannot control how many external modifications there will be, but we can be sure that when not all opposites have explicit names implicitly generated opposites may be ambiguous undermining the LUSSID principles.) The Pivot metamodel could be modified to have both Property::explicitOpposite and Property::implicitOpposite with implicitOpposite being transient and so not serialized. See Bug 509309. For now a derived XMIHelperImpl can just suppress references to implicit opposite Property elements.
(In reply to Ed Willink from comment #0) > For now a derived XMIHelperImpl can just suppress references to implicit > opposite Property elements. Bug 530384. Suppressing all implicit references breaks consumers that make illegal references. Tough.
