W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2002

Re: New Version of XPath Filter

From: Aleksey Sanin <aleksey@aleksey.com>
Date: Mon, 08 Apr 2002 11:28:28 -0700
Message-ID: <3CB1E14C.8010308@aleksey.com>
To: John Boyer <JBoyer@PureEdge.com>
CC: merlin <merlin@baltimore.ie>, reagle@w3.org, w3c-ietf-xmldsig@w3.org
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.
>
Received on Monday, 8 April 2002 14:29:29 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:15 GMT