Re: issue 8196

Yves,

To be clear, are you saying that there exist known "transformations" 
that do not preserve namespace prefixes?

- gp

On 1/26/2010 1:46 PM, Yves Lafon wrote:
> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>