The suitability of XSL

Sorry, but I can't resist a good old-fashioned religious flamewar. 8)
> 
>   Robin Berjon writes
> 
> > Dude, the hype around XSLT died off about ten years ago :) I reckon
> > nowadays most of the people who use it know why they're using it,
> > and if anything people who could benefit from it don't because of
> > its bad reputation 
> 
>   I did not even know that XSLT had a bad reputation. I wonder
>   where I have been living all these years ;-). The XML::LibXSLT
>   engine is really fast, that why I use it, for certain jobs.

That's right...I'm one of those people who uses XSLT when it's 
appropriate...and doesn't use it when it's not. Telling the difference is 
the important and sometimes difficult part, of course. 

We have huge XML documents that have to be translated into over a dozen 
languages, and output as CHM help modules as well as PDF. There's no way 
we could do a lot of the jobs we have to do without XSL: just the 
conversion to HTML, the creation of the TOC and Index files, etc. is MUCH 
easier in XSL than it would be in some programming language that would 
require me to do string processing instead of XML rules-based 
transformations. 

And then there was the nine hour program. My boss told a co-worker who 
knows something about programming (but not enough) to write an XSL that 
would search a 20M XML file for duplicate ID values. These were attributes 
attached to certain elements (of the form id="xxxxxxxx"), and the IDs were 
supposed to be unique. However, the editors kept screwing up by copying 
and pasting text when they made revisions, so we had to have a way to find 
these dupes, or the process would break down when it came to production 
time. My co-worker wrote an XSL that did the job...after running for NINE 
HOURS on a reasonable workstation PC. During the "code review" for this 
program I politely mentioned that this was an awfully long time, and 
that--ahem--certain efficiencies could be introduced to make it run 
faster. One of those efficiencies was not to do this in XSL at all--this 
was a job for Perl. But my boss ignored me, as he usually does. I tried 
gently advising my co-worker, but he ignored me too (my stock isn't too 
high around here; I'm perceived as a trouble-maker). It wasn't really the 
co-worker's fault--he had been told to use an inappropriate tool, and 
didn't really have the experience to recognize this as a classic problem. 

I finally cracked one day when, during a phone conference with our 
European counterparts, my boss said that extra time had to be built into 
the schedule to accommodate the Nine Hour Program. This was making us all 
look like idiots. So I went to my desk, did a quick Google for a Perl 
solution to this well-known old chestnut, found four lines of code that I 
could use, and wrote a Perl program (integrated into a GUI wrapper) in two 
hours that did the same as the XSL. It ran in TWO SECONDS (CPU time). I 
then sent out an email that announced a new tool I was releasing, and 
mentioned that it had an additional feature--a duplicate ID search that 
ran a bit faster than the one we had. 

(Off-topic: The funny thing is that I expected two sorts of outcome: I 
would either be punished for exceeding my instructions, or they'd just use 
the program without a word of acknowledgment. Lucky me, I got the second 
possibility. On a totally unrelated note, my boss has been promoted and is 
moving across the country. I am delirious with joy.)

So there you have it--instances where XSL is the right tool for the 
problem, and an example where it was the wrong tool. 

I have to agree that XSL has its ugly aspects. In fact, when I'm writing 
an XSL, I spend half my time thinking what a cool language this is, and 
the other half cursing its sheer perversity (and verbosity). In general, 
XSL 2 got rid of a lot of things that bugged me in the first version. For 
example, it's much easier to output multiple documents, and "tunnel" 
parameters allow you to make some variables known to all descendants of a 
template, while still controlling their scope. (As opposed to passing the 
parameters to every descendant template until it finally gets to the one 
template that needs them.)

Anyway, I guess my point is that a toolbox that contains more than just 
one kind of tool is what you should want to have. You shouldn't be 
carrying around a toolbox that just contains a very complete selection of 
hammers. 

Peter


_______________________________________________
Perl-XML mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs