Re: WS-Fragment: Another XPath subset

+1 to Pratik's comments.

I'm not sure I understand the harm of more than one profile of an  
existing specification for different purposes. The core XPath spec is  
defined and use of a profile need not be that confusing.

I agree it makes sense for XML Security WG to define a profile as part  
of its work to be sure it is appropriate for security application.

What do others think?

regards, Frederick

Frederick Hirsch
Nokia



On Oct 15, 2009, at 8:28 PM, ext pratik.datta@oracle.com wrote:

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

Received on Friday, 16 October 2009 12:45:20 UTC