An XSLT 2.0 processor running in backwards compatibility mode(due to
xsl:version=1.0) accepts an illegal XSLT 1.0 stylesheet, as
long as it is
valid XSLT 2.0(say, an if statement was in an expression).
Hence, one can
write an "1.0" stylesheet which works just fine with an XSLT
2.0 processor,
but is flagged as invalid at a static stage with an XSLT 1.0
processor.
Yes, that's correct.
What makes me wonder is because I find it hard to to motivate
this behavior or
see it in a practical perspective.
The WG didn't feel it was reasonable to expect a 2.0 processor to have
complete knowledge of which facilities are in 1.0 and which are new in 2.0 -
especially for things where the rules are relaxed at run-time such as RTF to
node-set conversion. Therefore it's not an error to say version="1.0" and
use a 2.0 feature.
Instead the version="1.0" attribute is used to switch behavior for a few
specific constructs: it simulates the 1.0 behavior for those constructs.
From one perspective, I think I find it annoying, because one
can't "simulate"
an XSLT 1.0 processor with the xsl:version attribute, and
hence be guaranteed
a stylesheet works with a "real" 1.0 processor
That's true: the WG felt it wasn't a reasonable requirement on 2.0
processors that they implement all the rules of 1.0 alongside those of 2.0.
Michael Kay
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--