Issue - 93 - Proposal For Vote

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

Issue 93 - Use of XML types in faults

Proposal: Make it possible to throw and catch faults whose fault data is 
defined by a XML variable.

Rationale: We current require that fault data values MUST be WSDL 
message type variables which is a heavyweight requirement for someone 
just wanting to throw a local fault.

Changes Required: Add a faultType and faultElement attributes for use 
with catch.

Sections 6.2, 11.3 and 13.4

Change schema from:

<faultHandlers>?
       <!-- there must be at least one fault handler or default -->
      <catch faultName="qname"? faultVariable="ncname"?
                                faultMessageType="qname"?>*
         activity
      </catch>
      <catchAll>?
         activity
     </catchAll>
</faultHandlers>

to:

<faultHandlers>?
       <!-- there must be at least one fault handler or default -->
      <catch faultName="qname"? faultVariable="ncname"?
                                faultMessageType="qname"?
                                faultType="qname"?
                                faultElement="qname"?>*
         activity
      </catch>
      <catchAll>?
         activity
     </catchAll>
</faultHandlers>

Section 13.4

From: The faultMessageType is technically redundant when the faultName 
used is derived from a WSDL 1.1 fault message defined as a fault 
response to a synchronous operation, since the WSDL fault response has a 
defined message type.  The faultMessageType is technically redundant 
when the faultName used is derived from a WSDL 1.1 fault message defined 
as a fault response to a synchronous operation, since the WSDL fault 
response has a defined message type.  However, the faultName may reflect 
a purely internal custom fault in a process, or the faultName may be 
missing.  In such cases, the faultVariable, which is local to the fault 
handler and declared by its occurrence in the catch element, will not 
have a defined type.  To avoid this possibility, although the faultName, 
faultVariable and faultMessageType attributes are all optional, the 
faultVariable and faultMessageType declarations go together, i.e., they 
must either both be present or both absent.  Moreover, the faultName and 
faultVariable attributes cannot both be absent.

To: Data thrown with a fault can be of any of BPEL’s supported variable 
declaration types, WSDL message type, XML schema simple or complex type 
and XML schema element. Each catch which specifies a faultName can only 
catch a fault of a single type. This one-to-one relationship is 
necessary in order to guarantee proper typing. If the data to be caught 
is a WSDL message type then the faultMessageType attribute MUST be used 
to specify the message type’s qname. If the data to be caught is a XML 
simple or complex type then the faultType attribute MUST be used to 
specify the type’s qname. If the data to be caught is a XML element 
definition then the faultElement attribute MUST be used to specify the 
element definition’s qname.

The faultName may reflect a purely internal custom fault in a process, 
or the faultName may be missing.  In such cases, the faultVariable, 
which is local to the fault handler and declared by its occurrence in 
the catch element, will not have a defined type. To avoid this 
possibility the following rules must be observed when using the 
attributes specified for use on a catch element:
•	A faultVariable attribute MUST NOT appear on a catch element unless 
exactly one of the following three attributes is also used on the catch 
element: faultMessageType, faultType or faultElement.
•	faultMessageType, faultType and faultElement attributes MUST NOT be 
used on a catch element without the faultVariable attribute also being 
present on the element.
The previous rules thus ensure that all fault variables will be typed. 
The faultMessageType attribute MUST only be used to specify the name of 
a WSDL message type

From: 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.

To: If the fault has associated fault data, a catch activity specifying 
a matching faultName value and a faultVariable whose type matches the 
type of the fault’s data will be selected if present.

Section C

From:
     <complexType name="tCatch">
         <complexContent>
             <extension base="bpws:tActivityOrCompensateContainer">
                 <attribute name="faultName" type="QName"/>
                 <attribute name="faultVariable" type="NCName"/>
                 <attribute name="faultMessageType" type="QName"/>
             </extension>
         </complexContent>
     </complexType>
To:
     <complexType name="tCatch">
         <complexContent>
             <extension base="bpws:tActivityOrCompensateContainer">
                 <attribute name="faultName" type="QName"/>
                 <attribute name="faultVariable" type="NCName"/>
                 <attribute name="faultMessageType" type="QName"/>
                 <attribute name="faultType" type="QName"/>
                 <attribute name="faultElement" type="QName"/>
             </extension>
         </complexContent>
     </complexType>