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.H.Kay@xxxxxxxxxxxx
work: Michael.Kay@xxxxxxxxxxxxxx 


> -----Original Message-----
> From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx 
> [mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Dimitre Novatchev
> Sent: 20 January 2003 21:35
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: AW:  how to "save" a context?
> 
> 
> 
> "Michael Kay" <michael.h.kay@xxxxxxxxxxxx> wrote in message 
> news:002201c2c0bd$53ff2fe0$6601a8c0@xxxxxxxxxx
> > > 
> > > 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