Re: [xsl] 1.0 and 2.0 and suitability for tasks

Subject: Re: [xsl] 1.0 and 2.0 and suitability for tasks
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Wed, 24 Aug 2005 14:34:04 -0400
Jay,

At 01:33 PM 8/24/2005, you wrote:
> There are many jobs for which XSLT 1.0 is an excellent fit.

Which made me wonder which tasks are best suited to XSTL 1.0 and which are
best suited to 2.0.

Heh: that's the million-dollar question.


Note, however, that there's a subtle difference between my claim and your underlying assumption (which I do not necessarily disagree with) that not only are there jobs for which XSLT 1.0 is an excellent fit, but also that there are jobs for which it's a better fit than 2.0.

Because 2.0 will do everything that 1.0 will and more (and indeed, since its developers have gone to considerable pains to make sure, to whatever extent practical, that migration be relatively painless and that most 1.0 tasks -- apart from the sometimes-elaborate workarounds we have developed, whether they be credited to Muench, Piez or whomever, will be performed essentially the same way in 2.0) I would not necessarily expect to see many jobs about which we can say unequivocally "that's a job better done in 1.0".

On the other hand, there may be many jobs that are well enough done in 1.0, or that are effectively the *same* jobs done either way, and if a small company with no budget for software engineering (to say nothing of private individuals, departments in schools and governments, or other shoestring operations) is doing things successfully with 1.0, and has 98% of its requirements met this way, I am also not necessarily going to be quick to say "invest in 2.0", since they simply may not get enough bang back for their buck.

So the line won't be between applications better done in one and those better done in another. It'll be more of a question of whether 1.0 hits the sweet spot for you, vs. whether 2.0 provides such immense benefits over tortured 1.0 approaches that you can't afford not to do it.

My position involves a blend of both documentation (everything from user
guides to API guides and data dictionaries and the XSLT-based solutions to
produce them) and data (lots of transformation of data-centric XML). So I
would like to hear how one version or the other might benefit either
effort.

In this context, keep in mind that 1.0 was designed specifically with down-conversions in mind, aiming towards formatting, while 2.0's scope is much broader, having been influenced not least by the uptake of 1.0 *outside* its initial target market. So I'd expect roughly (no great wisdom here) that 2.0's extra power will be more useful on the data-centric side, and for cross- and up-conversions, which 1.0 didn't target -- while on the other hand, there will be a *few* problems even on the document-processing side (date handling?) for which we'll be grateful to have 2.0.


Also remember that we already know how to pipeline (and by all accounts pipelines work well) and there's nothing that says you have to use the same version of the language for every transformation in a pipeline (or indeed, XSLT at all). This isn't always going to be the best option (maybe you should just move to 2.0, or be ready to), but it's not unthinkable.

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

Current Thread