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

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

On Sun, 11 Dec 2005, Daniel Veillard wrote:

> On Sat, Dec 10, 2005 at 07:28:19PM -0500, Joel E. Denny wrote:
> > Do you see XSLT 2.0 in libxslt's future?
> 
>   Would you implement it ? Me, the answer is no. I don't need it, my
> employeer has no interest in it, it's foundations are shaky (XSD),
> it's unclear how much of 1.0 can be reused, and it's way too big for
> my taste. However it's an open source project, if people want to 
> implement it I'm not against.

No money + no need + tough project = no work.  I'd feel the same.

> > In light of the discovery that 
> > keys referencing keys is supposed to be an error in 1.0, are you still 
> > willing to allow it?
> 
>   I'm not happy to violate the spec conciously.
> 
> > Have you ever considered having a --strict flag (or 
> > --non-strict) for xsltproc to select whether extensions like this should 
> > be permitted?
> 
>   I'm gonna be frank. XSLT-1.0 does not fit your need. You want to sort
> node set and do maths with it ? Use XPath from a high level *programming
> language* instead of trying to divert somthing XSLT was not designed for !
>   Use the right tool for the job !

Thanks for your honest opinions.  I guess it seems as if I'm placing my 
project on a slippery slope, and a little code evolution might possibly 
give it a shove.

For now, I just need keys referencing keys.  Given that any XSLT 1.0 
implementation must build keys in some order, any XSLT 1.0 implementation 
should probably be able to accommodate this in some manner unless it 
explicitly makes it an error in order to conform to the 1.0 errata.  In 
other words, I'm not quite sure why the 1.0 errata decided to disallow 
this.  Maybe they didn't realize it's easy?  Or maybe there's a complexity 
for certain special cases that I'm not aware of?

In any case, as long as you're willing to maintain this feature in 
libxslt, I think I'll use it.  Fortunately, I'm not tied to my current 
implementation.  It's just the architecture that's important.  I can rest 
assured that anyone who's not willing to use an XSLT 1.0 processor with 
this extension should be able to accomplish the same thing with a 2.0 
processor.

Joel