Re: [wsbpel] Issue 303 proposed resolution

Hi Mark,

From your proposal:

"MUST
NOT contain identical <catch>
constructs such that a fault would match multiple fault handlers using
the same
fault matching rule as described below."

The term "identical <catch> constructs" may be a bit
underspecified. And, I think I understand what you mean by "a fault
would match multiple fault handlers using the same
fault matching rule as described below". I guess it does
not consider the following combination of:

<catch faultName="foo:BarFault" >

and

<catch faultName="foo:BarFault" faultElement="foo:BarElement">

illegal.

But, it may not be that easily to decode the text that way. 

How about:

------------------------------

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. <catch> constructs are considered identical in this context, when they
have identical values in
their faultName, faultElement and faultMessageType attributes.[note-1] When one of such attribute is present in
<catch>, the attribute value are considered absent, which is
considered identical to absent attribute of other <catch>. 
A process definition that violates this
condition MUST be detected by static analysis and rejected by a
conformant
implementation.

------------------------------

[Note-1]: we may need to expand the list of attributes here, depending
on the resolution of Issue 280. 

I guess this approach of the spec text will be less affected by Issue
280,  *if* Issue 280 resolution introduces semantics that allow some
more flexible fault matching.

What do you think? 

Thanks!

Regards,

Alex Yiu

Mark Ford wrote:

  
  
  
  

  
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.