Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-bpmn2.dev] ItemDefinition and structureRef

Hi Bob,
I'm still convinced that a reference to EObject is correct. In the XSD model of BPMN2 it is a QName, which is a clear sign that they expect a kind of valid reference to something (whatever something means). It could be a reference to an XSD complex type or Element. But it could also be a reference to any proprietary Data structure containing any kind of information. 
For the EMF model it means that it could point to an EObject from a private class, e.g. containing some strings. 
We had a similar discussion on the list some time ago. See here:
http://dev.eclipse.org/mhonarc/lists/mdt-bpmn2.dev/msg00151.html
There is even an example, how you could but a string into the structureRef property using the EOject proxyURI.


Reiner.
 

-----Ursprüngliche Nachricht-----
Von: mdt-bpmn2.dev-bounces@xxxxxxxxxxx [mailto:mdt-bpmn2.dev-bounces@xxxxxxxxxxx] Im Auftrag von Bob Brodt
Gesendet: Donnerstag, 13. Oktober 2011 23:23
An: mdt-bpmn2.dev@xxxxxxxxxxx
Cc: adrian mos; Antoine Toulme
Betreff: [mdt-bpmn2.dev] ItemDefinition and structureRef

Hi all,

I'm running across some problems with the bpmn2 metamodel when trying to reference informational items with an ItemDefinition. This is related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=340068

The main issue is that structureRef is a reference to an EObject; as I understand it, for itemKind=INFORMATION the structureRef doesn't necessarily refer to any kind of data structure, nor EObject - it could be a plain String object. At some point in its history, this feature was a QName (see the links in https://bugs.eclipse.org/bugs/show_bug.cgi?id=355651 to discussions about why this was changed) but it's been changed to EObject Reference.

Since interpretation of this feature is mostly up to the runtime anyway, does anyone see a problem with making this an Object instead of a EObject reference?

Also, the BPMN 2.0 spec states that the default value for itemKind is INFORMATION, but the model has the default as PHYSICAL - but that's a minor issue.

________________________
Robert ("Bob") Brodt
Senior Software Engineer
JBoss by Red Hat

_______________________________________________
mdt-bpmn2.dev mailing list
mdt-bpmn2.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-bpmn2.dev


Back to the top