[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 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]