Issue 303 proposed resolution

["Mark Ford" <mark.ford@active-endpoints.com>]

My proposal for Issue 303 is below. The intent is to disallow duplicate fault handlers by stating that if a rule were to match more than one fault handler then we have an ambiguity and must reject the process. This can be determined statically.

 

It was mentioned in the July 12 TC call that it is possible that the resolution for Issue 280 may have an impact on this issue resolution. In particular, if Issue 280 changes the fault matching rules such that a rule can match multiple fault handlers or creates an ambiguity due to type inheritance or substitutionGroups then the proposal would have to be reworded to not rely on the fault matching rules and instead define what constitutes a duplicate <catch>.

 

FORMAL PROPOSAL

 

CHANGE paragraph in Section 12.5 (line 5118 of July 4^th version)

 

FROM

 

Because of the flexibility allowed in expressing the faults that a <catch> construct can handle, it is possible for a fault to match more than one fault handler.

 

TO

 

Because of the flexibility allowed in expressing the faults that a <catch> construct can handle, it is possible for a fault to match more than one fault handler. While multiple fault handlers may match a fault, the <faultHandlers> element MUST NOT contain identical <catch> constructs such that a fault would match multiple fault handlers using the same fault matching rule as described below. A process definition that violates this condition MUST be detected by static analysis and rejected by a conformant implementation.