Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 344777 - Escalation should extend RootElement
Summary: Escalation should extend RootElement
Status: RESOLVED FIXED
Alias: None
Product: MDT.BPMN2
Classification: Modeling
Component: Core (show other bugs)
Version: unspecified   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-04 20:28 EDT by tsurdilo surdilovic CLA
Modified: 2011-05-09 10:52 EDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description tsurdilo surdilovic CLA 2011-05-04 20:28:59 EDT 
org.eclipse.bpmn2.Escalation does not extend RootElement but it should. This problem goes all the way back to the ecore model.
Comment 1 Antoine Toulmé CLA 2011-05-04 20:33:30 EDT 
Reiner, would this be a bug in the ecore translation ? I'll take a look next week more closely.

Tihomir, any contribution to fix the problem is most welcome of course.
Comment 2 tsurdilo surdilovic CLA 2011-05-04 23:06:45 EDT 
Hi Antoine, 
simple change to BPMN20.ecore:

<eClassifiers xsi:type="ecore:EClass" name="Escalation" eSuperTypes="#//RootElement">

(addition of eSuperTypes="#//RootElement")

fixed the problem for me locally. I'll upload a patch shortly.
Comment 3 Henning Heitkoetter CLA 2011-05-05 09:26:24 EDT 
This could be due to Escalation not having a super type defined in the CMOF file.
There are some other types that should extend another type (mostly BaseElement) according to the XSD, but don't have a Generalization in the CMOF and, thus, no super type in our Ecore. A quick search among all classes in our Ecore model that don't have a super type yielded the following cases:
Escalation
InputOutputBinding
ParticipantMultiplicity
ResourceAssignmentExpression
ResourceParameterBinding
Comment 4 Reiner Hille CLA 2011-05-05 12:43:04 EDT 
Thanks Henning. This is obviously a bug in original OMG CMOF metamodel. 
Could you fix the Ecore accordingly? I don't think that we need to path the ECore, as I don't plan to rerun the merge tool.
Anyway I will post a bug to OMG BPMN 2.0 RTF.
BTW: Is it always clear what the correct super type has to be? In case of "Escalation" it is clear that the super type is "RootElement", as we have similarity to "Signal". And of cause we have the XSD, which can guide us.
InputOutputBinding for example is only contained "CallableElement" and thus does not need to be a RootElement or BaseElement.
Comment 5 Henning Heitkoetter CLA 2011-05-09 10:52:01 EDT 
In three of the five cases mentioned above, both the specification document and the XSD agree on a super type: BaseElement for ResourceAssignmentExpression, ResourceParameterBinding and RootElement for Escalation

For ParticipantMultiplicity and InputOutputBinding, only the XSD denotes BaseElement as super type, the spec does not mention a super type.

Nevertheless, I have updated all five classes, so that all XML files that are valid according to the XSD can be read.

See commit b49a7a3b6e493d4741690ba9e750069eb3cb1e8c