- From: John Boyer <JBoyer@PureEdge.com>
- Date: Mon, 8 Apr 2002 10:58:04 -0700
- To: <aleksey@aleksey.com>, "merlin" <merlin@baltimore.ie>
- Cc: <reagle@w3.org>, <w3c-ietf-xmldsig@w3.org>
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 13:58:49 UTC