On the Xalan Java user mailing list, Henry Zongaro of the IBM Xalan development team recently replied to my request about plans for XSLT 2.0 support in Xalan Java: "the Xalan [Project Management Committee] hasn't put in place any plans for XSLT 2.0 support."
When I asked on xsl-list if anyone knew of current or forthcoming XSLT 2.0 implementations besides Saxon, the general response was that there is piecemeal support developing in various other XSLT processors, so this shouldn't hold up XSLT 2.0's progress toward becoming a W3C Recommendation. Still, I'd consider the three leading XSLT engines to be Saxon, Xalan, and libxslt, and if two of those three have no current plans to move beyond XSLT 1.0 then I have to worry about XSLT 2.0's future.
2005-12-28 update: I just found out that Xalan 2.2 is bundled with the Java 1.4 JRE, making Xalan pretty ubiquitous. This also explains why, after putting Xalan 2.7 jar files on an Ubuntu Linux machine at home and a Windows machine at work after a hard disk replacement, I couldn't get either to work. The Sagehill documentation for using DocBook + XSLT (which is great all-around) shows has a nice workaround for this.
I have to worry also. In particular, I think that if the W3C has any concern at all about acceptance of XSLT 2.0 in the open-source community, it should not become a rec unless/until there is an implementation of it based on libxslt/libxml2 (if necessary, forked off from the current libxslt codebase, since the principal developer of libxslt has made it clear that he is personally not interested in implementing support for XSLT 2.0). Or if not libxslt, then in some other non-Java open-source library.
I recall a personal communication with David Tolpin, who argued that XSLT 2.0 was likely to be just a single implementation language: Saxon.
It's unfortunate we're not seeing evidence yet that he's wrong; I find a lot of the XSLT 2.0 features really useful.
I probably need to look into reimplementing my citepoc, my XSLT 2.0-based citation processor in some other language (or combination of them; maybe Ruby or Python + XSLT 1.0?).
Wow. I'm very skeptical of XSLT 2.0, but I'm surprised to hear that it's becoming a Saxon-only thing. I know that Daniel V is eve more skeptical than I am, so I don't expect there will ever be an libxslt implementation. However, Michael, I think it's grossly overstated to suggest that XSLT 2 should proceed to REC without a libxslt impl. C'mon!
It underscores the fact that we need to keep EXSLT going with features borrowed from XSLT 1.0, but to be made available in 1.0.
And Bruce, oh yeah. Python+XSLT 1.0 rocks the park. It's the reason I don't even have to care about what happens to XSLT 2. See:
http://copia.ogbuji.net/blog/2005-10-20/Processing
I think MSXML is a leading XSLT engine as well. And Microsoft doesn't have plans to support XSLT 2.0 either.
Yeah, and while they've made noises about XQuery support, they're so big on this XLinq thing (Google: "did you mean XLink?") that I have to wonder about that as well.
The unclosed "update" paragraph that's currently blowing up your Atom feed is why I've never felt very good about including inline XHTML in a feed without also serving it as application/xhtml+xml, to see when it breaks (or, of course, having an XML toolchain involved that wouldn't let you save anything that's not well-formed).
1. Good point.
2. Oops, sorry. I write new entries in Emacs with nxml to make sure that it's valid XHTML, and got sloppy in throwing that single paragraph into a MoveableType data entry form, and now I know what goes wrong if I'm not careful.