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

Chris,

>I read Stuart's email, and I just don't see that he's 
>suggesting that a node might silently fail w/r/t the SOAP 
>processing model.

The place I am pointing to in Stuart's mail is towards the end where it
says

>My conclusion is that the revised proposal, "If processing is
unsuccessful,
>at-most one fault MAY be generated by the node." is appropriate on two
>grounds:
>
>a) Some failure conditions permit or advise, but do not mandate
>  the generation of a fault.
>
>b) It is not clear the the failure to generate an optional
>  (and even a mandatory) fault lead to interoperability
>  problems that would necessitate a MUST.

Maybe I am misreading this but a) seems to indicate that it should be
possible to have some fault case as part of processing a SOAP message
that doesn't call for generating a fault. The reason why this makes me
nervous is that we as stated in my earlier mail describe in section 2
what it means to understand and this is the particular context in which
this text is to be read.

Rather than bringing in question whether to generate a fault or not, I
propose that we say who is responsible for defining the fault states. In
the SOAP 1.2 itself, we define some fault states covering specific
situations (e.g. DTDNotAllowed). For header blocks and body contents it
is up to the people defining the semantics for SOAP blocks and body
contents to define fault states (e.g. credit card number not valid).
This is the purpose of the proposed formulation (repeated here for
convenience):

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

Henrik

Received on Thursday, 21 February 2002 14:58:15 UTC