Re: [xslt] key() in match pattern of xsl:key

["Joel E. Denny" <jdenny ces clemson edu>]

On Tue, 13 Dec 2005, Vincent Lefevre wrote:

> On 2005-12-13 16:05:07 -0500, Joel E. Denny wrote:
> > On Tue, 13 Dec 2005, Vincent Lefevre wrote:
> > > Unless there's a way, through an extension, to access the RTF in
> > > another way, e.g. with document().
> > 
> > You're referring to exslt:document, right?
> 
> Well, it does what I was suggesting, but this will lead to an
> unnecessary linearization.

Did you have something else in mind?

> > I know little about exslt:document and IDs. Reading the spec for
> > exslt:document at http://www.exslt.org, its relationship with keys
> > and IDs doesn't seem very well defined.
> 
> There is no relationship, exslt:document just generates a document.
> Then you can read back the document with document(), and IDs are a
> standard XML feature.

I ignored the () in document() for some reason. I assumed you meant 
exslt:document inside a variable -- no linearization.  I was unsure how 
that would work with IDs and keys.

> But supporting XLST 2.0 features in XSLT 1.0 processors isn't more
> standard than supporting extensions like exslt.

Maybe even less common... but I still need to explore it to be sure.  If 
both were to prove to be equally well supported, I'd prefer 2.0 features 
so that converting stylesheets to full 2.0 would be less work.  I guess 
I'm making the assumption that 2.0 processors don't usually support EXSLT.  
Is that right?

Forgetting extensions for a moment, a few emails back you suggested 
multiple passes with an XSLT 1.0 processor.  Each pass could produce 
XML-encoded sets of data off of which the next pass could construct keys. 
Although exslt:document might add some convenience to this approach, it 
wouldn't be necessary.  This seems like a straight-forward pure XSLT 1.0 
alternative to keys referencing keys.

This multi-pass approach is undoubtedly less efficient by some (perhaps 
large) constant factor, but the asymptotic behavior is just as good: O(n) 
for each key's construction, O(1) for lookup (assuming a hash 
implementation).  Using an API, such as the C API for libxslt/libxml2, it 
wouldn't be necessary to ever linearize the intermediate DOMs.

I still like the conciseness of keys referencing keys, but it's nice to 
know there's some well-supported alternative in cases where that option is 
not available.

Thanks for this discussion.  It's proving very helpful.

Joel