Visual programming languages have been around since the 1960s (see, for example, [Boshernitsan1998]). Visual programming often uses the dataflow programming paradigm, whose description XProc matches exemplarily:

XProc is an “XML Pipeline Language” that was first specified in 2010 [XProc1]. Its main purpose is the orchestration of XML validation and transformation tasks that traditionally is done with scripting languages and tools such as Ant, Make, shell scripts, or custom Java programs. Two advantages of XProc are: 1. Processing happens in main memory, which means documents need not be serialized or even stored to disk between processing steps, and there are no penalties in JVM startup times that are often associated with shell script or Makefile orchestration. 2. There is no global state in an XProc pipeline, a thing that is responsible for unexpected side effects in Ant, Make or Shell scripts and that makes these programming languages unsuited for encapsulating possibly complex, re-usable functionality. XProc provides this encapsulation and composability in its processing blocks, the so-called “steps.”

It has been argued that, given the advances in XPath 3.1 and XSLT 3.0, together with extension modules for dealing with binary data, archives, HTTP APIs, etc., XSLT itself can now be used as a replacement for XProc pipelines [Quin2019]. While this is possible, XSLT does not offer or enforce the degree of processing block encapsulation that XProc offers and that is a prerequisite for creating a visual editor that lets users assemble predefined building blocks.

While XProc version 1.0 is primarily focused on processing XML documents, XProc 3.0  [XProc3] knows other document types, namely text, HTML, and JSON, but also arbitrary binary files, as first-class citizens. XProc’s main applications so far are in publishing, and publishing these days requires handling of non-XML HTML and JSON, in particular. XProc 3.0’s embrace of XPath 3.1 as its expression language and the XSLT and XQuery serialization 3.1 specification  [Serialization31] are key enablers of its more “webby” capabilities.

XProc 3 programs continue to be written in XML syntax, at least this is the only serialization that is specified for 3.0. When writing a browser-based editor, there probably needs to be some translation between the editor’s representation of a pipeline, be it HTML, SVG, or JSON, and XProc’s XML syntax. As it will be shown, the solution presented in this paper uses JSON data structures as the internal representation. Translation from XProc XML to this internal model and back to XProc XML will be done with XSLT 3.0 in the browser and the XPath 3.1 functions that convert between JSON and XML.

While the concepts of XProc seem straightforward at first glance – processing steps whose outputs connect with inputs of other steps – many users have reported difficulties in writing actual pipelines. This is partly due to the syntax. The concept of primary inputs and outputs and default readable ports (that is supposed to make pipeline documents less verbose) contributes to this reportedly steep learning curve.

Having experienced graph editors that also know the concept of multiple ports per processing unit, namely the Blender node editor [Blender] and the Lego Mindstorms visual programming environment, we at le-tex thought that connecting existing XProc steps graphically will help overcome the initial learning difficulties. It will also be useful to visualize complex XProc pipelines since the XML representation offers almost no visual clues (apart from adjacent primary output/input ports) which steps are connected and how data flows through the pipeline.