OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]