Re: issue 8196

Like I said, this is a judgment call. "How big of a problem this is" 
depends on (a) how likely it is that your products will ever run in an 
environment in which your WS-Frag requests, wse:Subscribe, or 
wsen:Enumerate requests are transformed in some way that does not 
preserve the namespace prefixes (b) whether or not the requests in 
question will actually be broken by such transformations (c) how much 
effort it will take to debug this situation and fix it.

One thing I think that gets missed in these discussions is that there is 
nothing "wrong" with a software component that transforms SOAP messages 
in way that changes namespace prefixes. XML says that prefixes are not 
semantically meaningful. Neither SOAP 1.1 nor SOAP 1.2 nor BP 1.1 (etc.) 
say that you can't change namespace prefixes. If WS-Frag breaks because 
something changed the namespace prefixes, it is not that "things" fault, 
it is WS-Frag's fault. A protocol that breaks because it depends upon 
behavior that is not guaranteed by the underlying specifications has 
nothing but itself to blame.*

- gp

* This gives me an idea for a good interop tool/scenario. Write a 
customized version of tcpmon that changes the namespace prefixes of the 
incoming messages to "ns1", "ns2", . . .

On 1/25/2010 4:20 PM, Doug Davis wrote:
>
> 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"_ 
> <http://www.w3.org/2003/05/soap-envelope>
>             xmlns:wsa=_"http://www.w3.org/2005/08/addressing"_ 
> <http://www.w3.org/2005/08/addressing>
> *xmlns:ex=**_"http://www.example.com/"_* <http://www.example.com/>>
> <s:Header>
>     . . .
> </s:Header>
> <s:Body>
> <wst:Get Dialect=_"http://www.w3.org/2009/09/ws-fra"_ 
> <http://www.w3.org/2009/09/ws-fra>>
> <wsf:Expression 
> Language=_"http://www.w3.org/2009/09/ws-fra/XPath-Level-1"_ 
> <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"_ 
> <http://www.w3.org/2003/05/soap-envelope>
>             xmlns:wsa=_"http://www.w3.org/2005/08/addressing"_ 
> <http://www.w3.org/2005/08/addressing>
> *xmlns:ns1=**_"http://www.example.com/"_* <http://www.example.com/>>
> <s:Header>
>     . . .
> </s:Header>
> <s:Body>
> <wst:Get Dialect=_"http://www.w3.org/2009/09/ws-fra"_ 
> <http://www.w3.org/2009/09/ws-fra>>
> <wsf:Expression 
> Language=_"http://www.w3.org/2009/09/ws-fra/XPath-Level-1"_ 
> <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"_ <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"_ 
> <http://www.example.com/>/>
>
> and
>
> <baz:Thing xmlns:baz=_"http://www.example.com"_ 
> <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"_ 
> <http://www.w3.org/2003/05/soap-envelope>
>             xmlns:wsa=_"http://www.w3.org/2005/08/addressing"_ 
> <http://www.w3.org/2005/08/addressing>
> *xmlns:ns1=**_"http://www.example.com/"_* <http://www.example.com/>>
> <s:Header>
>     . . .
> </s:Header>
> <s:Body>
> <wst:Get Dialect=_"http://www.w3.org/2009/09/ws-fra"_ 
> <http://www.w3.org/2009/09/ws-fra>>
> <wsf:prefixMapping prefix="ex"
>                          namespace=_"http://www.example.com"_ 
> <http://www.example.com/>/>
> <wsf:Expression 
> Language=_"http://www.w3.org/2009/09/ws-fra/XPath-Level-1"_ 
> <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"_ 
> <http://www.w3.org/2003/05/soap-envelope>
>             xmlns:wsa=_"http://www.w3.org/2005/08/addressing"_ 
> <http://www.w3.org/2005/08/addressing>>
> <s:Header>
>     . . .
> </s:Header>
> <s:Body>
> <wst:Get Dialect=_"http://www.w3.org/2009/09/ws-fra"_ 
> <http://www.w3.org/2009/09/ws-fra>>
> <wsf:Expression 
> Language=_"http://www.w3.org/2009/09/ws-fra/XPath-Level-1"_ 
> <http://www.w3.org/2009/09/ws-fra/XPath-Level-1>>
>         /{_http://www.example.com_ 
> <http://www.example.com/>}:a/{_http://www.example.com_ 
> <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
>
>
>
>
>
>
>
>