Re: When *not* to use XLST...
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:
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.
====================================================================== 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 ======================================================================
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format