I missed that point somehow:
The trouble is that XSLT allows regions of a stylesheet to belong to different versions. In XSLT 1.0, you can put an xsl:version attribute on any literal result element to indicate the version of XSLT used in the content of that element. In XSLT 2.0, any XSLT element can have a version attribute, and any other element can have a xsl:version attribute that does the same thing.It can be quite useful when upgrading stylesheets step by step, but I don't think such mix is useful otherwise provided huge difference in XPath 1.0 and XPath 2.0 data models and XSLT 1.0 and XSLT 2.0 behaviours (even in backwards compatible mode). And it's a disaster for anyone impementing XSLT 2.0 from scratch. Now I wonder how are we going to implement this feature in the XQP project?
The rationale is that it allows you to upgrade part of your stylesheet without having to upgrade all of it. The parts of an XSLT 2.0 stylesheet that are marked as XSLT 1.0 run under backwards-compatibility mode, which means that (in general) things work as they did under XSLT 1.0 (e.g. you have weak typing, first-item semantics, numeric comparisons). This is handy if you have a big XSLT 1.0 stylesheet, and you want a little bit of XSLT 2.0 functionality but don't want to upgrade the entire thing just now.
Jeni Tennison in xsl-list.
Leave a comment