W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2002

RE: Issue 182: Fault Code restriction: "At Most One Fault Proposal"

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Thu, 21 Feb 2002 09:44:41 -0800
Message-ID: <79107D208BA38C45A4E45F62673A434D067C84F8@red-msg-07.redmond.corp.microsoft.com>
To: "Williams, Stuart" <skw@hplb.hpl.hp.com>
Cc: <xml-dist-app@w3.org>

In section 2.4, 2.5, and 2.6, we talk about "understanding" header
blocks and understanding bodies to the extend that we can integrate them
into our processing model. A SOAP node can claim to understand a block
or a body if it knows the semantics of that block or body.

As part of understanding comes knowledge about when to fail. All I am
saying is that we make it clear that when a failure state is reached we
know how it impacts the overall SOAP processing. The way we have done
this so far is to say that the SOAP node must generate a fault. 

Note that we don't say what to do with the fault - it may be returned to
the sender, sent somewhere else, or simply discarded - the
particularities of what to do with generated faults is a function of the
message exchange pattern and possibly other things. Maybe I am missing
something but why does this not cover case b)?

>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).

>> "In all cases where a SOAP header block is processed, the SOAP node
>> understand the SOAP block and must do such processing in a manner
>> conformant with the specification for that block. The ultimate
>> 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
>> 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?

Then for all we know, it is not a fault.

Received on Thursday, 21 February 2002 13:30:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:18 UTC