This is the final installment in our series of tutorial tips on the subject of the XML Style Sheet Language Transformations, aka XSLT. It deals with the various mechanisms that XSLT provides for handling errors if and when they should occur when processing input documents and creating output documents.
The ways in which errors may be handled when using an XSLT processor to handle a document depend in large part on the kinds of errors encountered during processing. These fall broadly into several categories, each of which requires a somewhat different response, but all are part of document processing and thus fall under the purview of the particular XSLT processor that may be in use. That said, it's possible to encounter unknown or unrecognized XSLT function calls, expressions, or mysterious syntax in an XSLT document itself. This is where the notion of fallback comes into play, which basically defines alternative processing instructions that the processor should follow when it encounters instructions it doesn't recognize or can't understand. The xsl:fallback instruction handles this sort of thing (and is covered in the next paragraph). Otherwise, each of the various XSLT processors (Xalan, Saxon, MSXML, and so forth) includes its own unique set of exception handling tools that must be brought to bear on handling errors in input documents being processed (these are covered in a broad way in the next two paragraphs, with pointers to additional information on specifics for key XSLT processors).
At present XSLT processors typically only need to use xsl:fallback when processor specific extensions appear in XSLT documents However, when a new version of XSLT becomes available -- this will probably be named XSLT 2.0 -- this instruction will also serve to resolve discrepancies between processors designed to handle the older version and constructs or syntax they may not therefore recognize from the newer version. Basically, the xsl:...
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
fallback instruction is used within a template body and must contain one or more of its own template bodies. It's also important to make sure to nest the fallback instruction within the element that may need recourse to fallback mechanisms. It's likewise important when using elements from within the xsl namespace to include a version attribute that correctly identifies the applicable version number when using some version other than 1.0 (as in ).
This mechanism only deals with XSL version compatibility or processor extension issues, and then only defers the REAL XSLT error-handling mechanisms available to stylesheet and related application developers -- namely, XSLT processor exception and error handling mechanisms. To some extent, these derive directly from the underlying languages or toolsets in use (so that standard Java exception handling techniques work well with Xalan or Saxon, standard .NET techniques with ASP or MSXML, built-in error-handlers support other XML environments like Struts, and so forth). These will generally consist of some method to send a message or alert to report that an error has been encountered, with whatever kind of error-handling and clean-up mechanisms the developer sees fit to provide or invoke from a standard toolset; these may include simple logging, close-out and process termination, or something more complex and capable -- though the processor must terminate without producing a final result tree, according to W3C specifications.
Microsoft has a good example on its Web site titled "Performing Error Handling with XSLT" that restates my categories in terms of parse errors versus run-time errors, but that still addresses both sides of the same divide. Version 2.0 of the XSLT W3C Working Draft (last updated on 9/15/2005) also includes a section (2.9) on error handling that does a great job of defining an error taxonomy and of describing appropriate handling mechanisms. But when the rubber meets the road, the details that apply to the specific processor in use will ultimately reign supreme:
- Xalan: see discussions throughout the Apache XML FAQ on Xalan
- Saxon: see discussion at Coverpages.org on SAXON element handlers
- MSXML: CodeProject has great pointers to general mechanisms, along with an even better discussion of an actual, small-footprint implementation
For other processors, a little searching on " exception handling" or " error handling" should also produce useful information, instructions, and often, examples of how to build or use these things in your own markup.
This concludes my multi-part series on the subject of XSLT. Expect to see me playing catch-up on recent XML tools, news and technologies in my next few tips. If you're interested in seeing similar coverage of other topics, shoot me an E-mail at etittel@techtarget.com and please let me know. I can only hope you've found this series as interesting and informative to read and ponder, as I found it to research and write.
About the author
Ed Tittel is a full-time writer and trainer whose interests include XML and development topics, along with IT Certification and information security topics. E-mail Ed with comments, questions, or suggested topics or tools for review.
