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

Is there any need to indicate that this is also independent from 
the role at which the headers are targetted, or is this obvious 
from the context?

Ie. no difference between:
      <a:A role="r1">header instance 1</a:A>
      <a:A role="r1">header instance 2</a:A>

and:
      <a:A role="r1">header instance 1</a:A>
      <a:A role="r2">header instance 2</a:A>

Jean-Jacques.

Henrik Frystyk Nielsen wrote:
> 
> 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 Wednesday, 23 October 2002 04:25:52 UTC