Re: Fault definitions missing from XSD

Andy,

You asked "why are the faults not declared in the relevant <portType> 
declarations?" The answer lies in the juxtaposition of some of the 
conventions used in WS-* and the mapping between WSDL-defined faults and 
SOAP.

The convention in most (all?) WS-* specs is to define faults in terms of 
five abstract properties: [Action], [Code], [Subcode], [Reason], and 
[Detail]. Of these [Subcode] is the primary designator as [Action] is 
usually the same for all the faults in a single spec and [Code] is 
almost always "Sender". The mapping of these properties to SOAP is also 
pretty uniform across WS-* specs. For SOAP 1.1:

<s11:Envelope>
<s12:Header>
<wsa:Action>*[Action]*</wsa:Action>
<!-- Headers elided for brevity. -->
</s12:Header>
<s11:Body>
<s11:Fault>
<faultcode>*[Subcode]*</faultcode>
<faultstring xml:lang="en">*[Reason]*</faultstring>
<detail>
*[Detail]*
         ...
</detail>
</s11:Fault>
</s11:Body>
</s11:Envelope>

It is considered reasonable/mainstream practice for WS-* 
implementations, when processing SOAP Fault messages, to use the QName 
of the value of the [Subcode] property (found in s11:Fault/faultcode or 
s12:Fault/s12:Code/s12:Subcode/s12:Value) to distinguish between the 
various error conditions. There would need to be a compelling reason for 
the WS-RA specs to depart from this convention, since anyone involved in 
implementing WS-* specs is not only accustomed to it, they probably have 
some common fault handling code that depends on it.

With regards to how WSDL-defined faults are mapped to SOAP fault 
messages, please refer to the Purchase Order scenario in the WSTF: 
http://www.wstf.org/docs/scenarios/sc009/sc009.xml. The WSDL for that 
scenario defines wsdl:faults for its operations. Here is an example of a 
SOAP 1.1 fault message that conforms to that interface:

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Action">http://www.w3.org/2005/08/addressing/fault</wsa:Action>
       . . .
</env:Header>
<env:Body>
<env:Fault>
<faultcode>env:Server</faultcode>
<faultstring/>
<detail>
<sc0:POFault xmlns:sc0="http://www.wstf.org/docs/scenarios/sc009">
<sc0:OrderFaultCode>NoSuchOrder</sc0:OrderFaultCode>
<sc0:OrderFaultComment>Unable to find order with ID 
'urn:uuid:cdce1080-a749-11e0-8264-0800200c9a66' in the 
system.</sc0:OrderFaultComment>
</sc0:POFault>
</detail>
</env:Fault>
</env:Body>
</env:Envelope>

Notice (a) that the <faultcode> value is "Server" and (b) we had no 
visibility/control of this value in our WSDL. Notice also that the 
message defined by "POFault" in our WSDL appears as a child of the 
<detail> element. To carry our [Subcode] property via a WSDL-defined 
fault message we would have to include it as some element within the 
message element that appears as the child of <detail>. This would be 
different from virtually every other WS-* spec. As stated previously, we 
don't want to depart from the usual WS-* conventions for defining faults 
without a compelling reason and we don't feel that the benefits of 
defining faults in WSDL (e.g. auto-generation of exception classes) are 
compelling enough to warrant such a departure.

~ gp