The news is something I’d rather despaired of ever hearing - XSLT 2.0 is now a Recommendation - big, capital R, with XPath right there beside and XQuery making its formal debut. It’s been a long time coming, but I suspect in many ways that the timing couldn’t be more perfect.
XSLT 2 started out as XSLT 1.1, an effort to try to solve some of the nastier, thornier issues of XSLT 1.0. Getting rid of the damned ext:node-set function that was a non-standard hack that became practically de rigour in XSLT processors, because there are many times where you want XML fragments to just act like XML. The introduction of a <xsl:function> tag so that you could call templates from with XPath. Multiple output serialization, support for tokenization and regular expressions. Take a look at EXSLT (http://www.exslt.org) sometimes, and you can see where many of us playing with XSLT 1.0 were seriously hoping XSLT 1.1 would become back in 2002-3.
But it didn’t happen. A fateful decision was made, one that many people at the time railed against, though in retrospect wiser heads than mine prevailed. XSLT 1.1 was sidelined, the data model was effectively scrapped, and an effort was made to reach out to the XQuery working group and ask a very fundamental question - just what is it that we’re trying to do with XPath. The decision was made to fix the technology from the ground up, and so XSLT 2.0 would end up sitting in limbo for nearly five years.
And yet, had XSLT 2 come out in 2003, it would have been at the depths of the tech depression, at a time when people were really just beginning to play with XSLT 1.0 to any great extent outside of the XML geek pool. Mozilla was just beginning to get legs then, Opera was an also ran and IE still ruled the roost. About that period, a group of open source developers (perhaps chief among them M David Peterson) and I decided to create and promote a C# version of the only real XSLT 2 implementation, Michael Kay’s Java based Saxon. David banged heads with IKV Java emulator layer for the better part of six months, but in the end what he came up with was a version of Saxon 8 beta that was so good Dr. Kay incorporated it back into his offerings.
In that period (and in the time leading up to 2004) - I contributed introductory chapters for two XQuery books, XQuery Kick Start for SAMS, and XQuery Early Adopter for Wrox. Ironically, the early adopter label was well deserved, as it would be another three years before the specification saw the light of day. When a third publisher - Manning - approached me about writing an XQuery book in late 2004, I told them (correctly as it turned out) that it would be a waste of time. In October 2004, I spoke at Chris Sells’ Applied XML Development Conference, a Microsoft oriented XML venue, and made the impassioned case that .NET should incorporate XSLT 2.0 - an opinion that actually seemed to be fairly widely agreed with. However, around that time XSLT 2’s completion was pushed out until late Fall 2006, and even the most ardent of evangelists can feel a little depressed when they watch a technology standard they believe in recede into the depths of the future.
However, I had a coming home realization last year when I encountered the eXist XML database. (http://exist.sourceforge.net). It married the concept of XQuery with the concept of server pages, was able to incorporate XSLT (and XSLT 2) and system level extensions into the XQuery language, and opened my eyes to the potential of working literally within an XML environment. When tied in with XForms on the client (yet another late blooming technological standard) what you end up with is a system that will force you to completely rethink web development, and to understand that ultimately XML can in fact stand alone without needing to explicitly having to spend anytime on Java, PHP or .NET mechanics.
Coming out now, I think XSLT2 and XQuery will be seen as a very potent combination (especially in with regards to the AJAX movement and what I see as the rise of the Bound XML era). I don’t necessarily see immediate adoption on the client, but with XSLT2 now “official” it is likely that many developers and vendors who have held off on incorporating XSLT 2.0 will now have a strong incentive to move forward to gain a foothold in this emerging technology space.
I will be doing a series on XSLT 2/XPath 2 shortly for XML.com, and will also be doing another series on XQuery in the very near future. To Michael Kay, Norman Walsh, and the many other people who have worked to get this trio of technologies out the door, I can only give a heartfelt “Thank you … this should be … spectacular!”
xforms.org, an XForms Community Forum built for fostering interest in XML Web technologies.
Agreed... a big ** Thank You ** to all involved, including yourself and David. I am amazed at the ease with which you can create active pages and new feeds from old using just eXist, a pinch of XQuery, and XSLT2; and though it wasn't difficult to configure eXist from Xalan to Saxon, I don't see why you wouldn't want to do this.
I would guess that these official recommendations will curb the "kudzu effect", too (for better or worse).
Cheers, and thanks to all!
I've been using xslt for nearly 1 year now ... I just switched to python's pyxml and used xpath tools from that library. I really think xslt is useless ... 1/2 my dev team could not understand it ... and the tools were absolutely horrible. Python is the way to go for all xml processing.
Tools are important. I've used Oxygen for years (www.oxygenxml.com) for doing most of my XSLT processing - works with XSLT1 and 2, contains an integrated debugger, and overall is probably one of the best XML editors I've worked for a long time.
Concerning talent - this is, and has been, the Achilles heel of XSLT for a long time, though that's changing. XSLT can be difficult to work with (although 2.0 is much simpler, because it makes it possible to use call templates as functions from within XPath among a number of very critical improvements) and finding good XSLT people is still tough.
I like the Pyxml toolset - it's sophisticated and useful, and if it accomplishes what you need, then use it. I think of XSLT as a convenient way of dealing with complex XPath compositions, and if you can do it in other ways, then more power to you.