XSLT 2 backwards compatibility (wsd: [xsl] Normalize / Simplify HTML-Tables with row-span / col-span)

[David Carlisle <davidc@xxxxxxxxx>]

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