Updated proposal for issue 192

I took an action item to try and summarize the discussion on issue 192 [0]. Although I hope I am being fair in my summary (and proposal) all the views being presented in the various threads, the discussion has gone on for a very long time. I therefore apologize if I have left things out and represented them in an incomplete manner. If you find things that are truly essential to resolving issue 192 and not represented here then please fill in.

Summary of Issues
-----------------

0) How to identify a SOAP fault in general

The question was brought up on how one can identify a SOAP fault so that one can use it in contexts outside a SOAP envelope, i.e. as a piece of data

1) How to identify a fault in a SOAP message

How it is possible to unambigously identify a SOAP fault as *the* fault of a SOAP message and not just a piece of data.

2) How a SOAP fault relates to the SOAP processing model

What is the relationship between the SOAP processing model defined in section 2 [3]?

3) How a soap fault interacts with underlying protocols

In particular, the question of how to deal with SOAP faults in the SOAP HTTP binding

4) Syntactic representation of a SOAP fault

Various proposals have been discussed for how to represent a SOAP message. Several people have pointed out inconsistencies in the current structure of a SOAP fault as opposed to the structure of the envelope itself: it doesn't use qualified names, it uses different casing (all lower-case), etc.

Proposal
--------

The following proposal attempts to address the 6 items above by providing an outline for what may be described in the SOAP 1.2 specification. This is not directly intended as text for the specification, but as an outline of the direction:

0) Use the text already in SOAP 1.2, part 1 [1] for identifying a SOAP fault, that is, a SOAP fault has the local name "Fault" and the namespace URI "http://www.w3.org/2001/12/soap-envelope <http://www.w3.org/2001/12/soap-envelope> ".

1) As to the question of determining when a SOAP fault is recognized as an "active" fault in a SOAP message by referring to the text already in SOAP 1.2, part 1 [1]:

"To be recognized as carrying SOAP error information, a SOAP message MUST contain exactly one SOAP Fault as the only child element of the SOAP body. A SOAP fault element information item MAY appear within a SOAP header block, or as a descendant of a child element information item of the SOAP body; but, in such cases, the element has no SOAP-defined semantics."

2) Keep the description of a SOAP body in section 2.5 [2] as being "opaque" from a basic SOAP processing perspective. Section 2.5 currently says:

"An ultimate SOAP receiver MUST correctly process the immediate children of the SOAP body (see 5.3 SOAP Body). However, Part 1 of this specification (this document) mandates no particular structure or interpretation of these elements, and provides no standard means for specifying the processing to be done."

Then as the next step go on and clarify that as one particular SOAP body "type", we define a SOAP fault which completely describes the semantics and structure of a SOAP fault (see also proposals for point 0) and 1))

3) Use the proposal listed in [4] for using corresponding HTTP fault codes and SOAP fault codes. Say that a sender MUST use these HTTP status codes in order to comply with the SOAP HTTP binding. A sender that doesn't do this is broken in the same way a sender that includes a DTD is broken. Given the discussion around this issue in particular, I suggest that we add a note or a warning saying that implementers of SOAP receivers are encouraged to detect broken SOAP senders that does not conform to the SOAP HTTP binding.

4) Several things have been brought up on this issue: I propose the following "cleanup" of the SOAP representation: 

    a) use qualified names
    b) be consistent in our how names are cased: for example

use "Reason" instead of "faultstring" etc. 

Comments?

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com <mailto:henrikn@microsoft.com>  

[0] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x192 <http://www.w3.org/2000/xp/Group/xmlp-issues.html#x192> 
[1] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#soapfault <http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#soapfault> 
[2] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#structinterpbodies <http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#structinterpbodies> 
[3] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#msgexchngmdl <http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#msgexchngmdl> 
[4] http://lists.w3.org/Archives/Public/xml-dist-app/2002Apr/0026.html <http://lists.w3.org/Archives/Public/xml-dist-app/2002Apr/0026.html>

Received on Tuesday, 9 April 2002 18:33:44 UTC