Re: New Version of XPath Filter

Yes, I have an example. Suppose we have following document:
    <a>
        <b>
            <c/>      
            <d/>
        </b>
    </a>
If the XPath expression selects node "b" (nodes set S = { node "b" } 
then the
current proposal  requires application to create new nodes set S' which 
will include
nodes "b", "c" and "d". This is an additional step. I don't see any 
reasons why the
author of XPath expression will not include these nodes him or herself.

Also this additional step limits the XPath filter functionality because 
one can have
a requirement to operate with nodes set having *only* node "b" but not 
nodes "c" and "d"

Aleksey.



John Boyer wrote:

>Hi Aleksey,
>
>All XPath implementations operate over actual nodes and not subtree
>roots.  At any point in time, the resultant node-set of an Xpath
>expression is interpreted by the application that consumes Xpath (the
>host language, so to speak).  For example, XSLT typically uses recursion
>to process the nodes in a node-set, so the nodes are interpreted as
>subtree roots.
>
>In essence, a node-set containing nodes that we choose to interpret as
>subtree roots is still a node-set containing nodes.
>
>Therefore, I do not see the basis in fact for your claim that we will
>sometimes lose efficiency.  Is this just what you suspect will happen or
>do you have an actual implementation that is harmed by this approach?
>
>Thanks,
>John Boyer
>
>-----Original Message-----
>From: Aleksey Sanin [mailto:aleksey@aleksey.com]
>Sent: Monday, April 08, 2002 10:46 AM
>To: merlin
>Cc: reagle@w3.org; w3c-ietf-xmldsig@w3.org
>Subject: Re: New Version of XPath Filter
>
>
>
>>2. We choose to perform expansion from nodes to node trees outside
>>the XPath processor to maximize the possible execution speed. It
>>is much faster to evaluate and expand //Foo than to evaluate
>>//Foo//self::node(). Remember, the only goal of this transform is
>>speed; it doesn't provide any new capability.
>>
>I don't think that there is no new functionality at all. For example, 
>uninon provides new ways
>to apply some transforms to a part of the document and add more nodes 
>later. Also some XPath
>implementations operates on the actual nodes sets (no sub-trees!) and by
>
>this construction
>S' is an additional and expensive operation!
>
>Aleksey.
>