> 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. Understood. Still the idea that the same stylesheet executed with XSLT 1.0 and XSLT 2.0 would give different results concerns me. Does XSLT 2.0 supercedes XSLT 1.0, or does it specify a different language? That is, after deployment of XSLT 2.0, would XSLT 1.0 compliant implementations be deprecated? As with SAX 1.0? Or is it a different language, such as C and C++? > > 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. It should somehow be stated very clearly and in very bold font that an XSLT stylesheet accepted by XSLT 2.0 processor and having version="1.0" on its document element is not necessarily a valid XSLT 1.0 stylesheet. And even if it is, it can produce different results when run by XSLT 1.0 processor. I would prefer a variant of 'import' instruction with imported-stylesheet-version="1.0" as an attribute, so that I can explicitely say that I know that what I am importing is an XSLT 1.0 stylesheet which I am going to use within the framework of XSLT 2.0 data model. I would prefer version="1.0" to mean what it does, that is, that it is a program in XSLT 1.0. I am not sure whether my notes are relevant or I am missing a point again. > 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)". Michael, please view my comments as friendly ones, not as rant or troll. I see the quote above as a flaw in XSLT 2.0; XSLT transformations have been used to convert XML and XSL data conforming to different drafts of XSL (FO); there are stylesheets to convert RELAX to Relax NG (which are different languages), there are stylesheets to convert between XML and compact syntaxes of Relax NG. XSLT 1.0 has been powerful enough to perform tricky transformations for the tasks listed above; XSLT 2.0 has string-oriented constructs as well (although not structured -- what I mean is that operators in regular expressions are not a part of the language, but are inside literals, I still think it is a wrong approach) and should cover things which were difficult in XSLT 1.0. Yet it turns out that XSLT 2.0 is not upto the task of converting from XSLT 1.0 to XSLT 2.0. David Tolpin http://davidashen.net/ 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