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

RE: issue 8196

From: Doug Davis <dug@us.ibm.com>
Date: Mon, 25 Jan 2010 19:20:53 -0500
To: Gilbert Pilz <gilbert.pilz@oracle.com>
Cc: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Message-ID: <OFBDC40C65.A1A9D1F4-ON852576B7.0001D352-852576B7.0001EC48@us.ibm.com>
I'm still trying to get my head around how big of a problem this is, but 
if it does turn out to be a problem then we need to solve it for enum and 
eventing as well since they have xpath expressions too. 

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.



Gilbert Pilz <gilbert.pilz@oracle.com> 
Sent by: public-ws-resource-access-request@w3.org
01/25/2010 04:33 PM

To
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
cc

Subject
RE: issue 8196






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 Tuesday, 26 January 2010 00:21:42 GMT

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