As you can imagine, there's been a lot of debate about how to use the version attribute in the working group, and there's no one solution that meets all requirements. One of the aims behind the design that we adopted is that you should be able to mix 1.0 and 2.0 code. We felt that this was necessary to make transition as painless as possible. You should be able to include a 1.0 stylesheet module from within a 2.0 module, for example. XSLT 1.0 already allowed parts of the stylesheet to be labeled as "version='2.0'" so we had to support that. The data models for 1.0 and 2.0 are different, so an XSLT 1.0 processor won't understand data that's passed to it by a 2.0 processor, or vice versa. Therefore, a 2.0 processor must execute 1.0 code according to rules defined in the 2.0 spec, not according the the 1.0 spec. So we defined that version='1.0' would invoke processing according to rules defined in the 2.0 specification, but with backwards compatibility mode enabled to make the results as consistent as possible with the results produced by a 1.0 processor, subject to the differences that are necessary because the data model is different. We also tried to take into account that the purpose of BCM is to provide a bridge between 1.0 and 2.0, and that both transitions (from 1.0 to 2.0+BCM, and from 2.0+BCM to 2.0) should be as painless as possible. Some working group members did argue that specifying version="1.0" should mean that the stylesheet is guaranteed to be processed according to the XSLT 1.0 specification. This would essentially mean that a 2.0 processor is required either to reject such a stylesheet or to delegate its processing to a 1.0 processor. This would allow no mixed-mode working, and it would mean for example that sections of a 1.0 stylesheet labeled as version='2.0' would be processed according to the 1.0 spec: that is, they would error if they contained any 2.0 constructs. My own experience of migrating real stylesheets has been that there have been very few problems, and that they have generally related to use of extensions rather than to facilities in the W3C specs. If anyone does have any negative experiences of migration, I will be very interested to hear them (ideally, send them direct to the public-qt-comments@xxxxxx list). The idea of creating tools to help in the conversion is an interesting one, but such tools would be quite tricky to write. They couldn't be written in XSLT, because they would need to do detailed parsing of the XPath expressions. For example, one would want to take the XPath expression "X < Y", do type inference on it, and if there is any possibility that both X and Y are non-numeric, replace it by the construct "some $x in X, $y in Y satisfies number($x) < number($y)". Saxon's approach instead is to give you a warning message if it encounters such a construct, and allow you to make the change by hand. (As an indication of how rare these situations are, I found I had to write new tests to invoke these warnings: they weren't coming up from my existing XSLT 1.0 test suite). Michael Kay > -----Original Message----- > From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx > [mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of > David Tolpin > Sent: 17 February 2004 09:23 > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx > Subject: RE: Normalize / Simplify HTML-Tables with > row-span / col-span > > > > An XSLT 2.0 processor is *not* required to detect every time you do > > something that wouldn't have been allowed under 1.0 and > reject it if > > the stylesheet says version="1.0". That would be far too > burdensome, > > especially for facilities like this one where it would > require extra > > information to be maintained at run-time. > > On the other hand, the common software practice has been to > honour versioning. For example, XML parsers should use > different lexical parsers for XML 1.0 and XML 1.0+Namespaces. > Regex-based utilities on BSD flavours of Unix allow to choose > between basic and extended syntax; and if basic syntax is > chosen, any construct from the extended syntax is an error. A > C compiler that supports both K&R C (as described in Version > 6 Manual) and ANSI/ISO C is expected to report things which > are not traditional when invoked in traditional mode. > > Is 'version="1.0"' a documented hack to quickly use XSLT 1.0 > stylesheets with an XSLT 2.0 processor without warranty? > Would not a transformation expressed in XSLT 2.0 that turns > XSLT 1.0 into XSLT 2.0, incorporated in or appended to the > specification, be more appropriate for this purpose? Ot is it > yet another bit I omitted from the draft? > > David Tolpin > http://davidashen.net/ > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format