[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 93 - Proposal For Vote
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]