RE: Proposal for SOAP 1.2 LC-Issue 371: Multiple Choice Assertions

I like the gist but think your proposal might imply more than we require
with the sentence "a given node must consistently understand or not
understand any header blocks that share a common qualified name within a
single message." The scenario is this:

<S:Envelope xmlns:S="http://www.w3.org/2002/06/soap-envelope">
  <S:Header xmlns:a="http://example.com/foo">
    <a:A>header instance 1</a:A>
    <a:A>header instance 2</a:A>
  </S:Header>
  <S:Body>
    <foo>some message content</foo>
  </S:Body>
</S:Envelope>

If the two header block instances with identical qualified names are
optional, then I don't think we have a requirement on whether the SOAP
receiver MUST process either none or both. In other words, it would seem
ok to process one and ignore the other even if they are both
"understood".

If one or both are marked with a mU=true then the situation changes in
that the sender explicitly requires the marked header block(s) to be
understood and hence processed. Given this perceived link between
"understanding" and "processing", people might easily think that we
don't allow the scenario above where one instance is processed and one
is ignored.

As a result (and given that we define "understanding" separately in
section 2.4), I would be happier if we use this instead in section 2.6:

<2.6_UpdatedProposal>
In all cases where a SOAP header block is processed, the SOAP node MUST
understand the SOAP header block and MUST do such processing in a manner
fully conformant with the specification for that header block. The
successful processing of one header block does not guarantee successful
processing of another block with the same fully qualified name within
the same message: the specification for the header block determines the
circumstances in which such processing would result in a fault."
</2.6_UpdatedProposal>

We could then, if need be, clarify the other part saying that
understanding must be consistent in section 2.4:

<2.4_Original>
A SOAP header block is said to be understood by a SOAP node if the
software at that SOAP node has been written to fully conform to and
implement the semantics conveyed by the combination of [local name] and
[namespace name] of the outer-most element information item of that
header block.
</2.4_Original>

<2.4_UpdatedProposal>
A SOAP header block is said to be understood by a SOAP node if the
software at that SOAP node has been written to fully conform to and
implement the semantics conveyed by the combination of [local name] and
[namespace name] of the outer-most element information item of that
header block. When processing a message, a SOAP node MUST consistently
either understand or not understand any header blocks that share a
common qualified name within that message (see 2.6 Processing SOAP
Messages).
</2.4UpdatedProposal>

I think this maintain a better separation and also is more consistent
with our discussion of roles in section 2.2 (which is in a similar
situation).

Comments?

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

><proposed>
>"In all cases where a SOAP header block is processed, the SOAP 
>node MUST 
>understand the SOAP header block and MUST do such processing 
>in a manner 
>fully conformant with the specification for that header block; because 
>understanding is a function of the qualified name of the 
>header (see 2.4 
>Understanding SOAP Header blocks), a given node must consistently 
>understand or not understand any header blocks that share a common 
>qualified name within a single message.  Nonetheless, the successful 
>processing of one header block does not guarantee successful 
>processing of 
>another block with the same fully qualified name within the 
>same message: 
>the specification for the header determines the circumstances in which 
>such processing would result in a fault."
></proposed>

Received on Tuesday, 22 October 2002 14:05:32 UTC