Issue 303 proposed resolution

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 4th 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.