thanks!
scott

In my view, dataInput and dataOutput elements (children of activity or event) relate to executable design, not non-executable modeling. They are children of the ioSpecification element, which is executable design detail. dataOutput allows the dataAssociation to represent the mapping , i.e., transformation, of that data to a stored variable (the data object), and dataInput allows another mapping from the variable to the input of the target activity or event.

In BPMN 1.x — and in non-executable models generally — the modeler’s intent is not signify XPath or XSLT or Java mapping in data flow; it is just to indicate that this data or document is passed to the next step. While the mapping elements (assignment or transformation) are not required in the xsd, without them dataInput and dataOutput are really redundant. A dataOutputAssociation child of an activity implies the source is the dataOutput; if you do not specify the mapping, you should not have to add the dataOutput element in the serialization. More important, most tools for non-executable modeling don’t provide the equivalent of dataInput or dataOutput, so they would just have to add extra stuff to the export that adds zero value.

As you correctly indicate, the sourceRef (required) for a dataOutputAssociation out of an activity is, according to the draft xsd, the id of the dataOutput not that of the activity itself. So on that score my serialization violates the draft schema, I concede. In the BPMN drafting, I argued that this forced execution-related elements into non-executable models. This was acknowledged by the team and deferred to FTF. The options we discussed were either allowing the dataOutputAssociation sourceRef to point to the activity itself (instead of its grandchild dataOutput element) or to allow the sourceRef to be optional, since the source is obviously implied. (And of course, all the same issues for data inputs…) I don’t know the current status of this issue in FTF.

_123
_6b35b310-ad84-4c8c-854c-1cefd2655736

_456
_a2370682-3fca-40f5-ad23-a25180931e6a

In ?standardProcess.bpmn? example, regarding ?Open Mail? userTask and its 2 associated dataObjects.

Is userTask missing 2 dataOutput?, then the 2 dataOutputAssociation would be referring to 2 dataOutput in ?sourceRef?, instead of the useTask itself. Something like this:
<userTask id=”_29749b37-5ab0-4bbb-8b27-9d8d5ffc55dd” name=”Open Mail”>
  <ioSpecification>
    <dataOutput id=”_123″/>
    <dataOutput id=”_456″/> 
 
    <outputSet>
      <dataOutputRefs>_123</dataOutputRefs>
    </outputSet>
 
    <outputSet>
      <dataOutputRefs>_456</dataOutputRefs>
    </outputSet>
  </ioSpecification>
 
  <dataOutputAssociation id=”_ef59debe-c0ea-49c8-8c96-3d625d4f82ff”>
    <sourceRef>_123</sourceRef>
    <targetRef>_6b35b310-ad84-4c8c-854c-1cefd2655736</targetRef>
  </dataOutputAssociation>
  <dataOutputAssociation id=”_dc482d79-eb09-4246-bfc4-002af3a3cee6″>
    <sourceRef>_456</sourceRef>
    <targetRef>_a2370682-3fca-40f5-ad23-a25180931e6a</targetRef>
  </dataOutputAssociation>
</userTask>
The same is for ?Process Remittance? & ?Process Application? subProcesses, as it seems that they miss dataInput each.

Does this make sense or I?m missing something?

Thanks,

Mohamed

1: XPDL provides a method for allowing multiple views of the same process model: the attribute ToolId in the graphics element for each model object. The specification does not spell out a systematic way of using this, and it should do a better job to support model portability; but then again, the BPMN2.0 spec doesn’t spell out how to use the multiple views either.
2: We are working very hard to make portability work for the conformance classes we have developed for XPDL2.1, and certification in a particular portability class will insure that models can be moved without requiring any XSLT tinkering.
3: BPMN2.0 fails the portability objective for another major reason: it includes so many details and new concepts, even in the ‘core’ elements, that vendors will end up supporting their own subsets and defeat the portability objective. Conformance class subsets are essential in this context. In fact Bruce and I have worked hard to develop a set of portability classes for XPDL2.2, which will include the process modeling capabilities of BPMN2.0.
4: In my opinion, The finalization Task Force must face the issue of how to provide a BPMN2.0 specification that addresses the needs of business analysts, rather than IT professionals focused on providing all the details for enactment or execution of a process model. I’m willing to bet that if you took a survey of all the current BPMN models you would discover that the vast majority are ‘higher level’. If the FTF does nothing about this problem BPMN2.0 will ultimately not serve the process modeling community at large.
5: I am on the FTF, along with some colleagues who support this perspective. We will need all the help we can get. If you agree with this please help us. I can be contacted at rshapiro@processanalytica.com.

WRT to pressuring OMG. Anyway we can organize something. I’m not a member but we are a client of Casewise who might have some weight. I also know someone who works with OMG on BPMN.

Any thoughts ?