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