December 16, 2004

To better understand when to use XSLT we must first understand when not to use it

XML.com: XML Namespace Processing in Apache

Some of the best advice I have ever been given came from Dr. Wendell Piez when he commented (and I paraphrase) not to let "religion" overcome common sense. He wasn't speaking to religion in the sense of my belief in God but in the sense of my belief in XSLT, two obviously very different things :) His advice was very appropriate and has stuck with me ever since.

This article suggests that to those willing to work at a much lower level in the form of the Apache and SAX API there are alternatives to the more commonly understood and therefore used languages in Java, XSLT, and PHP. From my side of the world I would add that there are also many alternatives to XSLT that exist within the .NET framework and can be accessed at very high levels via many different languages, C# and VB.NET being the most common.

Don't get me wrong. I have no plans nor intentions of hanging up my XSLT hat at any point in the foreseeable future. Its simply too powerful of a language to not use when the time is appropriate and the benefits that come from its use outweigh the cost in the extra processing time incurred by its use. In fact as I have stated before (not so much on this blog but in other forums like XSL-List) and as I know people like Oleg Tkachenko full whole heartedly believe client-side processing of XSLT via MSXML, client-side use of System.Xml.Xsl, TransforMiiX, Saxon, Saxon.NET, and in the near future libxslt on Safari (see previous link to Oleg's comments on this) is a VERY ATTRACTIVE and POWERFUL tool that has been in our toolbag via MSXML since IE 5.0. But it hasn't been until very recently that it has been considered a realistic solution given its historically recent addition to the Mozilla family of browsers, thus making the solution cross-platform. And with open-source projects like Sarissa turning two very different API's into one very accessible and powerful wrapper API this "new found" alternative becomes that much more appealing.

But this article has nothing to do with the client and everything to do with the server. If nothing else its good to know that there are alternatives to server-side XML processing. This is one of them.

NOTE: This article focuses on the SAX-style XML Push processing model [-> link to push vs. pull comparison] The CLI (.NET framework via System.Xml) introduces the pull processing method which is extremely fast, very powerful, and something that should be looked into and considered when looking to increase XML processing performance on the server.