Re: Updated proposal for issue 192

+1!

Noah Mendelsohn/Cambridge/IBM wrote:

> +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 Wednesday, 10 April 2002 03:23:23 UTC