BPMN2 — Use "item" terminology more uniformly

> Terminology is perhaps the hardest part of standards such
> as BPMN. There is no way to pick terms that will be
> acceptable to all potential users of BPMN. Different groups
> will come into BPMN with different expectations. Some of
> the terms will fit those expectations and other will not.
> [From <a href="http://www.omg.org/archives/bpmn2-eval/msg00048.html">http://www.omg.org/archives/bpmn2-eval/msg00048.html</a>]

In this particular case, the submission has one already ("item", as in
ItemDefinition, ItemAwareElement, and ItemKind), introduced to
accomodate informational and physical flows. I think it would be good
to have uniform terminology covering both information and physical
things, for example:

Message Flow => Item Flow
(Message appears redundant with ItemDefinition, or Message could be
a subclass of ItemDefinition for those items that happen
to be used in Item Flows)
Data Object => Item Object
DataInput => ItemInput
DataOutput => ItemOutput
DataState => ItemState
DataAssociations => ItemAssociations

So much of BPMN's market is modeling businesses in general rather than
business software specifically, that I think it's important for adoption
to have the appropriate terminology.

DataInputs/Outputs/Objects, Messages, and other BPMN elements can be
physical, as defined in ItemDefinition, and it would be better if the
names reflected that possibility. However, implementations are too far
along to change at this point.
Disposition: Closed, No Change