RE: Issue 182: Fault Code restriction: "At Most One Fault Proposa l"

Hi Henrik,

> -----Original Message-----
> From: Henrik Frystyk Nielsen [mailto:henrikn@microsoft.com]
> Sent: 21 February 2002 16:52
> To: Williams, Stuart; xml-dist-app@w3.org
> Subject: RE: Issue 182: Fault Code restriction: "At Most One Fault
> Proposal"
> 
> Thanks Stuart for writing this up - I realize the amount of work it is.
> I think, however, that the text we are discussing has a slightly
> different purpose than what you are implying. Section 2.6 "Processing
> SOAP messages" talks about how to process *any* SOAP message: you find
> the pieces targeted at you, you must do the mU ones, may do the rest,
> and then process according to the semantics of these pieces.
> 
> The point I was bringing up yesterday is that *if* the rules and
> semantics of a block (or the body) are not met then we must guarantee
> that the processing does not appear to be successful. The reason why
> this has an implication on interoperability is that if I don't know that
> a SOAP processor is going to fail in a specific situation, I have no
> mechanism for reliably determining the outcome of the processing and
> hence can not possibly expect to interoperate.

There a bunch of anthropmorphic 'I's in there which could be any of the
God-like 'I' looking down on the whole system from above, or any one of the
sender, receiver or intermediary 'I's. On the whole we have nothing that
ensures that a generated fault comes to the attention of anything, we have
little/no model of what a fault is intended to accomplish (with the
exception of sender faults which do advise that the same message, or a
message with the same content, should not simply be resent). I would be much
more sympathetic if there was some mechanism that we spoke about in the
specification whose operation were crutially emperiled by the absense of a
fault, but I can't put my finger on one. 

I could also argue it the other way... why just one fault per message...
that too seems artificial... if something goes wrong you could argue for the
generation of as much relevant fault information... 

> While the specific fault codes you list below describes specific cases,
> they do not cover the general case of the processing model which invokes
> the term "understand". It is perfectly valid for a header block or a
> body to define states that are not clear fault states, call them warning
> states, say, that do not result in a SOAP fault being generated. While
> the SOAP processing is indifferent to such states, if the semantics
> calls for a fault, we (as the SOAP processor) must guarantee that SOAP
> processing is deterministic.

I'm not sure that I see the contraction here, seems to me that there are
three possibilies:

	a) processing fails and generates a fault
	b) processing fails and doesn't generate a fault 
	c) processing succeeds (and doesn't generate a fault).

The way the spec is drafted today, it only allows a) and c) and specifically
excludes b).

> Maybe we can address this doing something like this (including the
> paragraph above the one we are discussing as it highly related):
> 
> "In all cases where a SOAP header block is processed, the SOAP node must
> understand the SOAP block and must do such processing in a manner fully
> conformant with the specification for that block. The ultimate recipient
> MUST process the SOAP body, in a manner consistent with 2.5 Structure
> and Interpretation of SOAP Bodies. If a block or the body cannot be
> successfully processed, the SOAP node MUST generate a fault conforming
> to the specification for the corresponding block or body being
> processed."

And if the corresponding specification does not mandate the generation of a
fault in particular circumstances that are not regarded as successful?

Also, part 1 section 2.5 actually explicity says we say nothing about the
structure and interpretation of SOAP Bodies, inronic!

<quote>
However, Part 1 of this specification (this document) mandates no particular
structure or interpretation of such elements, and provides no standard means
for specifying the processing to be done.
</quote>

> The idea of this is that we have symmetry between the MUST process
> (going from SOAP to app-defined  specification) and MUST fault (going
> from app-defined specification to SOAP).

And... the purpose of a 'generated' fault is to...? 

> 
> Comments?

I will concur with whatever the general opinion and collective wisdom
dictates here.

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

Regards

Stuart

Received on Thursday, 21 February 2002 12:22:26 UTC