[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

XSLT 2 backwards compatibility (wsd: Normalize / Simpl

Subject: XSLT 2 backwards compatibility (wsd: Normalize / Simplify HTML-Tables with row-span / col-span)
From: David Carlisle <davidc@xxxxxxxxx>
Date: Wed, 11 Feb 2004 13:48:33 GMT
xslt normalize
  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)
saxon6 $*
saxon7 $*

I hope the result is a complaint version 2 processor.
(I know the grep doen't catch all possible cases, but ...)



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:

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.