|
I'm going to go out on a limb, and try to argue against the naysayers.
I've worked with XSLT extensively, and it has featured prominently in most books that I've written since 1999 (seven in all). I've heard this criticism come up quite frequently about the utility of XSLT versus its complexity, and inevitably there are those people who cite it as being 1) too complicated to write, 2) too limited in scope as an integration language, and 3) over-utilized to solve common problems.
I think all three of these points are in fact straw-men arguments. In the first case, the single biggest problem that XSLT faces is the fact that it is not a language for manipulating scalars but rather for manipulating sets. This point is frequently lost in articles by people who are attempting to work with it in the same way they work with procedural code, because the two paradigms are very different. Indeed, this is one of the great unifying factors between SQL and XSLT -- while in both cases you can do scalar operations with the languages, what you will have is a very bastardized format that cannot even hope to compare to the same operations done in binary compiled form, yet if you use either SQL or XSLT as a set manipulation language, you can create code of both astonishing simplicity and great power. Is such code more complicated to write? Sure -- you're dealing with data at a higher level, and you're working with a pattern recognition technology rather than a simple assignment language. That's the tradeoff you face.
Along those same lines, if you use XSLT using comparable technologies, you will get comparable results. Both Java and MS have the ability to create compiled stylesheets that work at speeds comparable to other compiled entities. They have the advantage that, because the source code can be referenced externally when needed, updating such XSLT source makes it easier to distribute and update changes to the component.
The second case strikes me as true, but vaguely silly. There are a number of purists who argue that XSLT needs to be kept as simple and pure as possible, because it is only a stylesheet language, and so have deliberately hobbled it. There are many others, myself included, who see it as an ideal language for integration, recognize that XSLT stylesheets, of all XML technologies, are the least likely to need to maintain device independence, and feel that it works very effectively as a binding or integration language. I remember back in the early 1990s when VB first appeared -- its detractors argued strongly that it was not a "pure" language and would in fact be little more than a toy. Yet it was the ability of this language to act as an easy to use binding agent that made it so immensely popular, even if it wasn't rigorously object oriented or pointer-centric.
XSLT has already spawned a number of variants that are nearly identical in most respects, save that they permit the use of extensions. If you bind a regular expression engine into a compiled translet, for instance, you are working not at interpreted speeds but at compiled ones, just as you would with any Java bean or COM object. The XSLT 1.1 working draft proposal was a significant move in the right direction, and it would have effectively solved many of the same issues that are repeatedly (and to a certain extent validly) brought up when criticising 1.0 - creating an output mechanism, creating a standard for extensions, even streamlining the language a bit so that the result of called templates could be invoked from within an XPath expression, rather than using the very roundabout mechanism that exists now (and then only by extension). This work is carried on in the EXSLT site and the people that participate in it, and by and large the solutions that they are coming up with work VERY effectively in creating integrated components.
However, XSLT 1.1 was basically dropped from the W3C agenda precisely because there are many people who fear that it gives too much power into the hands of programmers, which is another way of looking at James Clark's statement that XSLT 1.0 was only intended as a stylesheet language. A large number of languages that were intended for very limited applications tend to find utility beyond those applications, and they grow in strength and power accordingly. I think it is a mistake to argue that simply because the original designers never saw the use of this language in this way that is it should be deliberately hobbled because of that.
This gets to the third point. XSLT's use has grown dramatically in the last couple of years, which is actually rather remarkable when you look at the fact that: 1) it is not a commercial product, which means that relatively few people actually make any money off of selling licenses on it, and 2) it invokes a very different paradigm than what most people are used to when dealing with computer languages. Most people when working with XSLT either love it or hate it (and most of the ones that hate it are also people that are most used to thinking in scalar or pointer referential terms -- C++ developers for instance). There is typically a period of anywhere from a couple of weeks to a couple of months that you have to work with it before you begin to "grok" the language, but while the initial hump to understanding is fairly steep, once you have that basic level of understanding you begin to appreciate just how powerful the language is, and you begin finding applications for it that you would never have even considered before. I used a very quick XSLT script the other day to convert an XML document with all uppercase tags into one with all lowercase tags, something that would have been a pain to do either with DOM or with Javascript but was trivial with XSLT.
There are always applications that XSLT is not useful for, or that its more effort to write than its worth -- but I'm finding, so long as I'm willing to cut a few corners on how pure I make the language, that there are fewer and fewer apps that don't fall into that category, especially now that more applications work via the transmission or receipt of XML streams. I think this is worrisome to companies like Microsoft that first endorsed XSLT but are now becoming less emphatic about it as they realize that XSLT can obviate a significant amount of the advantages that their own, object based technologies offer.
I am definitely in the minority in my belief of this, but I continue to press it because I think that it is a valid and important viewpoint. Rather than limiting the utility of XSLT, look at where people are using it and expand it accordingly. Especially in comparison to XML Query, which I see as in several respects a step back, XSLT has the potential to be an integral component of XML development in the future.
-- Kurt Cagle
-- Co-author, Profession XSLT
|
Previous Message
