- From: Hugo Haas <hugo@w3.org>
- Date: Thu, 27 Oct 2005 16:22:50 +0200
- To: www-ws-desc@w3.org, Jonathan Marsh <jmarsh@microsoft.com>
- Message-ID: <20051027142250.GH21550@w3.org>
I have implemented LC315's resolution in Part 2 (modulo Jacek's approval on [1]). I realized that, when we changed the HTTP Header component, we hadn't changed the IRI identification. Here is what I did: 6.6.6 IRI Identification Of A HTTP Header component WSDL Version 2.0 Part 1: Core Language [WSDL 2.0 Core Language] defines a fragment identifier syntax for identifying components of a WSDL 2.0 document. An HTTP Header component can be identified using the wsdl.extension XPointer Framework scheme: wsdl.extension(http://www.w3.org/@@@@/@@/wsdl/http, whttp.header(parent/name)) 1. parent is the pointer part of the {parent} component, as specified in WSDL Version 2.0 Part 1: Core Language. 2. name is the {name} property value. In order to do this, we need a unique {name} value per {parent}. As we are already saying: If an HTTP header field corresponding to the value of {name} property is set by a mechanism other than the HTTP binding, such as the HTTP stack or another feature, then an error MUST be raised. I added the following: It is an ERROR for a Binding Message Reference or a Binding Fault component's {http headers} property to contain multiple HTTP Header components with the same {name} property. Note that RFC2616 says: Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. I don't see this as a problem. Jonathan, can we check the WG is happy with this? Cheers, Hugo 1. http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0053.html -- Hugo Haas - W3C mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
Received on Thursday, 27 October 2005 14:22:55 UTC