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

Hello Henrik,

> -----Original Message-----
> From: Henrik Frystyk Nielsen [mailto:henrikn@microsoft.com]
> Sent: 21 February 2002 17:45
> To: Williams, Stuart
> Cc: xml-dist-app@w3.org
> Subject: 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.

Yes...

> As part of understanding comes knowledge about when to fail.

Might reword as "...comes knowledged of what constitutes failure."

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

So we're defining failure as anything which generates a fault, otherwise
apparent success?

Or equally, all failures cause a fault to be generated (by definition of
what failure is)?

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

Well the current wording, which is also retained in Marc's propoals against
182 record in the issues list, is,

	"If processing is unsuccessful, exactly one fault MUST be generated
by the node."

It think that would require pretty subtle interpretation say that it allowed
case b) ie. failure, unsucessful processing and 0 *generated* faults.

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

So maybe this is the heart of it... the use of multiple words/phrases which
may encapsulate the same or different concepts. In this discussion (and I
believe in the spec.) we have:

	unsuccessful processing
	failure
	fault [used as a verb]
	fault [used as a noun]

So... I think I see "unsuccessful processing" and "failed processing" as
synonymous, but I see the generation of a fault as a consequence of failed
processing to be optional in general. In a particular case fault generation
is inaccordance with the semantics and rules associated with the block being
processed. ie. the specification of the block being processed may insist on
the generation of a fault under particular circumstances.

> Henrik

Regrds

Stuart

Received on Friday, 22 February 2002 05:03:05 UTC