RE: New Version of XPath Filter

"John Boyer" <[email protected]>
Newsgroups gmane.ietf.xmldsig
Message-ID <[email protected]>

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:[email protected]]
Sent: Monday, April 08, 2002 10:46 AM
To: merlin
Cc: [email protected]; [email protected]
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.