Closed FO-e-X closed 4 years ago
You can easily disable this rule if you don't like it: https://github.com/bpmn-io/bpmnlint#configuration
BTW: Please don't use BTW sections. Open a separate issue if you think it's justified.
I understand your position. It's not your problem, that I can't change the config because auf enterprise restrictions here with conflicts to the rebundling process.
But I really don't understand, why this rule exists, or still exists. It is cutting functions of Camunda BPMN, if someone uses the default settings and wants only good linted models running.
I don't want to force someone or something, I just want you to think about it :) It's a rule proposal, as mentioned exactly at the page you showed me by the link. :) It's fine to me when nothing is changed...
Regards Frank
But I really don't understand, why this rule exists, or still exists. It is cutting functions of Camunda BPMN, if someone uses the default settings and wants only good linted models running.
The no-inclusive-gateway rule exists for good reasons:
Both issues are due to the semantics of the inclusive gateway according to the BPMN spec which says: Join happens only when all tokens that could arrive arrived.
Meta comment: When filling issues, please provide context (links to documentation) and add images that make your case. This helps you get appropriate answers and saves time for us to get to a shared understanding.
Can this be mentioned in the main docs? It is a part of official BPMN specs, so saying that it doesn't work well in Camunda is not enough. And your other point that it is hard for humans to read can also apply to any other complicated diagram or their parts.
Can this be mentioned in the main docs? It is a part of official BPMN specs, so saying that it doesn't work well in Camunda is not enough.
It does not say it doesn't work well with Camunda. It says you should not use it (for the reasons mentioned https://github.com/bpmn-io/bpmnlint/issues/41#issuecomment-580213851).
To add up to this, the criticism on this one is not that it is hard to read, it is incredibly hard to understand the fork and join semantics, i.e. understand what actually happens on the diagram.
If you think we can do anything to improve the documentation, please file a PR and we can start a discussion.
Why the linter rule no-inclusive-gateway is allways an error? This kind of gateway is a usefull combination of an exclusive gateway and a parallel gateway. Its the missing link between both :)
An exclusive gateway need a clear decision, what single sequence flow should be used. A parallel gateway always run all following flows. But if I have to decide to run all possible flows depending on the condition, this means I can run all but I need not to run all. This is not possible with the 2 other gateways. Even if I have only 2 sequence flows following the gateway all 3 gateways can have a different behavior. The exclusive gateway always runs only 1 flow, the parallel gateway always run both flows and only the inclusive gateway has the capability to decide if it run 1 or 2 flows.
So, please remove this rule from the basic rule set.
BTW: maybe you can enhance the conditional-flows rule? At the moment this rule only checks if the sequence flows are marked as default oder have a condition. Maybe it's not a big effort to check, that only 1 flow is marked as default and all other conditions are unique for this gateway (not checking for possible results, just comparing the values).
Regards Frank