XML Developer TipUse template languages with XSLT
This week's XML.com includes a nice article by Jason Diamond called "Template Languages in XSLT." Therein, he manages to articulate an issue about more conventional use of XSLT that's troubled me for some time because it challenges what the very notion of style is about?namely, a clear separation between the content in a document and the way that content gets presented when a document is assembled and formatting for viewing, printing, or other forms of consumption.
In a nutshell, XSLT excels at threading its way through a document's structure and permitting programmers or content developers to grab elements of the structure and fiddle with them to their heart's content before emitting them for output. But the problem with this capability might be summed up as "grab a little, emit a little." That is, there is no clear separation between accessing individual elements of content and operating on those elements to transform them for output. Also, traversal of document structure through XPath or XQuery requires that the XSLT code recognize individual elements and respond to them appropriately. In turn, this requires XML code to be created to handle specific document structures, elements, and so forth, in a less than general way. Thus, if document structure, organization, or contents change, the XSLT that traverses and transforms such documents must often change as well.
In his article (and in other references that appear therein) Diamond makes the entirely predictable and incredibly valuable observation that a bit of indirection in using XSLT can sidestep this dependency and create a template language that permits XSLT to be written in a more flexible, general-purpose way. In other words, instead of writing a single XSLT transform that embeds specific knowledge of documents elements and structures and combines traversal and transforms ("grab a little, emit a little") this means writing two (or more) XSLT documents, where one document describes general document structures (description), elements, and so forth, and the other document represents the actual transforms that should be applied to various elements or content that appear within the source document (transforms).
In this case, you must first internalize the description XSLT document so you can use this information to drive the behavior of the transforms document. Then, while reading the input or source document, the descriptions piece provides information about the elements, structures, and content the source document is likely to contain. Likewise, the transforms document provides information about what to do with individual elements, structures, and content when emitting output. This helps keep the structure (description) separate from the presentation information (transforms) and prevents XSLT authors from having to alter both description and transforms information when one or the other must change.
Have questions, comments, or feedback about this or other XML-related topics? Please e-mail me care of firstname.lastname@example.org. I'm always glad to hear from my readers.
About the Author
Ed Tittel is a principal at LANWrights, Inc., a wholly owned subsidiary of LeapIt.com. LANWrights offers training, writing, and consulting services on Internet, networking, and Web topics (including XML and XHTML), plus various IT certifications (Microsoft, Sun/Java, and Prosoft/CIW).
For More Information
- Need help with the latest industry acronyms and terms? Visit our helpful Glossary.
- Visit our Best Web Links for the best editor-selected XML resources on the Web.
- Post your technical questions, or help your peers in our Enterprise Developer Forums.
- Ask the Experts! Our Web Services, SOAP, WSDL, XML, .NET, Java and EAI gurus answer your toughest questions.