schematron icon indicating copy to clipboard operation
schematron copied to clipboard

Upgrade Schematron compilation XSLTs to XSLT 2.0

Open vincentml opened this issue 8 years ago • 9 comments

http://saxonica.com/html/documentation/conformance/xslt30.html

From 9.8, XSLT 1.0 backwards-compatibility mode requires Saxon-PE or higher (that is, Saxon-HE will reject stylesheets that specify version="1.0").

The Schematron XSLTs currently use XSLT version 1.0. In order to keep compatibility with future versions of SaxonHE the Schematron XSLTs will need to be upgraded to XSLT 2.0.

vincentml avatar Aug 16 '17 23:08 vincentml

+1 for the same reason.

I just brute-forced all the 1.0's to 2.0's and it didn't fall over dramatically, but it would be good if someone with more experience could make sure that the 2.0 versions pass the test suite.

ndw avatar Sep 02 '17 15:09 ndw

I changed it locally in my project in commit https://github.com/phax/ph-schematron/commit/7dbc1d4385c72ba1025c09d47dd4c3d01af23d92 and experiencing no problem using Saxon HE 9.7 or 9.8 (except that 9.8.0_1 and 9.8.0_2 were not usable but because of other errors). hth

phax avatar Sep 04 '17 04:09 phax

It might need parallel XSLT 1.0 and XSLT 2.0 versions.

Not the best alternative, I know, but if a user is happily using, say, xsltproc, the user won't think that dropping XSLT 1.0 support is the best alternative, either. xsltproc had a new release just today, so you can't just say that XSLT 1.0 processors are either dead or legacy.

There is the option of saying that XSLT 1.0 support will disappear at a defined future milestone and seeing who howls, since right now we don't know who, if anyone, is using XSLT 1.0 with Schematron.

tgraham-antenna avatar Sep 04 '17 17:09 tgraham-antenna

Yes, parallel might be necessary. I tried to persuade the DocBook folks to move from the 1.0 stylesheets and got precisely that argument, that lots of places were still relying on xsltproc. :-(

But I do think Schematron has to work on Saxon HE 9.8 as well.

ndw avatar Sep 05 '17 02:09 ndw

Suggestion:

  • new Schematron versions are only compatible with XSLT 2.0, no more xsltproc (XSLT 1.0) support
  • no parallel development of an 1.0 compatible version
  • users of xsltproc need to use the "old" Schematron version which will never receive an update anymore

IMHO maintaining two versions is hard, PullRequests/fixes need to implement all the stuff twice, at some point we may want to use XSLT 2.0 features(!) (not only the version attribute 😏) and would have to try implementing those features in 1.0. Not a big fan of this idea...

tofi86 avatar Feb 08 '18 15:02 tofi86

Pragmatic approach: we basically need a different versioning scheme here. Use semantic version numbers (like 1.2.3), label the current version "1.0.0" (or whatever) and start with the next major release, that onlöy supports XSLT 2 and onwards. Add a test suite etc.

phax avatar Feb 08 '18 15:02 phax

XSLT 1.0 support is unimportant only if you're not using XSLT 1.0 yourself. There are some people who will not or cannot (because their clients will not) move away from XSLT 1.0.

I suggest that the 'Schematron' organization can have separate projects for 'schematron-xslt1' and 'schematron' (or 'schematron-xslt2'). We already have 'schematron-exist' and 'schematron-basex' projects, and they are probably more similar than the XSLT 1.0 and XSLT 2.0 versions will end up being similar. There will, presumably, eventually be a need for a 'schematron-xslt3' project, and dropping XSLT 2.0 in favor of XSLT 3.0 at that time will inconvenience a different set of users.

Having a separate, binding-independent (as much as possible) test suite will make it easier for an XSLT 1.0 project to keep up with changes in Schematron, just like it's meant to help all the other Schematron implementations.

No, we don't have enough active people to maintain parallel XSLT 1.0 and XSLT 2.0 versions, but that's because we don't have enough active people, period. We need to make it easier for people to contribute and to see their contributions be merged into the master branch, not to decide upfront that we don't have the people. Maybe we end up with an 'XSLT 1.0' team, or maybe the code just sits there in its separate project, but either way is better than having XSLT 1.0 support silently disappear.

tgraham-antenna avatar Feb 12 '18 21:02 tgraham-antenna

By the way, I have my first request for XSLT 3.0 support, https://github.com/ndw/xmlcalabash1/issues/267

ndw avatar Mar 14 '18 12:03 ndw

By the way, I have my first request for XSLT 3.0 support, ndw/xmlcalabash1#267

XSLT 3.0 support is the subject of #20.

tgraham-antenna avatar Feb 27 '20 23:02 tgraham-antenna