[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 280 - Proposal to Vote
(resend the response to the correct email thread) Hi Dieter, -1 to the proposal. Copied from the word doc: ====================== - paragraph
after the fault catching rules, from: Matching
the type of a faultVariable to fault data as mentioned in points #1 and #4
above is
more restrictive than in points #2 and #5. A WSDL message type variable
can
only match a WSDL message type fault data, while an element variable
can only
match element based fault data. They match only when their QNames are
identical. to: ====================== As mentioned before, this proposal essentially create a psuedo-data-model in BPEL which treat type always *static*. This static psudo-data-model significantly contradicts:
The not-well-founded urge to quest for skin-deep-level symmetry in <catch> will abrupt the future adoption of other standards. I would prefer Mark Ford's original proposal. Mark Ford's proposal is just a bug fix/clarification, while Dieter's proposal is definitely a new feature. That really violates the practice that we should ONLY do clarification/bug-fix in this stage of specification. And, this <catch> with "type" discussion was discussed way back when Yaron suggested to add "element" . It was a conscious decision that we do NOT add type related feature to <catch> to stay way from type related complexities: inheritance and polymorphism complexities. Thank you! Regards, Alex Yiu Dieter Koenig1 wrote: Also as Word-File to highlight the changes: http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/18915/Issue%20280%20-%20Proposal%20for%20Vote.doc Proposal for vote (Issue 280) Change the syntax descriptions of <catch> from: <catch faultName="QName"? faultVariable="NCName"? faultMessageType="QName"? faultElement="QName"?>* activity </catch> to: <catch faultName="QName"? faultVariable="NCName"? faultMessageType="QName"? faultElement="QName"? faultType="QName"?>* activity </catch> This change has to be done in: - Section 5.2, basic structure of <process> - Section 5.2, basic structure of <invoke>) - Section 10.3, syntax of the <invoke> activity - Section 12.5, syntax of <faultHandlers> Change in section 12.5: - paragraph 7 and 8, from: Data thrown with a fault can be a WSDL message type or a XML schema element. Each <catch>, which specifies a QName as its faultName attribute value, can only catch a fault matching that particular QName. This one-to-one relationship is necessary in order to guarantee proper targeting for fault catching. If the data to be caught is a WSDL message then the faultMessageType attribute is used to specify the message type’s QName. If the data to be caught is a XML element then the faultElement attribute is used to specify the element definition’s QName. To have a defined type associated with the fault variable, the faultVariable attribute MUST only be used if either the faultMessageType or faultElement attributes, but not both, accompany it. The faultMessageType and faultElement attributes MUST NOT be used unless accompanied by faultVariable attribute. to: Data thrown with a fault can be a WSDL message type, a XML schema element or a XML schema type. Each <catch>, which specifies a QName as its faultName attribute value, can only catch a fault matching that particular QName. This one-to-one relationship is necessary in order to guarantee proper targeting for fault catching. If the data to be caught is a WSDL message then the faultMessageType attribute is used to specify the message type’s QName. If the data to be caught is a XML schema element, then the faultElement attribute is used to specify the element declaration's QName. If the data to be caught is a XML schema type, then the faultType attribute is used to specify the type definition’s QName. To have a defined type associated with the fault variable, the faultVariable attribute MUST only be used if exactly one of the faultMessageType, faultElement or faultType attributes accompany it. The faultMessageType, faultElement or faultType attributes MUST NOT be used unless accompanied by faultVariable attribute. - fault catching rule 1 with associated data, from: If there is a <catch> construct with a matching faultName value that has a faultVariable whose type matches the type of the fault data then the fault is passed to the identified <catch> construct. to: If there is a <catch> construct with a matching faultName value that has a faultVariable whose declared type matches the declared type of the fault data then the fault is passed to the identified <catch> construct. - fault catching rule 4 with associated data, from: Otherwise if there is a <catch> construct without a faultName attribute that has a faultVariable whose type matches the type of the fault data then the fault is passed to the identified <catch> construct. to: Otherwise if there is a <catch> construct without a faultName attribute that has a faultVariable whose declared type matches the declared type of the fault data then the fault is passed to the identified <catch> construct. - paragraph after the fault catching rules, from: Matching the type of a faultVariable to fault data as mentioned in points #1 and #4 above is more restrictive than in points #2 and #5. A WSDL message type variable can only match a WSDL message type fault data, while an element variable can only match element based fault data. They match only when their QNames are identical. to: Matching the declared type of a faultVariable to the declared type of the fault data as mentioned in points #1 and #4 above is based on QName matching of the declared variable types. This means, if a variable declared with element type tns:bar is thrown, a catch with faultElement="tns:bar" will catch it. - paragraph after the fault catching example, from: Assume that a fault named ”x:foo” is thrown from within the scope to which this <faultHandlers> construct is attached. The first <catch> will be selected if the fault carries no fault data. If there is fault data associated with the fault, the third <catch> will be selected if and only if the type of the fault’s data matches the type of variable “bar”, otherwise the <catchAll> fault handler will be selected. Finally, a fault with a fault variable whose type matches the type of “bar” and whose name is not “x:foo” will be processed by the second catch. All other faults will be processed by the <catchAll> fault handler. to: Assume that a fault named ”x:foo” is thrown from within the scope to which this <faultHandlers> construct is attached. The first <catch> will be selected if the fault carries no fault data. If there is fault data associated with the fault, the third <catch> will be selected if and only if the declared type of the fault’s data matches the declared type of variable “bar”, otherwise the <catchAll> fault handler will be selected. Finally, a fault with a fault variable whose declared type matches the declared type of variable “bar” and whose name is not “x:foo” will be processed by the second catch. All other faults will be processed by the <catchAll> fault handler. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]