RE: issue 8196

On Mon, 25 Jan 2010, 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.

Easy:
http://www.w3.org/TR/2009/CR-exi-20091208/#options
[[
[Definition:]  The strict option is a Boolean used to increase compactness 
by using a strict interpretation of the schemas and omitting preservation 
of certain items, such as comments, processing instructions and namespace 
prefixes. The default value "false" is assumed when the "strict" element 
is absent in the EXI Options document. When set to true, those productions 
that have NS, CM, PI, ER, and SC terminal symbols are omitted from the EXI 
grammars, and schema-informed element and type grammars are restricted to 
only permit items declared in the schemas.
]]

> 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-*.

"XML" as in angle brackets level?
Because at the infoset level, those are not exactly the same
<<
An element information item has the following properties:

    1. [namespace name] The namespace name, if any, of the element type. If 
the element does not belong to a namespace, this property has no value.
    2. [local name] The local part of the element-type name. This does not 
include any namespace prefix or following colon.
    3. [prefix] The namespace prefix part of the element-type name. If the 
name is unprefixed, this property has no value. Note that namespace-aware 
applications should use the namespace name rather than the prefix to 
identify elements.
>>
Not exactly the same, but close enough for people to avoid relying on 
namespace prefixes. After all we are building namespace-aware 
applications every time we are using the WS stack.

> 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
>
>
>
>
>
>
>
>
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Tuesday, 26 January 2010 21:46:46 UTC