I recently received the following letter:

I am a Computer Science student and Software Engineer interested in scientific workflow technologies and BPMN2.0 modeling/execution semantics.   If possible, I would like to ask for your kind opinion on a simple BPMN2.0 modeling issue I am wondering about.  This issue is related to the following question: “is it possible to overwrite activity-task’s properties with InputDataAssociations ?”.

Suppose we model a task T with dataInput dI and property P as follows:

 <task id="T">
  <ioSpecification>
     <dataInput id="dI" />
     <inputSet>
       <dataInputRefs>dI</dataInputRefs>
     </inputSet>
  </ioSpecification>
   <property id="P" />
</task>

I was wondering weather or not it is both BPMN2.0 compliant and elegant to introduce the following assignment InputDataAssociation “dA” inside task “T”, in order to write P ?

 <task id="T">
   
[...]
   <inputDataAssociation id="dA">
     <targetRef>dI</targetRef>
     <assignment>
       <from>dI</from>
       <to>P</to>
    </assignment>
  </inputDataAssociation>
</task>

I think this modeling is not completely elegant, maybe because dI is used as a source value of the assignment, despite the fact that it is a target of the inputDataAssociation.  Since the target of an inputDataAssociation can not directly be a task’s property (can be?), I wonder weather or not BPMN2.0 task’s properties can be overwritten with data values from the outside task’s scope.   If you could share your kind opinion about this topic, it will be of a great help and highly appreciated. Thank you.

I am publicly on record as saying the data flow portions of the BPMN 2.0 spec are the worst part of the document, so vague as to be mostly unusable.  And I have debated the student’s question previously, in a slightly different form, with Falko Menge of camunda, so even BPMN experts do not agree on the answer.  The spec does not clearly distinguish between a dataObject and a property except to say that there is no graphic for a property, even though 99% of the time, the graphic for dataInput is omitted, so this is not a useful distinction.  They both represent stored instance values accessible only during the lifetime of the running instance of the activity, process, or event in which they are defined.  In other words, technically the spec defines only their use in executable BPMN; for non-executable, you are left to your imagination.  They are both explicitly item-aware, meaning they both may be a source or target of a data association.

One difference related to the student’s question is that a data object cannot belong to a task, but a property can.  The data object may belong to a subprocess or process containing the task, and its value may be mapped at runtime to the task data input by a data association.  About that much there is no debate.

The debate is related to the meaning of a data input.  Is it an interface specification (my view) or a stored value (Falko’s view)?  The spec says on pp211-213 that data input is used to specify the input requirements of an activity (sounds like a signature or interface to me), and that a data input may have incoming data association.  It does not say a data input may have outgoing data association, and if you consider it, as I do, to be an interface not a stored value, then outgoing data association makes no sense.  But as I said earlier, there is no agreement on this, and given OMG’s record on such things, I don’t expect resolution of the question in my lifetime.

But I would say that neither side of that argument would favor the student’s solution of mapping a task data input to a property of the same task.  The property can attain its value in one of two ways: mapping from a stored value external to the task (data object or data store), or action of the task itself.  In the former case there would probably be a data input association directly to the property from the external  data source; in the latter case there would be no data input association.  If you consider a data input a storage location, I suppose it might be legal to populate the property via a mapping to the data input and then a second mapping from there to the property, but I don’t see the purpose in the extra step.  That might make sense if the property lifetime were not limited to the lifetime of the task, for example if it could store some value until the end of its containing process instance.  But it can’t.