>> To summarise, it is perfectly possible to create the above key without
>> walking up the ancestor axis for the nodes.
>
> But do you know of any implementations that build such a key like that?
>

This question is better asked to the developers of XSLT processors.

If this is the first idea that comes to me on this topic, then it is
very likely the developers of XSLT processors would have come across
it, too.

Indexing "on the fly" (with some restrictions) may also be the only
possibility when processing potentially infinite xml documents in
streaming mode.



-- 
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play






On Mon, Aug 4, 2008 at 10:17 AM, Colin Adams
<colinpauladams@xxxxxxxxxxxxxx> wrote:
> 2008/8/4 Dimitre Novatchev <dnovatchev@xxxxxxxxx>:
>>> Yes (although you're just walking the ancestor axis once per node in a
>>> different place)
>>
>> It is possible to create the following key (and any other keys!):
>>
>>    <xsl:key name="kRtlMode" match="*[ancestor-or-self::*[@dir='rtl']]"
>>     use="generate-id()"/>
>>
>> just during the initial reading of the xml document -- without any
>> walking up the ancestor axis.
>>
>> That is, when the currently-read node satisfies:
>>
>>  @dir='rtl'
>>
>> then the "key-recording-mode" for the key named 'kRtlMode' is turned
>> on and key-values are generated for each element while this
>> "key-recording-mode" is on.
>>
>> To summarise, it is perfectly possible to create the above key without
>> walking up the ancestor axis for the nodes.
>
> But do you know of any implementations that build such a key like that?