XSLT 2 backwards compatibility (wsd: Normalize / Simpl
Michael 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. Yes since posting that I have looked through the xslt 2 spec to see what changes would be made and I agree that they would probably be too intrusive. You could make xsl:variable in BC mode make some kind of RTF thing instead of a node set but then you'd have to make every xpath expression whether or not in BC mode know what to do with a variable of that type, and that's probably too much. However I think it probably is worth highlighting in appendix K. Currently you attempt a more or less complete list (in the no schema case) of differences between a non-error result on an xslt 1 processor and an xslt2 processor. Even if you can not list all cases where an XSLT 1 system would generate an error that is not flagged by an XSLT 2 system I think you could list the main ones and say that stylesheet authors SHOULD avoid using <xsl:stylesheet version="1.0" on stylesheets known not to conform to XSLT 1. In addition to this RTF/document node incompatibility, there's the extra xhtml unprefixed output type in xsl:version, and probably some other things as well... I was going to send a comment to the qt comments list but since you've responded here maybe that isn't needed? In a late "After PR and just before REC" change, it's interesting to note that XML 1.1 processors are now _forced_ to accept XML 1.0 documents and process then according to XML 1.0 rules, ie they must essentially be dual XML 1.0/1.1 processors. You probably don't want to force XSLT 2 systems to include an XSLT 1 implementation, although since BC mode is optional anyway I don't think that it would necessarily be a bad thing to say that if version="1.0" appears on xsl:stylesheet then a stronger notion of BC is invoked than if it appears on some subtree. Essentially that it has to be processed by an XSLT 1 compliant processor. I doubt you would want to do this (it makes it difficult to work on pre-digested data models as the data models are different, apart from any implementation/maintenance worries) but it should be clearly allowed. If I implement an xslt processor as if (grep 'xsl:version.*version=.1.0.' $1) then saxon6 $* else saxon7 $* fi I hope the result is a complaint version 2 processor. (I know the grep doen't catch all possible cases, but ...) David -- http://www.dcarlisle.demon.co.uk/matthew ________________________________________________________________________ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ 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