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

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
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?

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

Henrik