- 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