RE: XSLT 2.0 *and* XSLT 1.0 validation -- how to?

> So better to have the stylesheets as 1.0, but individual templates as 
> 2.0?
> 

If you want to develop a stylesheet that's capable of operating on a 1.0
processor but can also take advantage of 2.0 features when available, then I
would be inclined to put the 2.0-dependent parts in separate modules, and to
assemble the complete stylesheet from different combinations of modules in
the two cases. This isn't the only way of doing it - you could also exploit
1.0 forwards compatibility mode - but it's probably the cleanest.

If you're in transition from 1.0 to 2.0, and want to do the conversion one
small step at a time, but without a need to keep the stylesheet working
under 1.0, then there might be some sense in using the version="2.0"
attribute only around constructs that require (or have been converted to)
2.0. Unfortunately, though, the obvious place to put such a version
attribute is on the xsl:template elements, but 1.0 doesn't allow this - it
allows it only on the xsl:stylesheet element or on literal result elements.
So again, moving the 2.0 code into a separate module that you then include
might be a more workable solution.

Incidentally, we have recently changed the XPath rules so that backwards
compatibility mode really means what it says - if your stylesheet specifies
version="1.0", you now continue to get all the old XPath 1.0 quirks, for
example that ["4.0"<="4"] is true while ["4.0"<"4" or "4.0"="4"] is false.
Although this reduces the problem in moving from 1.0 to
2.0-in-compatibility-mode, it's not a panacea, because the same problems
still exist, you now get them when moving from 2.0-in-compatibility-mode to
"2.0 proper". This is particularly true for the introduction of string
comparisons, where the meaning of a construct like @price<@discount now
changes between 2.0-in-compatibility-mode and 2.0 proper.

Michael Kay