SYSML2_ — TransitionUsage requires binding to succession with mandatory end multiplicities

Clause 7.13.3 (Bindings as Usages) says

The end features of a binding always have multiplicity [1..1].

and Clause 8.3.17.9 (TransitionUsage) includes a constraint requiring a (1 to 1) binding between its succession and transitionLink:

checkTransitionUsageSuccessionBindingConnector
A TransitionUsage must have an ownedMember that is a BindingConnector between its succession and the
inherited Feature TransitionPerformances::TransitionPerformance::transitionLink.

ownedMember->selectByKind(BindingConnector)->exists(b |
    b.relatedFeatures->includes(succession) and
    b.relatedFeatures->includes(resolveGlobal)
    'TransitionPerformances::TransitionPerformance::transitionLink')))

with similar text in 8.4.13.3 (Transition Usages). A succession will typically have fewer values than its transition usage, because the succession won't be traversed for every value (occurrence) of its source feature, while its transition usage will have the same number of values as the source feature, conflicting with the 1-1 end multiplicities. Compare to the modeling pattern in KerML Clause 9.2.10.1 (Transition Performances Overview), excerpted in KERML-157.

No semantic problem

The semantic constraint checkTransitionUsageSuccessionBindingConnector is not actually related to the binding discussed in the part of 9.2.10.1 Transition Performances Overview referenced in the isse (indeed, this text in the overview no longer seems to be a correct description of the Transition Performances model). The constraint checkTransitionUsageSuccessionBindingConnector does not require that there be a BindingConnector between a TransitionUsage and it's inherited feature TransitionPerformance::transitionLink. Rather, it requires, for any TransitionUsage, that there be a BindingConnector between the Succession given by TransitionUsage::succession and transitionLink.

For the record, the following is the semantic pattern enforced by checkTransitionUsageSuccessionBindingConnector.

• The multiplicity of transitionLink is 0..1. It will have a value or not depending on the performance of the TransitionUsage.
• The multiplicity of the succession of the TransitionUsage will be the default of 0..* (since it is parsed without any explicit multiplicity). (The multiplicity of the property succession in the abstract syntax is 1..1, but the multiplicity of the Succession itself will be 0..*.)
• If transitionLink has a value, then the mandated BindingConnector will require that this value be the value of the succession.
• If transitionLink does not have a value, then the succession also cannot have a value, which is acceptable, because the multiplicity lower bound of the succession is 0. (The succession thus has an effective multiplicity of 0..1, but it is not necessary to declare this explicitly, because the succession can never have more values than transitionLink anyway.)

These are the correct semantics.

Note also that resolution SYSML2_-420 to SYSML2_-416 proposes to remove the sentence from 7.13.3 Bindings as Usages that is quoted in the issue. Even so, the ends of a BindingConnector still have a cross multiplicity 1 by default (these can just now also be validly subsetted to 0..1). Indeed, the default 1 to 1 BindingConnector multiplicities are necessary for the proper semantics above.