XMLTools with XSLT 3.0 support updated to latest SaxonC HE 12.9 release
-
The XMLTools plugin so far provided XSLT 1.0 support based on Microsoft’s MSXML. As the current version of XSLT, since 2017, is XSLT 3.0 and, while Microsoft never supported it nor XSLT 2.0 (from 2008), there are by now third party solutions like SaxonC (exists in an open-source HE editions) that allow the use of XSLT 3.0 from C++, it would be nice to allow the use of XSLT 3.0 in addition to XSLT 1.0 in Notepad++ with XMLTools.
I have therefore tried to fork XMLTools and have managed to integrate SaxonC HE 12 to provide an additional menu entry to run XSLT 3 (against XML or against JSON or against no input (starting with the named template xsl:initial-template)); today I have updated the fork to integrate the latest SaxonC HE 12.9 release.
A first zip with that new release is at https://github.com/martin-honnen/xmltools/releases/tag/3.1.1.16-beta1, let me know here or on Github whether it works for you.
-
Please be careful when forking and keeping the original name for an apparently-abandoned plugin. Sometimes, it turns out it wasn’t as abandoned as thought – something like that happened with NppConsole plugin (as obliquely mentioned in a recent Topic here): a few years ago, it appeared abandoned, so a regular here took the source code, and made their own fork, but kept the original name (thinking it would be safe, because it appeared to be no longer supported in the original channel); but then, fast forward a few more years, and the original author did provide their own upgrades to the original plugin – so now there are two competing development paths, each having version numbers not present in the chain for the other, which will make any future questions in the forum confusing, as to which NppConsole plugin is actually being talked about.
Similarly, if morbac ever decides to come back to the plugin, then your fork and the original could have conflicting and/or confusing version numbers and naming.
I would highly recommend coming up with your own name for your product, if you are planning to continue development and support on your version of the plugin. If it’s really just a one-off thing, and you aren’t planning on future bugfixes/improvements/support, then it’s up to you whether it’s worth the rename; but if you want to continue to work on the plugin, then I’d suggest the rename.
OTOH: if you can get permission from @morbac to take over completely, then it’s safe to keep the original name, because you’ve got the permission. (It’s most clear, in cases like that, if you can get write permission to the original repo – @chcg was able to do with @bruderstein’s PythonScript, and that sense of continuity makes it more obvious that his is still the “official” PythonScript.)
