From: Michael Kay <mike@sa...> - 2007-04-30 10:48:25
> I thought that if using an XSLT version 2.0 construct that
> you should mark the stylesheet as version 2.0, and if you
> want xslt 1.0 to be able to process it, then you provide some
> fallback behaviour under the forward compatible processing,
> under xslt 1.0 spec.
That's a reasonable strategy. Another strategy is to use version="2.0"
around those parts of the stylesheet that use 2.0 constructs - for example
by putting all the 2.0-dependent parts in a separate module and marking that
module with version="2.0". Alternatively, if you want to use a 2.0 construct
in one particular place, and want backwards-compatible behaviour in the rest
of the stylesheet, and if you have no intention of running it under a 1.0
processor, then you can leave the whole thing labelled as version="1.0".
> But an xslt 1.0 processor on seeing a document marked as
> version 1.0 but using version 2.0 constructs will throw an
> error, rather than try and do fallback behaviour.
> Is that right?
> [I tried to do this last week, but got a bug report from
> someone using some widespread C library that didn't seem to
> correctly implement the forward compatible processing, so no cigar]
Yes, I think you're quite likely to find that some 1.0 processors have taken
short-cuts in their support for forwards-compatibility mode. It's the kind
of thing that you can get away with, it will be years before users notice.
In fact, we did a little survey and found there are one or two aspects of
forwards-compatibility mode that hardly any XSLT 1.0 processor implements
correctly, including Saxon 6.5 - notably the provision "if the element has
an optional attribute with a value that the XSLT 1.0 [sic] does not allow
the attribute to have, then the attribute must be ignored". This means, for
example, that if you find <xsl:template match="a[b=$x]">, then the correct
action for an XSLT 1.0 processor in forwards compatible mode is probably to
ignore the match attribute if there is a name attribute, and to report an
error if there is no name attribute (because the match attribute is optional
only if there is a name attribute). But in practice, ignoring the match
pattern because it contains an error doesn't seem very friendly, and taking
different action depending on whether or not there is a name attribute seems