Link Event Definition: Table 10.98 inconsistent with XSD and MM

[falko]

Cardinalities of source and target in Table 10.98 are inconsistent with BPMN's XML Schema and UML Meta-Model:

Table 10.98 on page 270 (PDF 300) says:

• sources: LinkEventDefinition [1..*]
• target: LinkEventDefinition [1]

XML Schema says:

<xsd:element name="source" type="xsd:QName" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="target" type="xsd:QName" minOccurs="0" maxOccurs="1"/>

UML Meta-Model says for both:
Lower Bound: 0
(see also Figure 10.73 on page 262 (PDF 292))

Proposal:
Change Table 10.98 on page 270 (PDF 300) into:

• sources: LinkEventDefinition [0..*]
• target: LinkEventDefinition [0..1]

[falko]

The BPMN spec is ambiguous about the connection of throwing and catching Link Events. I see two possible interpretations:

1. Throwing and Catching Link Events are correlated using the mandatory attribute name and the attributes source and target are just optional similar to incoming and outgoing.
2. Throwing and Catching Link Events are correlated using the attributes source and target.

After further investigation, I discovered that the BPMN 2.0 Finalization Task Force intended to introduce the attributes 'source' and 'target' to avoid the correlation via names. See also OMG Issue 14816, BPMN 2.0 FTF Report and BPMN 2.0 FTF Report Verification Site.

Here is the resolution that all FTF members accepted:

This is what's in the final BPMN 2.0 specification:

So it looks like source and target are meant to be used for link correlation. However, this raises further questions:

1. Why is the name attribute still there?
2. Does this new mechanism break backwards compatibility with BPMN 1.x?
3. How did vendors actually implement it in their current implementation?

[falko]

When I think about connecting Link Events in a modeling tool, I believe that source and target are rather impractical to handle in a user interface.

Furthermore, I challenge the key arguments raised in OMG Issue 14816:

There is no constraint on names, so I could create multiple Catch Link Events with the same name, thus breaking the model.

There plenty of other places in the BPMN spec where constraints are only expressed by plain text.

Names are not used, in general throughout the spec, for formalizing relationships. Instead IDs are.

In fact Error, Escalation and depending on the implementation event Signal and Message Events are correlated via simple names.

Users do sometimes assign different names to the Throw and Catch (for example "A" for the throw and "from A" for the catch).

That is certainly true for the name of the Event, which is displayed graphically as a label in the diagram. But the name of a Link is an attribute of the underlying Event Definition. So different values for documentation are perfectly handled without source and target. However, most other Event Definitions refer to some central definition of the according Error, Escalation, Signal or Message. This is a generic pattern of BPMN Events, which could be applied to Link Events to avoid direct correlation via names that are entered by a user in multiple parts of a model.

Proposal:
Keep the attribute name as correlation key and completely remove source and target (or if that is not possible for backwards compatibility, make them completely optional like incoming and outgoing).
Optional: Make Link Event Definitions refer to central Link definitions.

[mskurz]

I tend to use explicit associations instead of implicit associations that are based on names.
IMHO, this creates easier to maintain models and it is more consistent with most parts of the spec.

Even if link events are explicitly associated, it is still helpful to add a name to the events in order to represent the association visually.

[falko]

The original proposal in the issue description has been accepted by the MIWG at 2013-11-27.

The rest of the discussion has been moved to a separate issue #141

@mskurz maybe you would like to repost your comment there.

[mskurz]

@falko OK.

[dgagne]

Webmeeting 27 Nov 2013
The following proposal for this issue was accepted

Change Table 10.98 on page 270 (PDF 300) into:

sources: LinkEventDefinition [0..*]
target: LinkEventDefinition [0..1]