Re: Comments on issue 101

Seems to me that SOAP1.2 should have an answer that
ensured consistent (and hence interoperable) handling
of "misunderstood" Body blocks.

	4.3.1 Relationship between SOAP Header and Body

	"The relationship between a SOAP body block and a SOAP header
	block is as follows: a SOAP body block is semantically equivalent
	to a SOAP header block targeted at the default actor and with a
	SOAP mustUnderstand attribute information item with a value of true."

Semantically equivalent is I believe the key phrase:

semantically
	1. Of or relating to meaning, especially meaning in language.

equivalent:
          1. Equal, as in value, force, or meaning.
          2. Having similar or identical effects.

This suggests that to be semantically equivalent, that the SOAP Body
block(s) would receive equal treatment with regards to mustUnderstand
(as well as actor). The spec fragment that Henrik cited
specifically calls out "immediate child element information item
of the SOAP Header element information item..." which seems to me to
be inconsistent treatment of what it means to mustUnderstand because
the definition of a SOAP block is:

	SOAP block

     	A syntactic construct or structure used to delimit data that
	logically constitutes a single computational unit as seen by a
	SOAP node. The type of a SOAP block is identified by the fully
	qualified name of the outer element for the block, which consists
	of the namespace URI and the local name. A block encapsulated
	within the SOAP header is called a header block and a block
	encapsulated within a SOAP body is called a body block.

And later in section 4.2.3 it discusses mustUnderstand in terms of
SOAP blocks, not explicitly SOAP header blocks.

It would seem to me to be appropriate that a SOAP processor that
did not recognize/understand a SOAP body block would return a mustUnderstand
Fault because that is precisely what the situation would be should
a SOAP node, acting in the default actor role receive a message
that contained a SOAP block (header or body) that it did not understand.

I think that either the spec needs to be cleared up in this regard
(is there a real distinction between SOAP header and body blocks?) or else,
we need to rethink whether the SOAP body blocks are indeed semantically
equivalent to a SOAP header block with mU and default actor (the
syntactic sugar argument).

Cheers,

Chris
Henrik Frystyk Nielsen wrote:

> Thinking more about this I think I was too quick on the trigger. While
> SOAP implementations in many cases dispatch the complete contents of the
> Body element to some "application", the processing model is in fact
> consistent in that all body blocks have to be understood in order for
> the SOAP processor to process the message successfully.
> 
> I don't think it makes sense to say that body faults can cause
> mustUnderstand faults simply because this is not how the mustUnderstand
> fault is defined [1]:
> 
> "An immediate child element information item of the SOAP Header element
> information item that was either not understood or not obeyed by the
> processing party contained a SOAP mustUnderstand attribute information
> item with a value of "true" (see 4.2.3 SOAP mustUnderstand Attribute)"
> 
> In other words, I don't think there is any inconsistency in saying that
> we have a set of body blocks and that they are equivalent to header
> blocks with default actor and mustUnderstand set to true. That the
> mustUnderstand may be interpreted by different parties in any given
> implementation is outside the scope of this specification.
> 
> A question is whether we would want to have a Client.Body fault or some
> such to indicate in a generic manner that the body was not understood.
> 
> Hope this is more clear
> 
> Henrik
> 
> 
>>Am I right in this understanding? I think this example should 
>>be written in the spec or in the primer because it makes clear 
>>that there is no issue about "understanding" (as in mU) of the 
>>RPC calls because the receiver has to "understand" env:Body 
>>and not m:GetLastTradePrice and thus an unknown method is not 
>>an mU fault as has been suggested a few times. 8-)
>>
> 
> [1] http://www.w3.org/TR/2001/WD-soap12-part1-20011002/#soapfault
> 
>

Received on Wednesday, 31 October 2001 14:34:59 UTC