W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > January 2010

Re: issue 8196

From: Gilbert Pilz <gilbert.pilz@oracle.com>
Date: Mon, 25 Jan 2010 13:50:43 -0800
Message-ID: <4B5E1233.80905@oracle.com>
To: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
I've got a real example for method (B). It uses the "namespace-uri" 
function. So the example would look like:

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
             xmlns:wsa="http://www.w3.org/2005/08/addressing">
<s:Header>
     . . .
</s:Header>
<s:Body>
<wst:Get Dialect="http://www.w3.org/2009/09/ws-fra">
<wsf:Expression Language="http://www.w3.org/2009/09/ws-fra/XPath-Level-1">
         
/a\[namespace-uri()='http://www.example.com']/b\[namespace-uri()='http://www.example.com']
</wsf:Expression>
</wst:Get>
</s:Body>
</s:Envelope>

Again, tools could be used to convert from "ex:a" to 
"a\[namespace-uri()='http://www.example.com']"

- gp

On 1/25/2010 1:33 PM, Gilbert Pilz wrote:
> To recap: in Section 6, "XPath Level 1 Expression Language", of 
> WS-Fragment it currently says the following:
>
>     The namespace bindings are evaluated against any namespace
>     declarations that are in scope where the XPath appears within the
>     SOAP message.
>
> The concern is that a WS-Fragment request that was minted as:
>
> <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
>             xmlns:wsa="http://www.w3.org/2005/08/addressing"
> *xmlns:ex="http://www.example.com/"*>
> <s:Header>
>     . . .
> </s:Header>
> <s:Body>
> <wst:Get Dialect="http://www.w3.org/2009/09/ws-fra">
> <wsf:Expression Language="http://www.w3.org/2009/09/ws-fra/XPath-Level-1">
>         /ex:a/ex:b
> </wsf:Expression>
> </wst:Get>
> </s:Body>
> </s:Envelope>
>
> might, after "some amount of processing" (signature transformation, 
> storage, retrieval, etc.) look like this:
>
> <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
>             xmlns:wsa="http://www.w3.org/2005/08/addressing"
> *xmlns:ns1="http://www.example.com/"*>
> <s:Header>
>     . . .
> </s:Header>
> <s:Body>
> <wst:Get Dialect="http://www.w3.org/2009/09/ws-fra">
> <wsf:Expression Language="http://www.w3.org/2009/09/ws-fra/XPath-Level-1">
>         /ex:a/ex:b
> </wsf:Expression>
> </wst:Get>
> </s:Body>
> </s:Envelope>
>
> Obviously the above expression is not going to be evaluated correctly 
> because the mapping of the "ex" namespace prefix to the 
> "http://www.example.com" URI has been replaced by the mapping of the 
> "ns1" namespace prefix.
>
> The question of "which transformations do this sort of thing?" has 
> been bandied about. I assert that is the wrong question to ask. It may 
> be that, today, certain transformations that we know about (e.g. 
> Canonical XML 1.1) preserve namespace prefix mappings, but that says 
> nothing about transformations that (a) we don't know about or (b) 
> haven't been written yet. From an XML perspective:
>
> <foo:Thing xmlns:foo="http://www.example.com"/>
>
> and
>
> <baz:Thing xmlns:baz="http://www.example.com"/>
>
> are equivalent. It might not occur to someone who, for example, writes 
> a piece of code that caches a frequent request in a database, that 
> they need to worry about preserving namespace prefixes. The result is 
> that WS-Frag might break as an unintended side-effect of some 
> "unrelated" technology or feature. This runs counter to the 
> composability model underlying all of WS-*.
>
> The assumption underlying "namespace bindings are evaluated against 
> any namespace declarations . . ." is that the namespace prefixes will 
> be preserved. This assumption carries with it a certain, unknown 
> amount of risk. It is possible for WS-Fragement to isolate itself from 
> this risk by one of the two following mechanisms:
>
> A.) Use of the <prefixMapping> element รก la CMBDF [1]. The above, 
> transformed request would then look like the following:
>
> <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
>             xmlns:wsa="http://www.w3.org/2005/08/addressing"
> *xmlns:ns1="http://www.example.com/"*>
> <s:Header>
>     . . .
> </s:Header>
> <s:Body>
> <wst:Get Dialect="http://www.w3.org/2009/09/ws-fra">
> <wsf:prefixMapping prefix="ex"
>                          namespace="http://www.example.com"/>
> <wsf:Expression Language="http://www.w3.org/2009/09/ws-fra/XPath-Level-1">
>         /ex:a/ex:b
> </wsf:Expression>
> </wst:Get>
> </s:Body>
> </s:Envelope>
>
> CMDBF describes the <prefixMapping> element as follows:
>
>     Each <prefixMapping> child element of the <xpathConstraint>
>     element defines a namespace declaration for the XPath evaluation.
>     The prefix for this declaration is provided by the
>     <prefixMapping>/@prefix attribute and the namespace URI is
>     provided by the <prefixMapping>/@namespace attribute.  These
>     prefix-namespace pairings shall be added to the namespace
>     declarations of the XPath processor.
>
> B.) Specify that XPath expression SHOULD NOT use prefixes but instead 
> use fully qualified namespaces. I'm still investigating if/how to do 
> this in XML 1.0. My sense is that request would/should look something 
> like:
>
> <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
>             xmlns:wsa="http://www.w3.org/2005/08/addressing">
> <s:Header>
>     . . .
> </s:Header>
> <s:Body>
> <wst:Get Dialect="http://www.w3.org/2009/09/ws-fra">
> <wsf:Expression Language="http://www.w3.org/2009/09/ws-fra/XPath-Level-1">
>         /{http://www.example.com}:a/{http://www.example.com}:b
> </wsf:Expression>
> </wst:Get>
> </s:Body>
> </s:Envelope>
>
> That seems like a lot more to type, but its likely that tools could be 
> used to automatically perform the substitution of the fully qualified 
> namespace URI.
>
> So this issue, like most, is about a trade off. How much risk is 
> involved in the dependence on prefix preservation and how much work is 
> involved in breaking that dependence?
>
> [1] http://www.dmtf.org/standards/published_documents/DSP0252_1.0.0.pdf
>
> - gp
>
>
>
>
>
>
>
>



Received on Monday, 25 January 2010 21:51:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:18:23 GMT