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

Hi Noah, Henrik,

Just sync'ing my mail before heading to the airport!

I think that there may be a way to bring this one to an amicable closure. 

I think our problem is that we speak of success/failure and the generation
of faults. 

In Henrik's response to me [1] he more or less states that he defines
'success' as the completion of message processing without fault generation
and 'failure' as the completion (or partial completion [see below]) of
message processing where a fault has been generated.

I think we should speak only of the message processing (in accordance with
the section 2.6 processing model) that completes with or without the
generation of a fault and avoid speaking of success and failure (which seems
to have a notion of application semantic to it).

If we do that then I would amend my proposal on 182 to:

"SOAP message processing MAY result in the generation of at-most one fault.
Header-related faults other than mustUnderstand faults MUST conform to
the specification for the corresponding SOAP header block."

I also re-iterate, as I stated in [3], that my issue with MUST is largely
due to the advice in RFC2116 quoted earlier [2]. I do not believe anyone has
yet demonstrated that the non-generation of a fault (under any
circumstances) leads to an interoperability problem.

On partial processing
---------------------
Our processing model is very clear with respect to mustUnderstand faults,
that if one arises during steps 1-3 in section 2.6 (part 1) the message MUST
NOT be processed and a single mustUnderstand fault generated.

What we are not clear about is for faults other than mustUnderstand. Whether
or not processing of the message should halt with fault generation, or
whether some best effort should be made to process as much of the message as
possible. 

Maybe it is right that we say nothing, because there is probably no right
answer in general and we have said nothing about the order in which blocks
are to be processed. However, this also leaves us with a soft notion of
success and failure eg. if processing were to continue beyond the generation
of the first fault presumably there is some notion of partial
success/failure, which as Henrik points out in [1] wrt Issue 68, we have
chosen not to address.

Regards

Stuart
--
[1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0408.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0361.html
[3] http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0386.html

> -----Original Message-----
> From: Henrik Frystyk Nielsen [mailto:henrikn@microsoft.com]
> Sent: 23 February 2002 22:51
> To: noah_mendelsohn@us.ibm.com; Williams, Stuart
> Cc: Christopher Ferris; Williams, Stuart; xml-dist-app@w3.org
> Subject: RE: Issue 182: Fault Code restriction: "At Most One Fault
> Proposa l"
> 
> +1 
> 
> Henrik
> 
> >This is in response to several comments earlier in the thread.  I read 
> >these to be generally along the lines of "why mandate exactly one fault
if 
> >in certain MEPs it will be dropped on the floor anyway" and/or the
closely 
> >related "it would be unwise to relay on it".  With respect, I disagree, 
> >and see this as reasoning inappropriately from the converse. 
> >
> >There do indeed exist cases in which the fault is not reliably delivered 
> >to anyone, and in that sense of questionable value.  However, the 
> >important point is that there are important cases in which the existence 
> >of exactly one fault or successful response is important, and may be 
> >relied upon.  Consider the HTTP binding for request response.  In 
> >practice, we open a TCP connection for the request, and the receiver
keeps 
> >that connection open.  Until when?  Until the node generates either a 
> >successful response or a fault!  If there's any question that one or the 
> >other of these will surely be generated, then we get into the business of

> >timeouts, which is a big mess IMO.    Note that this requirement is
indeed 
> >at the message level, not per header or body. 
> >
> >So, I think on balance it's a useful model to say that every message 
> >sooner or later reaches an endpoint in its processing.   That endpoint is

> >formally demarcated by the availability of some sort of result, which is 
> >either success or failure.  Modeling this as a fault seems a good idea to

> >me.
>

Received on Sunday, 24 February 2002 10:36:55 UTC