A look at the upcoming XSLT 3.0 release, and why it matters beyond the XML community
Eighteen years ago, the originators of XML specification faced a problem: how to use the new language to generate a book-publishing format. What emerged were two new languages, the first for describing the various functional parts of a publication in XML called the XML Stylesheet Language Formatting Objects (ultimately XSL-FO) and the XML Stylesheet language (XSLT) for transforming XML-formatted content into the XSL-FO language.
XSL-FO is still in use today, though the number of formatting languages in XML has grown beyond the initial scope of FO. Additionally, CSS has been quietly overtaking FO for many simpler document transformations, to the extent that many eBooks (specifically those based upon the ePub standard) are essentially HTML + CSS. However, XSLT has taken its own remarkable trajectory, as people began to realize that the problem of transforming XML transcended just publishing books and covered transforms from any format to any other.
A problem that XSLT adoption has faced comes due to the difficulties in getting older implementations upgraded. Java ships with Xalan. Xalan has not been improved since it was first incorporated into Java back in 2000 and it still uses the very first version of XSLT, standardized in 1999. The Linux based libxslt processor is similar; while it is a good implementation for the Linux platform, it has not been upgraded since it was written in the early 2000s. Since then there have been two more major versions released of the XSLT standard, the first (XSLT 2.0) in 2006, the second (XSLT 3.0) scheduled to be released this year. These versions are backwards compatible, which means that XSLT 1.0 stylesheets written fifteen years ago should still work today in contemporary XSLT engines with little to no modification.
Moreover, swapping out XSLT versions is typically as simple as dropping a more contemporary engine, such as the Saxon processor, into a folder in your Java project and changing a line in a configuration file. Most Java developers could do it in under ten minutes, and there are both open source and commercial versions of these for free up to a fairly modest licensing fee. Upgrading similar systems on Windows (such as Altova's XSLT server or the Quixslt XSLT processor) is usually nearly as easy. There really are very few reasons why you should not upgrade.
The question, of course, is what benefits do you get for that upgrade? There are a number of them, but it's worth going through the key ones to understand why upgrading (preferably to XSLT 3.0) is so worthwhile.
JSON Transformations
In XSLT 3.0, an inbound document can be in JSON, rather than XML. The processor can take that document, use the json-to-xml() function to convert it into a specific known XML format, process that through the templates, then convert the resulting output back into JSON (or can convert it into HTML 5 among other formats).
For instance, the following inbound JSON content
{ "employees" : { "jd101" : { "firstname" : "Jane" , "surname" : "Doe" , "department" : "IT" , "manager" : "kp102" }, "kp102" : { "firstname" : "Kitty" , "surname" : "Pride" , "department" : "IT" , "manager" : "jh104" }, "cx103" : { "firstname" : "Charles" , "surname" : "Xavier" , "department" : "Management" }, "jh104" : { "firstname" : "James" , "surname" : "Howlett" , "department" : "Security" , "manager" : "cx103" } }}
... continue reading