W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2001

RE: [soapbuilders] question re: namespace hierarchies

From: Frystyk <frystyk@w3.org>
Date: Fri, 20 Apr 2001 16:11:43 -0700
To: <dick@8760.com>, <soapbuilders@yahoogroups.com>
Cc: <xml-dist-app@w3.org>
Message-ID: <79107D208BA38C45A4E45F62673A434D0297CB49@red-msg-07.redmond.corp.microsoft.com>

>The SOAP 1.1 spec says the following about SOAPAction:
>"6.1.1 The SOAPAction HTTP Header Field
>The SOAPAction HTTP request header field can be used to 
>indicate the intent of the SOAP HTTP request. The value is a 
>URI identifying the intent. SOAP places no restrictions on the 
>format or specificity of the URI or that it is resolvable. An 
>HTTP client MUST use this header field when issuing a SOAP 
>HTTP Request."
>Can you explain why you feel ebXML must use an absolute URI 
>for SOAPAction, given the above description of SOAPAction 
>within the SOAP spec.

Certainly, the reason is that the consequence of the ebXML spec defining
the relative URI "ebxml" is that this implies that all URIs ending in
"ebxml" identify the same thing (the contents being an ebXML message).
Examples are


Because the relative URI "ebxml" has to be expanded against the
request-URI of the HTTP request. I don't think the guys owning the
namespaces above are likely to agree with this :)

This is not really a SOAP problem but a URI problem in that it breaks
the URI model [1][2]. The fix is for ebXML to use a single globally
unique URI which means that the value in 99.99999% of the case will have
to be absolute because the request-URI will have nothing in common with
the ebXML URI.

This will also ensure that other parties won't start to use URIs ending
in "ebxml" over which you have no control and that doesn't mean what the
ebXML specs defines it to mean. In other words, using a globally unique
URI ensures that ebXML won't run into name conflict problems later on.

Hope this helps,


[1] http://www.w3.org/DesignIssues/Model.html
[2] http://www.normos.org/ietf/rfc/rfc2396.txt
Received on Friday, 20 April 2001 19:14:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:12 UTC