Re: WS-Fragment: Another XPath subset

I looked at this WS-Fragment's XPath Level 1 subset  carefully, this is 
different from the Dsig XPath subset as follows.

Things in WS-Fragment XPath Level 1subset, that are not in Dsig subset
a) We do not allow the text() function. The reason for not allowing this 
- is that text nodes are often very large, and Streaming parsers do not 
load up the entire text node at once - rather they present them as 
separate adjacent text nodes. I had a detailed discussed with the Spec 
leads for StaX group about this, and they told me that this is default 
behavior in the StaX specification but it can be overriden at the 
expense of performance.
b) We did not allow the pos() function or its shortcut (e.g. 
/doc/chapter[2])  in the initial subset, but have agreed to put this in..
c) We do not allow relative XPaths, because it was not clear what should 
be the context that this should it be relative to.


These are things that are in our Dsig XPath subset which are not in the 
WS Fragment subset
A) arithmetic or relational expressions using attributes. Note variables 
and functions are allowed in the Dsig subset, but expression can only 
involve the attributes the current element.
  e.g.  /doc/chapter[@title="Jaws"]
B) descendant axis   '//'
C) Non-abbreviated notation  e.g.   /child::doc/child::chapter
D) Select multiple nodes  e.g. /doc/chapter   will select all chapter 
elements, not just the first one. (WS-Fragment chooses the first one)
E) a top level Union operator '|' . e.g.  /a/b  |  /a/c


Overall there is difference is motivations - The Dsig Xpath subset is 
designed with the constraints of a streaming parser. Code complexity is 
not issue - it just needs to be efficient in time and memory usage. 
Whereas the WS Fragment XPath subset is designed to reduce code 
complexity. However I think WS-Fragment can also benefit from streaming.


I agree with Ed, that there should be a separate specification for 
streamable XPath independent of security. However Xpath is of great 
importance to us, if we give it off to a different group there may not 
be sufficient interest to drive it to completion.

Pratik




On 10/14/2009 12:09 PM, Ed Simon wrote:
> I'm wondering if there should not be non-security-specific (though
> security-aware) W3C specification for streamable XPath. 
>
> In other words, maybe streamable XPath work should be led by those
> leading XPath (not the variety of other groups who need a streamable
> XPath). Of course, input to a streamable XPath specification must
> include input from the non-XPath groups.
>
> Ideally, we would have one streamable XPath specification that fulfils
> the needs of various applications.
>
> Ed
>
>
> On Wed, 2009-10-14 at 14:02 +0200, Thomas Roessler wrote:
>   
>> Looking at the upcoming WS-Fragment Working Draft, I see yet another
>> XPath subset.
>>
>> http://www.w3.org/2002/ws/ra/snapshots/fpwd/frag/wsfrag.html#XPathL1
>>
>>
>> I wonder whether it's worthwhile to spend a little bit of time
>> comparing motivations for their and our XPath subsets; we both seem to
>> be solving for some notion of "constrained resources".
>>
>>
>> Regards,
>> --
>> Thomas Roessler, W3C  <tlr@w3.org>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     
>
>
>