Upgrade Schematron compilation XSLTs to XSLT 2.0

[vincentml]

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.

[ndw]

+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.

[phax]

I changed it locally in my project in commit phax/ph-schematron@7dbc1d4 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

[tgraham-antenna]

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.

[ndw]

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.

[tofi86]

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...

[phax]

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.

[tgraham-antenna]

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.

[ndw]

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