Open vincentml opened 7 years ago
ndw
commented
7 years ago +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
commented
7 years ago 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
tgraham-antenna
commented
7 years ago 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
commented
7 years ago 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
commented
6 years ago Suggestion:
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
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago By the way, I have my first request for XSLT 3.0 support, https://github.com/ndw/xmlcalabash1/issues/267
tgraham-antenna
commented
4 years ago 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.
http://saxonica.com/html/documentation/conformance/xslt30.html
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.