supritht / oryx-editor

Automatically exported from code.google.com/p/oryx-editor
Other
0 stars 0 forks source link

Adopt BPMN 2.0 final metamodel #442

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
The BPMN 2.0 final specification is there, and we can use it with through the 
Java metamodel of the Eclipse MDT BPMN 2.0 project. 

We should prefer it to using jaxb, as it will come with better testing  and 
validation.

I am the lead for this Eclipse project and I commit to helping Oryx use this 
metamodel.

Original issue reported on code.google.com by antoine....@gmail.com on 15 Jun 2010 at 9:47

GoogleCodeExporter commented 9 years ago

+1 on aligning ORYX with final version of BPMN 2.0.

I am curious why the Eclipse MDT BPMN 2.0 project chose not to use JAXB 2? In 
my experience JAXB2 has been a very solid foundation for XML Data Binding in 
the implementation of many specifications. Is there something diferent about 
BPMN 2.0 that JAXB is not a good fit?

-1 on not using JAXB

Original comment by farrukh.najm on 12 Aug 2010 at 1:14

GoogleCodeExporter commented 9 years ago
You might want to check out the Eclipse Modeling Framework. The BPMN2 spec is 
based on CMOF and XSD, and EMF has all the tooling to create a good ecore-based 
model that takes both best parts of CMOF and XSD, with the ability to create 
qnames while checking the object type for example, or the possibility to manage 
multiple resources through BPMN. JAXB would not work at all for this kind of 
job.

Original comment by antoine....@gmail.com on 12 Aug 2010 at 12:12

GoogleCodeExporter commented 9 years ago
@Antoine> Thanks for the info. Forgive my unfamiliarity with CMOF. Can you tell 
me:

* what BPMN 2 uses CMOF for? Is it complimentary to what it uses XSD for or is 
it an alternate model description language from OMG? 
* What would one lose if one where to only build JAXB 2 bindings from the BPMN 
2 XSD?
* What precise version of BPMN 2.0 xsd is oryx project currently supporting. I 
cannot tell for sure because the generated XML does not have schemaLocation 
specified.

Original comment by farrukh.najm on 12 Aug 2010 at 12:19

GoogleCodeExporter commented 9 years ago
Here is a presentation of the work to reconcile the CMOF and the XSD:
http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/20177

Both CMOF and XSD schemas are valid, but the XSD cannot explicitly enforce the 
type of object it references through qnames. The CMOF has this ability.

If you use JAXB only, you will not be able to enforce the types of the 
references that use qnames.

AFAIK Oryx uses the beta 1 schema.

Original comment by antoine....@gmail.com on 12 Aug 2010 at 12:25