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:33:50 -0800
Message-ID: <4B5E0E3E.8020504@oracle.com>
To: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
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:34:39 GMT

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