RE: New issue: Default values of SOAP header block attributes

>I think this is very good overall.  Suggestion:  let's line 
>this up with 
>Mark's proposed rewrite of section 2 to introduce the 
>"ultimateReceiver" 
>attribute. 

Thank you and yes, I agree on the attribute value.

>==============================
><insteadOf>
>Omitting the SOAP actor attribute information item implicitly 
>targets the SOAP header block at the ultimate SOAP receiver. 
>An empty value for this attribute is equivalent to omitting 
>the attribute completely, i.e. targeting the block at the 
>ultimate SOAP recipient. </insteadOf>
>
><suggestedAlternative>
>Omitting the SOAP role attribute information item is 
>equivalent to supplying that attribute with a value of 
>"http://www.w3.org/2001/12/soap-envelope/role/ultimatereceiver".
>An empty value for this attribute is equivalent to omitting the 
>attribute completely, i.e. targeting the block at the ultimate 
>SOAP recipient.
></suggestedAlternative>

ok

>If you prefer, this could be integrated in chapter 4, which would be 
>symmetric with mU.  In this particular case, I think we should 
>at least 
>provide a mention in chapter 2, as targeting the endpoint with 
>a missing 
>role attribute will be a very common idiom.  Perhaps chapter 
>would say: 
>NOTE that section 4.x mandates a default value of 
>i"http://www.w3.org/2001/12/soap-envelope/role/ultimatereceiver
>" if the role attribute is missing.

Yes
 
>==============================

>I think the warning on schema 
>validation can be interpreted as ruling out 
>the need to validate even application level structures.  That 
>presumably 
>was not your intent. Also, with the infoset formation, we 
>shouldn't be 
>saying what's serialized, as that's at the discretion of the binding. 
>Indeed, if a binding wants to optimize out defaults on the 
>wire, we can't 
>see that, as long as it's recreated in the received infoset.  So, I've 
>changed "serialized" to "transmitted".
>
><insteadOf>
>A SOAP message MUST NOT impose any XML schema processing 
>(assessment and
>validation) requirement on the part of any receiving SOAP node 
>in order to correctly process a SOAP message according to the 
>processing rules defined in section 2. Unless explicitly 
>stated otherwise, SOAP REQUIRES that all information items 
>that affect the SOAP processing model, whether specified in 
>this specification or whether they belong to a foreign 
>namespace be carried in the serialized SOAP envelope.
></insteadOf>
>
><suggestedAlternative>
>A SOAP message MUST NOT require any W3C XML schema processing 
>(assessment or validation) in order to establish the values or 
>correctness of element and attribute information items 
>explicitly used in this specification.  These information 
>items, which include mustUnderstand, role, the qualified names 
>of header blocks, etc. must be carried explicitly in the 
>transmitted SOAP envelope.
>
>Specifications for the processing of particular SOAP header 
>blocks or body entries MAY but NEED NOT call for additional 
>validation of the SOAP message in conjunction with application 
>level processing.  In such cases, the choice of schema 
>language and/or validation technology is at the discretion of 
>the application. discretion of the application.
></suggestedAlternative>

>Do these suggestions make sense?

Yes, I agree

Thank you!

Henrik

Received on Tuesday, 12 February 2002 16:23:34 UTC