[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 303 proposed resolution
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" >
<catch faultName="foo:BarFault" faultElement="foo:BarElement">
But, it may not be that easily to decode the text that way.
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?
Mark Ford wrote: