Skip to content
This repository has been archived by the owner on Nov 2, 2020. It is now read-only.

Upgrade Schematron compilation XSLTs to XSLT 2.0 #55

Open
vincentml opened this issue Aug 16, 2017 · 9 comments
Open

Upgrade Schematron compilation XSLTs to XSLT 2.0 #55

vincentml opened this issue Aug 16, 2017 · 9 comments
Labels
enhancement infrastructure Housekeeping review wanted Needs review before acceptance

Comments

@vincentml
Copy link
Member

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
Copy link

ndw commented Sep 2, 2017

+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
Copy link

phax commented Sep 4, 2017

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
Copy link
Member

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
Copy link

ndw commented Sep 5, 2017

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
Copy link
Contributor

tofi86 commented Feb 8, 2018

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
Copy link

phax commented Feb 8, 2018

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
Copy link
Member

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
Copy link

ndw commented Mar 14, 2018

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

@tgraham-antenna
Copy link
Member

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement infrastructure Housekeeping review wanted Needs review before acceptance
Projects
None yet
Development

No branches or pull requests

5 participants