Re: [mdt-bpmn2.dev] Splitting up BPMN20.ecore

[Benedikt Ritter <beneritter@xxxxxxxxxxxxxx>]

Hi Reiner,

please have a look at my comments inline.

Am 26. März 2012 11:37 schrieb Hille-Doering, Reiner
<reiner.hille-doering@xxxxxxx>:
> Hi Benedikt,
> first of all welcome to the BPMN2 project.

Thank you :)

> Now about your idea: It sounds good, but ...
> The Ecores in BPMN2 are generated(merged) from 2 OMG sources - CMOF and XSDs. Details can be found in my articles that are linked from our wiki. Unfortunately BPMN2.0 might have a logical layering, but physically all the semantic stuff is in one file - in both CMOF and XSD.

Ah okay, I had a short look at the Processor. Then it makes sense to
me. I'll have a look at your articles ASAP.

> If we would break the ECORE not into multiple files, it would become impossible to redo the generation. So I would only do it, it we are 100% sure, that a regeneration will definitely not happen.

At least BPMN Spec 2.0 won't change :-) OMG will publish a new
version, when something changes (at least I hope they'll do...). But
even then, I agree with you, that it is a lot of work to do it
manually.

> Besides of this technical problem, it would be a lot of work. Do you know a technical way to decide to which submodel a class would belong? They are all in the same namespace and I don't know any (meta-) attribute that would allow us the qualification.
>

I'm not sure if I understand what you mean. Are you thinking of ways
to tell the generator, how to map classes to submodels?
To be honest, I don't know the CMOF and XSD models to well. I had the
idea to split the ecore up, while I was looking through the spec.
So to answer your question: no I don't know a way to do that. :)

The only way I can think of, is to inject a mapping of class names to
submodel names into the processor. That mapping would have to be
maintained by looking through the spec. The processor would then have
to be modified to generate a variable number of models, depending on
the number of mappings available.
That is a lot of work, and without test coverage I don't want to touch
the processor implementation.

> Regards,
>  Reiner.
>
> PS: I will comment on the other question in Bugzilla soon.
>
>
>
> -----Original Message-----
> From: mdt-bpmn2.dev-bounces@xxxxxxxxxxx [mailto:mdt-bpmn2.dev-bounces@xxxxxxxxxxx] On Behalf Of Benedikt Ritter
> Sent: Sonntag, 25. März 2012 12:01
> To: mdt-bpmn2.dev@xxxxxxxxxxx
> Subject: [mdt-bpmn2.dev] Splitting up BPMN20.ecore
>
> Hi,
>
> BPMN20.ecore is really huge. Why don't we split it up the way, the
> BPMN meta model is split up in the spec? We would have four referenced
> models:
> * Infrastructure
> * Foundation
> * Common Elements
> * Services
>
> What do you think?
>
> Regards,
> Benedikt
> _______________________________________________
> mdt-bpmn2.dev mailing list
> mdt-bpmn2.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-bpmn2.dev