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?
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
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
|