Re: Updated proposal for issue 192

+1

Gudge

----- Original Message -----
From: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
To: <xml-dist-app@w3.org>
Cc: <noah_mendelsohn@us.ibm.com>; <moreau@crf.canon.fr>
Sent: Tuesday, April 09, 2002 11:33 PM
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#structinterpbodie
s>
> [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 04:24:51 UTC