Releases. Lots of releases.

Volume 5, Issue 6; 18 Jun 2021

Release the Krak…all the things! I’ve been pushing a bunch of related, if not exactly dependent, projects forward. I think I’ve pushed new releases of all of them now.


The centerpiece is the work I’ve been doing on the XML Resolver. I summarized that work recently so I won’t repeat it here. The resolver has hundreds of unit tests, but writing a sample application functioned as a good integration test and flushed out a few more bugs. I’m pretty confident of the current beta release, but I’d love to hear from someone else who’s tried it.

XML Resolver SampleApp version 3.0.1beta3

I released the sample application that you can use to try out the new features. It will do well-formed or validating parsing, RELAX NG and/or XML Schema validation, and XSLT transformations. In any combination you’d like.

The distribution is a self-contained, complete application and the project README file includes a full set of sample recipes to try out. Suggestions for more most welcome.

I’ve updated the XML Resolver website with new documentation for the 3.x release. At the moment, this includes updated documentation about the features of the resolver and the JavaDoc for the source code.

I haven’t yet tried to rework the various sources of information about catalog resolvers in general, but it’s on my list.


A few years ago, I pulled together a Maven release of DocBook 5.1. I’m not actually sure how I did that; I’ve learned a lot about Maven Gradle since then and that may have been a one off. In response to a bug report and also because I wanted to provide a catalog file that the XML Resolver could find automatically, I reworked the build process to produce a Maven release of DocBook 5.2b10a4. (That’s the current test release for the latest beta release of what will be DocBook 5.2.)

Note that I’ve changed the artifact ID; this was the recommended approach because I changed the APIs.

❺ Gradle RELAX NG validate and translate plugins

In order to build and publish a DocBook schema release, there are a bunch of transformations that have to be done, some XSLT, some Trang, and a bunch of validations with Jing. That used to be done with a nice XProc pipeline, but I haven’t got my XML Calabash 3.0 release far enough along yet so I punted back to doing them the hard way.

But the hard way (running each process as a JavaExec task) was slow and inconvenient.

I learned a lot about writing Gradle extensions from reviewing (and patching) Eero Helenius’ saxon-gradle plugin. I thought I could adapt the ideas in that plugin to do plugins for Jing and Trang. Along the way, I also worked out how to call the Jing APIs directly instead of the now moribund “Multi-Schema Validator” written back in the Sun Microsystems days by Kohsuke Kawaguchi of Jenkins fame.

Aside from some weirdness with a lot of tasks running in parallel, they work really well and have made the whole build much faster.

DocBook xslTNG 1.5.0

The XML Resolver isn’t just useful for validation, it’s useful for anything that reads URIs, including stylesheets. I wanted a stylesheet release that would include catalogs that could be found automatically, so I reworked the DocBook xslTNG release. Along the way, I fixed a few bugs and implemented a feature I saw in the online JATS documentation.

DocBook: The Definitive Guide, 15 June 2021 (I think I forgot to bump the version number.)

When Tommie spoke at MarkupUK about tag sets, I noticed that the marginal table of contents on the JATS documentation included a search feature. (This wasn’t relevant to Tommie’s excellent talk, it’s just something I happened to notice.) I didn’t see any reason why the xslTNG marginal table of constents (the “persistent ToC”) couldn’t have that too!

So I implemented it and rebuilt The Definitive Guide. The persistent ToC button doesn’t appear on the home page for the guide. I’m not sure if that’s a bug or not.

❽ Gradle saxon-xslt plugin

I’ve also published my fork of Eero’s Saxon XSLT plugin. I’m still hoping this is a transient plugin and that my patches back to the upstream project will be accepted. But I wanted to be able to use my version directly in build scripts without special casing, so I pushed it to the plugin registry.