Re: Updated proposal for issue 192

+1, at least that's my initial reaction.  Thanks.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"Henrik Frystyk Nielsen" <henrikn@microsoft.com>
04/09/2002 06:33 PM

 
        To:     <xml-dist-app@w3.org>
        cc:     <noah_mendelsohn@us.ibm.com>, <moreau@crf.canon.fr>
        Subject:        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:46:45 UTC