Infinitesque

Subjects:

Dropping in <!DOCTYPE>-Dropping Alternatives

This version:

Revision 0.1 (2006-02-03)

Contributor:
John L. Clark

Abstract

A fundamental question moves one researcher to explore the future of XML with the future of XSLT, which in turn moves another researcher to explore alternate XSLT futures.

In XML, entities are declared within the Doctype declaration. Entities are recursively expanded when they are encountered by a parser, so when hand-authoring XML, these entities are often used as a macro facility. In December of 2005, Tim Bray wrote Drop the <!DOCTYPE>, in which he (not surprisingly) argued against the use of Doctype declarations. If you were to follow his advice, you would not be able to use the entity "macro" facility. Personally, I try to avoid depending on any of the features offered by Doctype declarations, but this article isn't about my opinion on that topic, but is instead about XSLT.

In response to Tim's article and some heady push-back from arguments calling for the demise of the Doctype declaration, Norman Walsh wrote a nifty XSLT script for allowing a high-level, user-configurable macro facility for XML. This was good stuff; I was ready to be very excited about this approach until I discovered that his work required XSLT 2. Unfortunately, my XML toolkit of choice—4Suite—does not currently have support for XSLT 2.

I really like XSLT, and so as I have come across XSLT 2 scripts like Norm's, I have been forced recently to evaluate different XSLT solutions. Do I try to push for more XSLT 2 support in toolkits that I use, or do I focus on XSLT 1 with enhancement through efforts such as EXSLT? As part of this process, I decided to see if I could reimplement (or rather, modify) Norm's script to use only XSLT 1 with EXSLT extensions. I was successful; my version of ml-macro.xsl uses XSLT 1 plus extensions from the common, regular expression, and function EXSLT modules. (Unfortunately, the use of the regular expression module currently excludes libxml2/libxslt.) My version comes out at about 80 lines longer than Norm's.

There are definitely some things that I like about the XSLT 2 solution. Sequences seem to be easy to use, and the analyze-string construct is elegant. Clearly XSLT 2 can do the job with slightly less code, and I think my need to convert to node-sets at several points is somewhat costly. But XSLT is here now, and with EXSLT it can do the task. If we wanted, we could even add the analyze-string machine to the EXSLT specification. Is this a typical task for XSLT 2, though? Is there a bunch of other functionality that will ultimately prove unapproachable by XSLT 1 + EXSLT? Honestly, I don't know. I'd love to hear some feedback on this whole issue. On the other hand, once your toolkit supports XSLT 1, how much more difficult would it be to just go ahead and implement XSLT 2 (or at least the "basic XSLT processor" model)? As we add more and more to EXSLT, does it make the migration to an actual XSLT 2 implementation that much easier?

Others use more traditional, procedural languages as their XML power tool. As I continue this XSLT investigation, I'm going to try to implement ml-macro in Python using 4Suite, as well. That will help me understand the different feel of different approaches. I'll post the results (or at least the code) here when I'm finished. For right now, I'm just glad I can leverage Norm's macro technique using XSLT 1 and EXSLT.

This page was last modified on 2006-02-03 00:00:00Z.

This page was first published on .

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

See the version of this page with comments enabled to read or add comments.