RE: [wsbpel] Issue - 280 - Proposal to Vote

["Mark Ford" <mark.ford@active-endpoints.com>]

+1

The existing specification text is ambiguous with respect to determining the
type of the fault data. This proposal clarifies that the type of the fault
data will be determined by the declared type of the message part or variable
used to throw the data. This clarification makes it easy to add support for
throwing and catching schema types in addition to elements and messages. 


-----Original Message-----
From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com] 
Sent: Friday, June 23, 2006 1:24 PM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue - 280 - Proposal to Vote


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.