Duplicate link throwing event issue

[Eilenn]

https://github.com/bpmn-io/bpmnlint/blob/566bec812d70751af28b252d3fdd3afce99f4dc5/rules/link-event.js#L58C37-L58C95

The line above points to Duplicate link throw event with name <${name}> in scope error - but according to the documentation: "Multiple throwing link events can link to the same catching link event. "
See: https://docs.camunda.io/docs/components/modeler/bpmn/link-events/

I think this part should be removed - the rest of the rules are quite useful, so I wouldn't want to disable the whole rule in my config.

[barmac]

Thanks for the report. The rule indicates "proper" usage of link events. I think we can consider two perspectives:

1. The rule ensures BPMN-compliant usage of link events (name enforcement, only a single catch event for given name, no catch-without-throw or throw-without-catch).
2. The rule ensures best practice usage of link events (compliant + only 1:1 relationship for link events).

The (2) part is "best practice" (according to the rules author) as indeed there can be multiple throw events of the same name according to the spec. So the relationship is n:1

Given that, we could split up the rule, so that you can still ensure correctness of your BPMN without enforcing 1:1 relationship. Still, I think the latter may make sense as the n:1 relationship is an another way to create fake-join pattern:

[barmac]

I added needs discussion as I'd like to clarify whether we want the "best practice" to still be present in the ruleset.

[Eilenn]

Hi, thank you for looking into the issue and elaborating on the rules!
While I agree that "n:1 relationship is an another way to create fake-join pattern", it strongly depends on the way you use the pattern. In our usage it's not possible to create the fake join, so I would be strongly for splitting the rule - that would allow us to still use other useful rules enforced by link-event while disabling the n:1 check separately.

[barmac]

I think this makes sense. Would you like to contribute a proposal?

[barmac]

Closed via #174