A sensible consistency

I do lots of things with XML documents: validate them (with RELAX NG and XML Schema and Schematron), transform them, query them (with XQuery and XPath), expand XIncludes, pretty print, the list goes on and on. I do a different subset of things with text documents and JSON as well.

Consequently, I have lots of little shell scripts lying about that do one or another of those things. Or did once. If I haven’t used one of them in a while, the classpath will be wrong, the version of Saxon will be wrong, etc. So the first ten minutes of any given task is likely to be spent fussing with the shell script. If nothing else, I have to remind myself of what the arguments are and what order they go in.

Lots of my repositories have build scripts that do one or another of those things in some ad hoc way as well. That’s a tiny bit less inconvenient because the build tool will generally manage the dependencies for me. But it’s still a bit random and ad hoc.

And tedious.

At the same time, I also have an XProc implementation that has well defined, documented interfaces to all these tools, and more. So there’s an obvious answer, write⊕If I want to do more than one thing, for example: validate, XInclude, and transform, then this is the right answer, of course. a pipeline for each task and then run the pipeline.

Well, sure, writing a pipeline called xslt.xpl to run XSLT (with all the inputs and outputs and options) and one called xinclude.xpl to run XInclude, etc. would totally work.

But I’m lazy. The definition of the step is right there in XProc, why am I writing a pipeline to run it?

So I tweaked the --step option of XML Calabash. If you use the --step option without supplying a pipeline, it looks for an atomic step (even an extension step) with the type you specified, and makes it run as a pipeline.

Now, if you’ll excuse me, I have bunch of shell scripts to delete.

(This feature will turn up in “alpha19”, probably tomorrow.)