WIP: Handle bpmn:DataInputAssociation and bpmn:DataOutputAssociation according to BPMN 2.0 specification

[philippfromme]

bpmn:DataInputAssociation

• create bpmn:InputOutputSpecification if not found
• add bpmn:DataInput element and reference as targetRef of bpmn:DataInputAssociation
• add bpmn:InputSet and add reference to bpmn:DataInput
• there will only ever be one bpmn:InputSet
• always clean up bpmn:InputOutputSpecification and remove if necessary

Example:

<bpmn:task id="myTask">
  <bpmn:incoming>incoming</bpmn:incoming>
  <bpmn:ioSpecification id="myIoSpecification">
    <bpmn:dataInput id="myDataInput" />
    <bpmn:inputSet id="myInputSet">
      <bpmn:dataInputRefs>myDataInput</bpmn:dataInputRefs>
    </bpmn:inputSet>
  </bpmn:ioSpecification>
  <bpmn:dataInputAssociation id="myDataInputAssociation">
    <bpmn:sourceRef>someSourceRef</bpmn:sourceRef>
    <bpmn:targetRef>myDataInput</bpmn:targetRef>
  </bpmn:dataInputAssociation>
</bpmn:task>

bpmn:DataOutputAssociation

• create bpmn:InputOutputSpecification if not found
• add bpmn:DataOutput element and reference as sourceRef of bpmn:DataOutputAssociation
• add bpmn:OutputSet and add reference to bpmn:DataOutput
• there will only ever be one bpmn:OutputSet
• always clean up bpmn:InputOutputSpecification and remove if necessary

Example:

<bpmn:task id="myTask">
  <bpmn:outgoing>outgoing</bpmn:outgoing>
  <bpmn:ioSpecification id="myIoSpecification">
    <bpmn:dataOutput id="myDataOutput" />
    <bpmn:outputSet id="myOutputSet">
      <bpmn:dataOutputRefs>myDataOutput</bpmn:dataOutputRefs>
    </bpmn:outputSet>
  </bpmn:ioSpecification>
  <bpmn:dataOutputAssociation id="myDataOutputAssociation">
    <bpmn:sourceRef>myDataOutput</bpmn:sourceRef>
    <bpmn:targetRef>someTargetRef</bpmn:targetRef>
  </bpmn:dataOutputAssociation>
</bpmn:task>

Related to camunda/camunda-modeler#984

[nikku]

Are we able to consume <= v3.0.0 style modeled diagrams and migrate them step by step to the new IO representation?

[ElCondor1969]

This feature is really necessary. More or less, when do you expect the changes to be merged into main?

[nikku]

This feature is really necessary.

Please provide us with a little bit more context. Why is this feature really necessary?

[ElCondor1969]

Hi Nikku.
I'm sorry, I may not have been very clear.
I meant the functionality illustrated by Philipp at the beginning of PR, that is the use, according to the BPMN 2.0 standard, of the tag "DataInputAssociation" and "DataOutputAssociation".
Since the PR has not yet been merged into the master, I wondered if there was a closing date for this PR.
If I understand your question correctly.
Bye.

Please provide us with a little bit more context. Why is this feature really necessary?

[nikku]

I'm asking why the feature is important for you and not what. An answer to that question helps us to better evaluate the demand.

[ElCondor1969]

I'm asking why the feature is important for you and not what. An answer to that question helps us to better evaluate the demand.

Hi Nikku.

If I understand the purpose of Philipp's PR, this feature is important because it would allow you to manage the associations between data and tasks through the ioSpecification tag and its dataInput / dataOutput as it should be.
For a better explanation, let's consider the following trivial diagram:

Currently the editor produces, for task 1, the following XML:

<bpmn:task id="Task_1" name="Task"> <bpmn:incoming>SequenceFlow_0iu53jb</bpmn:incoming> <bpmn:outgoing>SequenceFlow_0mz7m8s</bpmn:outgoing> <bpmn:property id="Property_05b30xr" name="__targetRef_placeholder" /> <bpmn:dataInputAssociation id="DataInputAssociation_0tgejuf"> <bpmn:sourceRef>DataObjectReference_1</bpmn:sourceRef> <bpmn:targetRef>Property_05b30xr</bpmn:targetRef> </bpmn:dataInputAssociation> </bpmn:task>

As you can see, the editor created a property tag instead of using a dataInput tag within a ioSpecification tag.
In my opinion, it would be better to use a dataInput because, logically, the data converge as input data within the task to undergo some processing.

If I understood correctly, and I'm not wrong, it seems to me that the PR submitted by Philippe should solve this case too.

Bye.

[philippfromme]

That still doesn't answer the question. Obviously this PR would ensure compatibility with the BPMN 2.0 specification. The question is: What is your use case that requires this compatibility? What are you trying to do?

[ElCondor1969]

Hi, Philipp.
From the fact that you still have not understood what I meant by my last post, I am convinced that I have not understood the aims of this PR.
Please ignore my previous posts.
When I have more time, in the future, I will create a special Issue and there I will explain well what, in my opinion, it would be useful to implement to adhere more to the BPMN 2.0 standard with regard to tasks and the association with data objects.

That still doesn't answer the question. Obviously this PR would ensure compatibility with the BPMN 2.0 specification. The question is: What is your use case that requires this compatibility? What are you trying to do?

[nikku]

When I have more time, in the future, I will create a special Issue and there I will explain well what, in my opinion, it would be useful to implement to adhere more to the BPMN 2.0 standard with regard to tasks and the association with data objects.

We second your opinion and may some day maybe improve handling of IO mappings in the future.