- From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- Date: Thu, 21 Feb 2002 09:44:41 -0800
- 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 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
Received on Thursday, 21 February 2002 13:30:34 UTC