, Issue 35; 15 Dec 2025

I’ve put up a preview of what I’m thinking about for a rebooted exproc.org website.

The EXProc.org website⊕At some point in the near future, that link is going to start pointing to the rebooted website, at which point you’ll have to trust me about how it used to be. is looking a little bit long in the tooth. It hasn’t changed since we published XProc 3.0 and it never felt like it was very successful.

There are at least a couple of steps that are now (or will soon be) implemented by both MorganaXProc-III and XML Calabash: the epubcheck step and the expand-templates step. The implementations are the same, so it makes sense to have a shared name for them. Users shouldn’t need conditional logic to switch between cx:epubcheck and mox:epubcheck when they are the same! (In fact, both those steps will likely become standard steps in the “p:” namespace eventually.)

That was my initial motivation for updating exproc.org.

Then I had a thought about user-contributed pipelines. Some sort of shared repository for user-contributed pipelines would be very useful. The following scenario is not uncommon:

1. Person 1: I think we need a step that will do “thing”.
2. Person 2: But a user could write that in XProc, it would be pretty easy.
3. Person 1: Hmm, okay, I guess.

Then you write one or I write one or someone else writes one, and maybe that’s okay for you or me or someone else, but it doesn’t help the next user who wants to do “thing”. We just have the same conversation again, except maybe I share the version I wrote. The new user then copies that version to their system, and maybe changes the name or the namespace. Now we’ve got at least two versions that will seem to be the same but will likely drift slowly apart.

Unideal.

In principle, someone could just publish the pipeline that does “thing” on the web and we could all share that. But you still need to be able to find them and if you put

<p:import href="http://example.com/path/to/thing.xpl"/>

at the top of your pipeline, you’re going to hit the web everytime you run it. That’s possibly slow, possibly doesn’t work, and might possibly be forbidden by local firewall rules. (The latter not being entirely unreasonable since you can’t actually know from one day to the next if thing.xpl has been changed!)

Then I had an idea. If the repository was immutable (as Maven Central is, for example), it would be possible to provide a downloadable archive and a catalog so that the URIs could be resolved locally. In fact, it might be reasonable for implementations to simply bundle the archive into their distributions.

So I sketched out what that could look like.

At this point, I should probably point you to the temporary staging area where I’m doing these⊕As above, at some point in the near future, when the exproc.org link is updated, the experimental site might go away. experiments:

https://exproc.datamagician.engineer/

If you look, in particular, at the contributed steps section, you’ll find a small collection of steps and a ZIP file.

Download that ZIP, unpack it,⊕In principle, you don’t even have to unpack it. Just pointing to the ZIP file as a catalog should work. And it does. Almost. There’s a small bug in XML Calabash that I’ll fix in the next release (whatever comes after 3.0.32). point XML Calabash at the catalog it contains, and you can import, for example:

<p:import
href="https://exproc.org/contrib/ndw/xslt-save/1.0.0.xpl"/>

without any network access. And because the contract for contributed steps is that they’re immutable after publication, you don’t have to go looking to see if it’s changed.

Might have legs. I dunno. What do you think?