Action 174 - Send some reference links to the mailin list to support this proposal

See

http://specs.xmlsoap.org/ws/2005/02/sc/WS-SecureConversation.pdf, section 10
http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509/#id2270287
section 6.2
http://schemas.xmlsoap.org/specs/ws-security/ws-security.htm#ws-security__toc6201567, section 6



http://ws-i.org/profiles/BasicProfile-1.2-WGD.html, section 3.4, 3.4.6



-----Original Message-----
From: Peter Easton 
Sent: Monday, May 24, 2010 6:39 PM
To: 'public-soap-jms@w3.org'
Subject: ACTION-168 - Develop a more detailed proposal for issue 34

Background

"Issue 34 soap-jms xsd should define fault sub-code QName types" was raised and discussed at the 5/18/2010 meeting. It was pointed out that whilst sub-code type information could be added to the current schema section in the specification, the binding of JMS fault sub-codes to SOAP 1.1 faults leads to a subtle schema difference. In the SOAP/JMS specification, JMS fault sub-code is a sub-element of the SOAP 1.1 fault detail element. In this use-case the JMS fault sub-code may have textual content. In SOAP 1.2, JMS fault sub-code appears as the SOAP 1.2 subcode element. No textual content is allowed under the subcode in here.

A Wider Issue

A more general issue arises of whether our definition of the SOAP 1.1 fault binding should be changed. 

A number of Web-Services specifications already defined fault sub-codes. All WS-Security specifications, WS-RM and WS-A define sub-codes. But their binding approach to SOAP 1.1. differs from that of the current SOAP-JMS Spec. Their approach is that the SOAP 1.1 faultcode element contains a specification-defined fault QName.

Note that WS-I Profile 1.1 appears to support both styles, e.g.

"R1004 When an ENVELOPE contains a faultcode element, the content of that element SHOULD be either one of the fault codes defined in SOAP 1.1 (supplying additional information if necessary in the detail element), or a Qname whose namespace is controlled by the fault's  specifying authority(in that order of preference)."

And WS-I gives an example....

CORRECT: 
<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'
            xmlns:c='http://example.org/faultcodes' >
  <faultcode>c:ProcessingError</faultcode>
  <faultstring>An error occured while processing the message
  </faultstring>
</soap:Fault>


Proposal

The following proposes that SOAP/JMS fault bindings for SOAP 1.1 be brought in line with the other specifications mentioned above.

For SOAP 1.1 faults, the faultcode element contains the SOAP/JMS fault sub-code. The faultstring element can contain some textual fault information.

For SOAP 1.2 faults, the current binding remains. The Fault/Code/Value is env:Sender (as defined in SOAP 1.2) and the Fault/Code/Subcode/Value is the SOAP/JMS fault sub-code. Fault/Reason/Text can contain some textual fault information.

Details

Rewrite SOAP 1.1 portion of Section 2.8 as follows:

The SOAP 1.1 specification does not support subcodes directly. In that scenario, the faultcode element should have a QName that matches the subcode for SOAP 1.2. The faultstring element can contain textual fault information. The same error as above, shown in SOAP 1.1:

Example: SOAP 1.1 Fault payload with the contentTypeMismatch subcode

<env:Envelope
     xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
   <env:Body>
       <env:Fault xmlns:soapjms="http://www.w3.org/2008/07/soap/bindings/JMS/">
           <faultcode>soapjms:contentTypeMismatch</faultcode>
           <faultstring> The content type of the JMS payload does
not match the XML</faultstring>
       </env:Fault>
   </env:Body>
</env:Envelope>

Add the following definitions to the SCHEMA section:

  <xs:simpleType name="FaultCodesType">
    <xs:restriction base="xs:QName">
      <xs:enumeration value="soapjms:contentTypeMismatch"/>
      <xs:enumeration value="soapjms:malformedRequestURI"/>
      <xs:enumeration value="soapjms:mismatchedSoapAction"/>
      <xs:enumeration value="soapjms:missingContentType"/>
      <xs:enumeration value="soapjms:missingRequestURI"/>
      <xs:enumeration value="soapjms:unrecognizedBindingVersion"/>
      <xs:enumeration value="soapjms:unsupportedJMSMessageFormat"/>
    </xs:restriction>
  </xs:simpleType>

Received on Tuesday, 25 May 2010 17:18:05 UTC