At 02:33 PM 9/18/2007, Sebastian wrote:
>Martin Holmes wrote:
>>I have moved all my recent projects over to 2.0; I wish there were
>>more than one implementation, but Saxon is very solid, and it's all
>>running under Cocoon anyway. 2.0 is such a breeze after all the
>>kludgy workarounds you have to do in 1.0.
>how long did it take you to find all the gotchas when you switched
>your 1.0 code to run
>in 2.0 mode? was it fairly obvious what to change? I am scared of
>trying; I worry
>that things will happen differently, but in non-obvious ways.
That's not nearly as bad as many of us feared. The fundamentals are
all the same; the things that have changed are mostly on the edges,
and almost all give static (compile-time) errors if you try relying
on 1.0 semantics in the 2.0 context.* Also, they're fairly well
documented. (For example, Kay's 2.0 book has an entire chapter on
them, which is blessedly short.) Then too, if you take a little care
it's not that difficult to set up a migration pathway with testing
along the way, to expose any gotchas. Quite often, this is as simple
as switching the @version attribute and seeing that the results are identical.
But the real benefits come with new stylesheets. There, you don't
have to worry about migration, you get all the 2.0 benefits up front,
and you learn the slight differences along the way. (Ah, I see Martin
has just said as much.)
I still write plenty of 1.0, for various different reasons including
its portability. But I have to write much less of the awful code
(pleasing for its ingenuity and nothing else) that 1.0 demands as
soon as it gets out of its comfort zone.
My advice to any XSLTer concerned about this is to look for
opportunities to try 2.0, just to get a sense of it. As soon as you
come to one of those moments when, as a 1.0 user, you inevitably say
"I wish I could X", the fun will start -- since chances are, you can.
After a few such successes, you'll find the idea of migrating a 1.0
code base to be much more enticing.
* For example, in 1.0, generate-id($nodes), when $nodes is bound to
more than one node, returns a generated ID only for the first one in
document order; in 2.0 you get an error if $nodes is more than a
singleton. An example where you don't get an error, but you do get a
change, is <xsl:value-of select="$nodes"/>; in 1.0 you get the string
value of the first node, while in 2.0 you get a concatenation of all
their values. But as long as your stylesheet says version="1.0"
you're in backwards-compatibility mode, meaning you'll get the 1.0
behavior even in a 2.0 processor. (Then too, some argue that you
should always say "$nodes" in any case if that's what you mean.)
The glass will look half-empty to you if you are faced with a
migration, but daunted by this sort of detail. It will look half-full
if you know enough to see how minor these changes are in the big
scheme of things -- especially when you consider what you get in
return, such as transparent processing of results, user-authored
functions, native grouping constructs, a much stronger XPath, better
support for i18n, more control of serialization and the rest. Or, if
you know little enough not to care, since you'll just learn as you go along.
Wendell Piez mailto:[log in to unmask]
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