DestroyLinkAction.endData type is not properly redefined

[jerome-obeo]

Some reference types are redefined with annotations in the UML2 metamodel. This is the case, for instance, in the DurationConstraint concept for the specification reference we can find the duplicates annotation that gives us the actual expected type:

  <eClassifiers xsi:type="ecore:EClass" name="DurationConstraint" eSuperTypes="#//IntervalConstraint">
    <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
      <details key="documentation" value="A DurationConstraint is a Constraint that refers to a DurationInterval.&#xA;&lt;p>From package UML::Values.&lt;/p>"/>
    </eAnnotations>
    <eAnnotations source="duplicates">
      <eAnnotations source="specification">
        <details key="eType" value="uml::DurationInterval"/>
      </eAnnotations>
      <contents xsi:type="ecore:EReference" name="specification" ordered="false" lowerBound="1"
          eType="#//ValueSpecification" containment="true">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The DurationInterval constraining the duration.&#xA;&lt;p>From package UML::Values.&lt;/p>"/>
        </eAnnotations>
        <eAnnotations source="redefines" references="#//IntervalConstraint/%duplicates%/specification #//Constraint/specification"/>
      </contents>
    </eAnnotations>
[...]
  </eClassifiers>

As far as DestroyLinkAction is concerned the endData reference only accepts the LinkEndDestructionData instance but we cannot find the same pattern of annotation to specify this type redefinition:

  <eClassifiers xsi:type="ecore:EClass" name="DestroyLinkAction" eSuperTypes="#//WriteLinkAction">
    <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
      <details key="documentation" value="A DestroyLinkAction is a WriteLinkAction that destroys links (including link objects).&#xA;&lt;p>From package UML::Actions.&lt;/p>"/>
    </eAnnotations>
    <eAnnotations source="duplicates">
      <contents xsi:type="ecore:EReference" name="endData" ordered="false" lowerBound="2"
          upperBound="-1" eType="#//LinkEndDestructionData" containment="true">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The LinkEndData that the values of the Association ends for the links to be destroyed.&#xA;&lt;p>From package UML::Actions.&lt;/p>"/>
        </eAnnotations>
        <eAnnotations source="redefines" references="#//LinkAction/endData"/>
      </contents>
    </eAnnotations>
  </eClassifiers>

We would expect to find an annotation such as inside DestroyLinkAction:

      <eAnnotations source="endData">
        <details key="eType" value="uml::LinkEndDestructionData"/>
      </eAnnotations>

Is there a different way to express type redefinition or is the redefinition missing?

Thanks

[khussey]

Thanks for issue report, @jerome-obeo .

It's been a while since I looked closely at this part of the code, but as I recall there are two ways that "duplicates" are processed when converting a UML model to an Ecore model - one detects cases where there is an explicit refines constraint in the metamodel and another which detects cases where there isn't such a constraint but a property is effectively redefined (typically because the type is being refined).

The classifier hierarchy is different for DestroyLinkAction and DurationConstraint. In the former case, there is an explicit redefinition only, whereas in the latter case there's both an implicit and explicit redefinition. The added complexity (and order in which explicit and implicit redefinitions are processed) for the latter case results in the intended type for property being located in an additional annotation whereas in the former case, the intended type is reflected in the duplicate eReference itself:

<contents xsi:type="ecore:EReference" name="endData" ordered="false" lowerBound="2" upperBound="-1" eType="#//LinkEndDestructionData" containment="true">

[jerome-obeo]

Thanks for the explanations. We will then have to look at each duplicates annotation to check all of them.