RE: Updated proposal for issue 192

Hi Henrik,

> -----Original Message-----
> From: Henrik Frystyk Nielsen [mailto:henrikn@microsoft.com]
> Sent: 09 April 2002 23:33
> To: xml-dist-app@w3.org
> Cc: noah_mendelsohn@us.ibm.com; moreau@crf.canon.fr
> Subject: Updated proposal for issue 192
>
>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. 

I had an offlist discussion with Gudge about the unqualified element names
used within the content of an <env:Fault/>. It seems clear that there is
no-ambiguity here. These are locally scoped, unqualified elements whose
'meaning' is scoped by their containment in a <env:Fault/> element.

I think there is a stylistic choice to be made... but I don't think that
quailifying the names of these elements is essential. "Clean-up" suggests
brokenness which I don't think is the case here. 

The downside to retaining unqualified element names is being very sure to
unset any inscope default namespaces at the appropriate times... which, as I
demonstrated in my exchange with Gudge, can easily be done wrong :-)

Personnally I have a preference for the status-quo with unqualifed element
names.

Regards

Stuart



> 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 08:33:44 UTC