Re: [wsbpel] Issue 182 - Proposal for vote

["Yaron Y. Goland" <ygoland@bea.com>]

I favor a simpler approach where we allow people to simply not mention 
the data at all and still be allowed to catch a fault with data if the 
name matches. But let's first discuss it in the context of an overall 
solution for 185. If that doesn't work then we can fall back to 182.

	Yaron

Alex Yiu wrote:
> Hi, all,
> 
> Similar to Danny's situation, one of my issue (Issue 182) has dependency on 
> Issue 185. Hence, here I submit a conditional proposal to make sure this issue 
> got addressed regardless of result of Issue 185.
> 
> The following proposal for Issue 182 will be active, if there is no proposal 
> passed for Issue 185 or the resolution for 185 is not passed in a way that I 
> expect. If I need to activate this proposal, I may to refine / edit some 
> semantics / wordings here pending on result of Issue 185 and other related issues.
> 
> 
> ============================================
> *Summary: *
> Add new version of fault handler that specifies both a name and a body and can 
> catch either just on name or on both name and body. [That is option (C)]
> 
> *Details:*
> Adding a new "optionalFaultData" attribute to the <catch>
> 
>      <catch faultName="qname"? *optionalFaultData="yes"?* faultVariable="ncname"?
>                                faultMessageType="qname"? >
> 
> Add the following to paragraph #4 in section 13.4:
> 
>     This attribute is an optional boolean attribute, which has the fixed value
>     of "yes".  When optionalFaultData attribute is present, faultName attribute
>     MUST be present, and faultVariable and faultMessageType attributes MUST NOT
>     be present.
> 
> 
> Change the following bullets in section 13.4:
> From:
> ---------------------------------------------------------------
> 
>     * If the fault has no associated fault data, a catch activity that specifies
>       a matching faultName value and no faultVariable attribute will be selected
>       if present. Otherwise, the default catchAll handler is selected if present.
> 
>     * If the fault has associated fault data, a catch activity specifying a
>       matching faultName value *and* a faultVariable whose type (WSDL message
>       type) matches the type of the fault’s data will be selected if present.
>       Otherwise, a catch activity with no specified faultName and with a
>       faultVariable whose type matches the type of the fault data will be
>       selected if present. Otherwise, the default catchAll handler is selected
>       if present.
> 
> ---------------------------------------------------------------
> 
> To:
> ---------------------------------------------------------------
> 
>     * If the fault has no associated fault data, a catch handler that specifies
>       a matching faultName value and no faultVariable attribute will be selected
>       if present. _Otherwise, __a catch fault-handler with optionalFaultData
>       attribute and a matching faultName value will be selected if present._
>       Otherwise, the default catchAll handler is selected if present.
> 
>     * If the fault has associated fault data, a catch handler specifying a
>       matching faultName value *and* a faultVariable whose type (WSDL message
>       type) matches the type of the fault’s data will be selected if present.
>       Otherwise, a catch handler with no specified faultName and with a
>       faultVariable whose type matches the type of the fault data will be
>       selected if present. _Otherwise, a catch fault-handler with
>       optionalFaultData attribute and a matching faultName value will be
>       selected if present._ Otherwise, the default catchAll handler is selected
>       if present.
> 
> ---------------------------------------------------------------
> 
> 
> ============================================
> 
> 
> Thanks!!!
> 
> 
> 
> Regards,
> Alex Yiu
>