Re: The suitability of XSL

Lol. I think most of us have had some sort of analogous story at some point
in our careers. I here you about XSLT, its a mixture of boons and curses.
One minute you can love something it does quite elegantly and a minute later
roll your eyes at some horrible workaround necessitated by the smallest of
inadequacies. XSLT2 really is much better, but we'll probably all die of old
age before there is a processor supporting it that has perl bindings....

On Mon, Dec 7, 2009 at 12:19 PM, Peter T Cash <[email protected]> wrote:

> 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
>



-- 
The Wise adapts himself to the world. The Fool adapts the world to himself.
Therefore, all progress depends on the Fool.

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