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 182 - Proposal for vote


Hi Alex,

Ok, I understand where you are coming from now. Looks like you want to "ignore fault data if present" semantics. I was thinking the optionalFaultData @ was an indicator to catch the "optional" faultdata if present. 

Can we name the attribute ignoreFaultData or something like that so that the intent is more direct and clear?

Thanks.

Prasad

Alex Yiu wrote:

Hi Prasad,

See comment inline in GREEN.

Prasad Yendluri wrote:
Hi Alex,

Couple of questions.

1. I take you are suggesting that when the @optionalFaultData is present, it can only be present with the value "yes" and when the attribute is not present it is equivalent to  optionalFaultData="no".  Is that correct? 

[AYIU]: Yes, your understanding is correct.

2. Assuming that is correct,  your proposed change to section 13.4 does not quite make sense to me.

"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. "

If the optionalFaultdata is "expected" by the catch, as implied by the optionalFaultdata="yes", then I am not sure why you say faultVariable MUST not be present?  I would think in fact the faultVariable MUST be present right?

Regards, Prasad


[AYIU]: Since the <catch> with optionalFaultData attribute will catch a fault with or without fault data, we will face an un-initialized variable, if we allow a faultVariable attribute and the fault is thrown without fault data. That may create some unnecessary headach / usability for users.

And, the way I interprete the usage of optionalFaultData attribute is: people want to catch a particular fault with or without fault data and they don't care about the fault data. Hence, they don't need to have a variable to hold the fault data.

If one needs to get a hold of fault data, they would make use of faultVariable and (faultMessageType or faultElement) (Issue 12?) without using optionalFaultData attribute.

Does the above make sense to you?



Thanks!


Regards,
Alex Yiu




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




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