Re: [xslt] key() in match pattern of xsl:key
- From: "Joel E. Denny" <jdenny ces clemson edu>
- To: Daniel Veillard <veillard redhat com>
- Cc: The Gnome XSLT library mailing-list <xslt gnome org>
- Subject: Re: [xslt] key() in match pattern of xsl:key
- Date: Sun, 11 Dec 2005 12:33:54 -0500 (EST)
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]