[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mdt-bpmn2.dev] ItemDefinition and structureRef
- From: Gary Brown <gbrown@xxxxxxxxxx>
- Date: Fri, 14 Oct 2011 06:32:40 -0400 (EDT)
- Delivered-to: email@example.com
----- Original Message -----
> 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
Its true that the QName implies it should be a reference to something.
However in section 13, it states that "ItemDefinitions with an itemKind of Physical" are non-operational. Combined with the description of what they mean as physical (8.3.10) "such as the mechanical part of a vehicle", it would suggest that physical item definitions do not have a machine processable representation.
So (for example) someone wanting to use BPMN2 to describe a manual business process, they would currently be forced to create XML schema for all of the physical items that are passed around as part of their process.
Just wondering whether it is better for the model to expose the QName, and then provide utilities to help applications resolve the reference where relevant (i.e. where kind is information)?
> 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.
> -----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
> 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 mailing list