It would certainly be possible in principle to optimize the execution of
count(preceding::node()), whether it's evaluated during index
construction or later, but I think you'll be lucky to find a processor
that does it. In general, executing this expression on N nodes will have
O(N^2) performance. The approach using dynamic evaluation will have O(N)
performance, so it will win in the end.
I think it's likely that on most documents, counting the number of
preceding-siblings at each level is likely to be significantly more
efficient than counting all preceding nodes. So (for elements at any
rate), why not use
<xsl:number level="multi" count="*"/>
giving an identifier such as 1.3.24.6, which can then be used to locate
the node using a recursive descent of the tree, using
child::*[position() = substring-before($nr, '.')]
to select the right node at each level.
Michael Kay
Software AG
home: Michael(_dot_)H(_dot_)Kay(_at_)ntlworld(_dot_)com
work: Michael(_dot_)Kay(_at_)softwareag(_dot_)com
-----Original Message-----
From: owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
[mailto:owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com] On Behalf Of
Dimitre Novatchev
Sent: 20 January 2003 21:35
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: AW: [xsl] how to "save" a context?
"Michael Kay" <michael(_dot_)h(_dot_)kay(_at_)ntlworld(_dot_)com> wrote in
message
news:002201c2c0bd$53ff2fe0$6601a8c0(_at_)pcukmka(_dot_)(_dot_)(_dot_)
That is, for every node (not an attribute or a namespace),
the following pair identifies it uniquely:
(count(ancestor::node()), count(preceding::node()))
For an attribute node or a namespace node this becomes
the tripple:
(name(), count(../ancestor::node()), count(../preceding::node()))
Finding the node from its id has an efficient implementation
using keys.
Only if you ignore the cost of building the index, which is
likely to
be
horrendous.
My reasoning is that building the index can be done while
initially reading and parsing the xml source document, as
(the sum of) the count of preceding nodes and ancestor nodes
closely follows (increases with) document order. So it can be
computed while and as a side effect of building the tree with
minor additional cost.
In case we have a standard "persistent node id" in some
future version of XSLT, xml parsers can be modified to
produce this index on the fly while building the document tree.
Even if we do not use a key, it is quite probable that evaluating
//node()[count(ancestor::node()) = $v1
and
count(preceding::node()) = $v2
]
will be less expensive than calling the xx:evaluate()
extension function.
Or am I wrong?
I missed the beginning of this thread, why can't you use
generate-id()?
The original question was to use *persistent* ids to access
the same node during different transformations (e.g. in
multi-pass processing). As we know, generate-id() is only
guaranteed to produce the same id for a node during the
course of the same transformation. My initial reply was to
use as persistent id an XPath expression for the node. But
then it would be necessary to have the xx:evaluate()
extension function in order to de-reference.
The coordinates of a node do not need dynamic XPath
evaluation in order to access the node. It is interesting
that the pair of coordinates is in fact an abreviation of an
XPath expression itself. But this XPath expression has a
"fixed format", it is a single and pre-defined XPath
expression, so no dynamic evaluation is necessary.
=====
Cheers,
Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list