W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2002

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

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Tue, 12 Feb 2002 13:22:59 -0800
Message-ID: <79107D208BA38C45A4E45F62673A434D05A53FF7@red-msg-07.redmond.corp.microsoft.com>
To: "Noah Mendelsohn" <noah_mendelsohn@us.ibm.com>
Cc: <xml-dist-app@w3.org>

>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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:06 GMT