Potential BPMN-Spec conformance flaw: Link-Event-Definition target property is handled as an attribute
torge-hmn opened this issue · comments
Describe the Bug
The target
-property of a LinkEventDefinition
is described as an xsd:element
in the BPMN 2.0 Semantic-Schema. Therefore it should be a child node of the link event definition in a BPMN model.
In contrast bpmn-moddle
defines a link event definition to include a property target
which is marked as an attribute: Link-Event-Definition-Target property.
This results in serialized models violating the BPMN-Semantic-Schema mentioned above: The target
-property will be serialized in an attribute of the LinkEventDefinition
whereas the Schema requires it to be a child node.
Importing a valid model (including the target as a child node) results in the target property being removed from the link event definition entirely.
Steps to Reproduce
The described bug occurs in two "directions":
Case A (Export/Serialization) - Setting the target property on a link event definition results in the value being set as attribute in a serialized model
Case B (Import/Deserialization) - Importing a valid BPMN-model containing the target of a link event definition as a child node results in the property being removed
The bug can not be directly reproduced by the means of this repository, but rather using another library like bpmn-js
using bpmn-moddle
.
Github does not allow uploading XML or BPMN-files, therefore models have been uploaded in plaintext.
Case A:
If the target property of a link event definition is set programmatically an exported/serialized model will contain the target property as an attribute instead of a child node: see the attached file invalid-link-event-definitions.txt, Link-Event-Definition with ID ID14e6ec89-6434-4ef9-bdab-6784f8fee217
.
Case B:
The attached file valid-link-event-definitions.txt contains a valid model according to the BPMN-Spec. Importing it by using bpmn-js
(for example by using the bpmn-js demo) results in the target property being removed from the link event definition of the intermediate throw event. The demo also shows an import warning:
unparsable content <bpmn:target> detected line: 5 column: 8 nested error: unknown type <bpmn:Target>
Expected Behavior
In Case A, the serialized model should include the target property as a child node <bpmn:target>
.
In Case B, the model should be imported without any warning and without the target property being removed.
Attached files
valid-link-event-definitions.txt
invalid-link-event-definitions.txt
Thanks for the report. The moddle schema is mainly generated from the CMOF file so the bug needs to be fixed in the cmof-parser which incorrectly assumes that single ownedAttribute
must have isAttr=true
: https://github.com/bpmn-io/cmof-parser/blob/master/lib/parseFile.js#L342.
Respective CMOF part: https://github.com/bpmn-io/bpmn-moddle/blob/master/resources/bpmn/cmof/BPMN20.cmof#L384
@barmac We could also workaround it, as we often do (https://github.com/bpmn-io/bpmn-moddle/blob/master/tasks/transforms/transformBPMN.cjs#L47).
PR welcome to contribute this ⭐
@barmac We could also workaround it, as we often do (https://github.com/bpmn-io/bpmn-moddle/blob/master/tasks/transforms/transformBPMN.cjs#L47).
We could, but the linked file is already a ball of mud ^^
100% test covered though 😉
Thank you for your quick response yesterday!
I can't really evaluate where and how to fix this - as you were also laying out two potential solutions, there might be some space for discussions 😅
As I encountered the bug using bpmn-js
I could share my quick and dirty workaround for testing purposes: I simply removed the isAttr
-flag from the target property and added isMany
as used for other child nodes. This seems to work at a first glance - the attached file with the valid link event definition was created using this workaround. But as I am afraid of some potential unintended side effects I am not sure whether to continue using the workaround or to wait for a solution, which is probably a better idea.
Hi,
are there any new insights on this issue?
And what do you think about my suggested fix below. It seems kinda dirty to me - and I am not sure about any side effects..
As I encountered the bug using
bpmn-js
I could share my quick and dirty workaround for testing purposes: I simply removed theisAttr
-flag from the target property and addedisMany
as used for other child nodes. This seems to work at a first glance - the attached file with the valid link event definition was created using this workaround. But as I am afraid of some potential unintended side effects I am not sure whether to continue using the workaround or to wait for a solution, which is probably a better idea.
Best regards
Will be fixed via #98.
Great news, thank you!