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 faultElement attribute for use with catch.

Change Since Previous Proposal: Removed the faultType attribute. 
Throwing complex types as faults is vaguely odd and WS-I requires that 
all SOAP faults be defined using elements so in general Web Services 
faults are typically elements anyway.

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"?
                                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 a WSDL message type or a 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 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 faultVariable MUST only be used if either the 
faultMessageType or faultElement attributes, but not both, accompany it. 
faultMessageType and faultElement MUST NOT be used unless accompanied by 
faultVariable.

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="faultElement" type="QName"/>
             </extension>
         </complexContent>
     </complexType>