Shawn,
I'm not going to second-guess whether you're deciding correctly
whether to use XSLT. I concur with others on their important points.
Nothing you have described is particularly difficult with XSLT, to
someone who isn't guessing -- indeed it sounds fairly easy and
straightforward. Yet it's only fair to acknowledge that there's an
up-front cost, since one does need to take a bit more care when
learning XSLT than one might with other languages; guessing will get
you into deeper trouble sooner.
At 04:22 PM 4/23/2009, you wrote:
Ha ha, no I didn't write that. I doubt many on the list would
appreciate the XSLT-bashing, followed by this conclusion:
"Now that we know XSLT is evil..."
The author then goes on to say what people should use instead.
However, I think the author isn't trying to be a jerk -- he's just
ignorant about XSLT.
He's trying to be serious, but also funny and flippant (as in the
line you cite). This backfires on him. And clearly he's in over his
head with the language. Maybe he's a smart fellow who's used to being
able to get things working quickly, but his skills just aren't
serving him, so he blames the language.
Yet anytime someone's criticism takes the form of "Language X stinks
because you have to do Y this way", followed by a piece of atrocious
code, a reader should be careful. Any real language offers more than
one way to do any one thing, so prima facie, any such statement is a
lie, and he's setting himself up for a fall at that point -- which
happens as soon as you look at the code, and are embarrassed at the
reminder of some of the things you used to do the first week you were
messing around with it. Shudder.
Be that as it may, I think the deeper issue (and the one that's
actually relevant to your concern), which he almost but didn't quite
touch on, has nothing to to with code aesthetics or a developer's
comfort level or how "natural" a language or technology is.
(Personally I've never found procedural code more "natural", just
more tedious, and I'm not even a mathematician.) Rather, it's in the
implications of adopting a particular technology for long-term
development and maintenance given an evolving problem domain.
In other words, it's not the one-off throwaway application, or the
black box, or the web site that has to last just three years or five,
where the difference will be felt. It's in the really open-ended,
distributed, long-lived systems.
If I hadn't had the discussions I've had on this
list and I read the article and the code snippets he provided, I'd
probably never look at XSLT again. The problem I had (and I assume the
author has as well) is that I approached it as a simple markup
language that one can just pick up right away to transform XML. It's
not. One needs to take the time to learn the ins and outs, the syntax,
and the capabilities (so they don't just bitch that "XSLT can't do
what I want").
I submit that the real reason for this is that the set of problems
faced by a general-purpose document transformation technology is
actually larger and more difficult than many developers and
data-processing folks have any inkling of. If you come out of
typesetting, you know something about this. (Or if you've been around
the block a few times, and learned some humility in other ways.)
But it's a sad truism that no one is ever as smart as they are in
their twenties. Then we start learning about all the things we don't
know anything about, and we get dumber and dumber.
XSLT is designed so that some of the kinds of things that are a real
bear in other technologies are simple and straightforward. In the
kind of data XML people are used to, irregular structures are not an
exception and a problem to be fixed: they are the norm, and correct.
Mixed content is not a sign of sloppy design: it is actually a clean
representation of an information set. Since "information" can be
defined, indeed, as "variation within regularity", such "sloppiness"
in XML source data is in fact *where the information is*, and can't
be casually ignored or refined away without destroying it. It simply
must be accommodated. XSLT does that gracefully.
The problem (although it lies with me and not XSLT) is that now that
I've been educated by the kind folks here, I don't have the time or
motivation to take a couple of days (or however long it takes) to
study XSLT so that I can continue my project. No time because this is
something I'm doing for work, and no motivation because I can use the
tools I already know with ease.
If that's the case -- and if your system is to be maintained by you
or others with your skills, and no one with XSLT proficiency is
likely to be around, then you are probably making the right choice.
Especially if, as you say, "I can use the tools I already know with
ease". If they're easy, that's an indication that you don't
necessarily have much to gain from XSLT.
This isn't to say that an XSLT-proficient person couldn't do it in
half the time with less error. They might. If so, that's a sign that
their investment in learning its ins and outs (as you put it) would
pay off for them, given this task. If you're never faced with other
kinds of work where it pays -- maybe this job is as close to an
arbitrary XML transformation as you'll ever get -- the calculation
will have different terms for you.
Cheers,
Wendell
======================================================================
Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================