[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mdt-bpmn2.dev] ItemDefinition and structureRef
- From: "Hille-Doering, Reiner" <reiner.hille-doering@xxxxxxx>
- Date: Fri, 14 Oct 2011 12:03:16 +0200
- Accept-language: de-DE
- Acceptlanguage: de-DE
- Delivered-to: firstname.lastname@example.org
- Thread-index: AcyJ7jrTboAldTn6QtaEwwzErLj25AAaCR2Q
- Thread-topic: [mdt-bpmn2.dev] ItemDefinition and structureRef
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:
There is even an example, how you could but a string into the structureRef property using the EOject proxyURI.
Von: mdt-bpmn2.dev-bounces@xxxxxxxxxxx [mailto:mdt-bpmn2.dev-bounces@xxxxxxxxxxx] Im Auftrag von Bob Brodt
Gesendet: Donnerstag, 13. Oktober 2011 23:23
Cc: adrian mos; Antoine Toulme
Betreff: [mdt-bpmn2.dev] ItemDefinition and structureRef
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