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