Teaching XSLT new tricks with EXSLT

by Michael Day

Following on from Kurt's detailed reevaluation of XSLT 2.0, I thought that I might share an example of what you can do in XSLT 1.0 with the assistance of EXSLT, a useful set of extension functions that are supported by most XSLT implementations.

10 Comments

M. David Peterson
2007-03-09 23:30:12
Fantastic article, Micheal! While the approach I took was from an analogy standpoint instead of a technical showcase, you might find the following article I wrote a while back in regards to EXSLT and XSLT 2.0, moving forward with both tools as part of our overall toolset.


http://www.xsltblog.com/archives/2006/02/on_procedural_v.html


Once again, great post! And welcome to XML.com, by-the-way... Great to have you here :)

M. David Peterson
2007-03-09 23:34:56
uh, not sure how I mixed to ae with ea in spelling your name. sorry about that, Mich*ae*l! :D
Michael Day
2007-03-10 01:20:08
Hi, M. David. It's good to see that there will be cooperation between the EXSLT and XSLT 2.0 communities. Perhaps it will eventually lead to a comfortable detente situation where the only major difference between them is their use of XSD schema. (I have to say that I feel more attached to schema-less XSLT, but understand that the value proposition may be different for people using XML databases based on XSD and XQuery).


In effect, the widespread support for EXSLT has created a defacto XSLT 1.1, even though the official draft has been abandoned. It would be a nice gesture for the W3C to rubber stamp EXSLT as being XSLT 1.1 at some point; at least that would allow the extensions to be brought back into the XSLT namespace and reduce the number of namespace declarations that users have to write :)

M. David Peterson
2007-03-10 05:33:57
I like the way you think, Michael ;-) :D I'll be sure to point a few folks at your comments and see what trouble we might be able to stir up ;-)
Bob DuCharme
2007-03-10 08:10:55
See also my XML.com article Extending XSLT with EXSLT.
Kurt Cagle
2007-03-10 13:58:36
Michael,


Very nice piece. Just a brief follow-up on this - the XSLT 2.0 engine would handle this in nearly the same way, except that you wouldn't need to use the exslt:node-set() method:



<xsl:template match="oneOrMore">
<xsl:variable name="expansion">
<sequence>
<xsl:apply-templates mode="copy"/>
<zeroOrMore>
<xsl:apply-templates mode="copy"/>
</zeroOrMore>
</sequence>
</xsl:variable>
<xsl:apply-templates select="$expansion"/>
</xsl:template>


At the present time, Saxon supports both XSLT2 and EXSLT, and overall I think that there is in fact a fair degree of cross-communication between the two communities ... especially since a number of people involved in EXSLT (myself included) worked closely with the XSLT WG in pushing most of that functionality into XSLT2. The schema issues for the most part arise due to XQuery, which was driven more by the database vendor side, and I find that you can generally get away with not using schemas for just about all XSLT2 transformations.

Kurt Cagle
2007-03-10 14:03:40
Actually a followup on your comment about EXLST as XSLT 1.1. I'd be a little nervous about retrofitting EXSLT as XSLT 1.1 at this stage. It creates more targets to implement, would slow down adoption of XSLT 2 because XSLT 1.1 would be seen as a good baby step, and for the most part EXSLT code IS implemented in XSLT 2.0, the primary difference being the underlying data model. After years of having to wade through the XSL 1.0 vs. XML Patterns (Microsoft pre XSLT implementation) I'd prefer not to revisit that, especially given the XSLT community is still not exactly huge.
Michael Day
2007-03-10 15:19:04
Hi Kurt,


Just a brief follow-up on this - the XSLT 2.0 engine would handle this in nearly the same way, except that you wouldn't need to use the exslt:node-set() method:


Excellent! The difference between result tree fragments and node sets can be very confusing when you encounter it for the first time; it's good that XSLT 2.0 has simplified the data model.


Besides SAXON, are there any other good XSLT 2.0 implementations I could try? One thing I like about xsltproc (libxslt) is that it is very lightweight, so it's ideal to use in shell scripts and makefiles. I guess that I'm really asking if there are any non-Java/C# implementations of XSLT 2.0 :)


(I do run Jing from shell scripts for validation as it has more complete schema support than xmllint, but there is always a noticeable pause when it starts up).


On the subject of XSLT 1.1, it seems that the incremental revision of XML languages at the W3C can be difficult. XML 1.1, XSLT 1.1, XHTML 1.1; none of them exactly set the world on fire, and there is a lot more interest in XML 2.0 (proposals, at least), XSLT 2.0 and XHTML 2.0. It remains to be seen if XSD 1.1 and XSL-FO 1.1 can break the trend. The most successful incremental revision of a W3C specification would have to be HTTP 1.1, or perhaps the award should go to CSS 2.1. Both of which are non-XML technologies... :)

Keith Fahlgren
2007-03-11 11:11:53
Michael said:
Besides SAXON, are there any other good XSLT 2.0 implementations I could try? One thing I like about xsltproc (libxslt) is that it is very lightweight, so it's ideal to use in shell scripts and makefiles. I guess that I'm really asking if there are any non-Java/C# implementations of XSLT 2.0 :)


Yeah, I struggled with whether or not to use Saxon for scripting for a while, but eventually gave in because it is such a nice, conformant piece of software. I recently discovered that the Saxon Java interface was easily approachable from JRuby (I do all of my scripting in Ruby anyway), so I'm looking forward to playing with that in the future.


Kurt Cagle
2007-03-11 11:56:33

On the subject of XSLT 1.1, it seems that the incremental revision of XML languages at the W3C can be difficult. XML 1.1, XSLT 1.1, XHTML 1.1; none of them exactly set the world on fire, and there is a lot more interest in XML 2.0 (proposals, at least), XSLT 2.0 and XHTML 2.0. It remains to be seen if XSD 1.1 and XSL-FO 1.1 can break the trend. The most successful incremental revision of a W3C specification would have to be HTTP 1.1, or perhaps the award should go to CSS 2.1. Both of which are non-XML technologies... :)


SVG 1.1 is being seen as the canonical form for that spec. The jury is still out on XForms 1.1 - my own take is that it would make more sense there to get XF1.1 out but shoot for an XF2.0 release that would incorporate XPath2, provide a consistent exstension mechanism, and introduce a few more critical elements such as treeview editors, which are hard to model in XF1.1. But yes, I'd agree with you that the 1.1 versions have not exactly set the world on fire.