![](https://seccdn.libravatar.org/avatar/3035b38ff33cf86f480bb169b8500b80.jpg?s=120&d=mm&r=g)
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c17
--- Comment #17 from Thomas Schraitle
[...]
XSLT-2.0 and is not backwards compatible.
Actually, this is not (entirely) true. :) I guess I need to shed some more light on this issue: According to the XSLT 2.0 spec (http://www.w3.org/TR/xslt20/#status): "Many new features have been added to the language (see J.2 New Functionality) while retaining a high level of backwards compatibility (see J.1 Incompatible Changes)." This "backwards compatibility" is definied in section 3.8 Backwards-Compatible Processing (http://www.w3.org/TR/xslt20/#backwards). So what does it mean? You *can* pass a XSLT 1.0 stylesheet to a XSLT 2.0 processor. In such a case, the 2.0 processor falls back to a 1.0 compatibility mode. However, this will only work if you stay completely in the *realm* of XSLT 1.0. As XSLT 1.0 was (and is) very restricted, there was an urgent need to add more functionality. For example, XSLT 1.0 can only create *one* output document which is one limitation and very unsatisfying. For such cases, XSLT provides in its core language the possibility to enhance its functionality with "extension functions and elements". Hence the X (eXtensible) in its name. However, such extensions are completely ouside of XSLT 1.0. They don't belong to the core language anymore and most of them are processor dependent. Unfortunately, to provide a certain functionality, the DocBook stylesheets, for example, has to rely on these extensions. Otherwise it wouldn't be possible to process a DocBook document and create several HTML files. Exactly these extensions create most of the problems. So it doesn't help to pass a XSLT 1.0 stylesheet which contains these extensions to a XSLT 2.0 processor -- it won't work as the 2.0 processor does not know these extensions. In other words, a 1.0 stylesheet which uses such extensions have to become a 2.0 stylesheet. It needs to be rewritten completely. This is not always as easy as it sounds. For the DocBook stylesheets, this is currently in progress. However, they are not finished yet and as such not in a production stable state as the 1.0 stylesheets. I guess, there are other stylesheets (TEI?) which need also extensions and are as such also "incompatible" with XSLT 2.0. Hope that gives you some more insight.
(*) Which packages fail with saxon9? xep. epubcheck? Any other?
Well, the most important part are the DocBook stylesheets. ;) They are based on XSLT 1.0 so they require a XSLT processor which understands version 1.0. This is the case for Saxon 6, but not for Saxon 9 (as I tried to explained above). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.