The criteria for selecting a graph editing framework were partly XProc-related, partly informed by current software development trends and user expectations:
browser-based
interactive
customizable
provides ports
supports encapsulation (hierarchical graphs)
open source
A market research of graph editing frameworks, excluding those that don’t run in browsers, led to the following score matrix:
| GoJS | JointJS | NoFlo/FloHub | vis.js | yFiles | |
|---|---|---|---|---|---|
| interactive | yes | yes | no/yes | yes | yes |
| customizable | yes | yes | yes | yes | yes |
| encapsulation | no | yes | yes | no | no |
| ports | no | yes | yes | no | yes |
| open source | no | yes | yes/partly | yes | no |
The Javascript framework that was selected for xprocedit is JointJS [JointJS]. Although it needs to be said that XProc pipelines are, by far, not a graph type that is supported by JointJS out of the box, its basic support for graph editing, for storing a graph model and for rendering a model as SVG has been very helpful.
NoFlo was a contender, but JointJS was chosen after initial experiments were promising. NoFlo didn’t enter the experimental phase, therefore we cannot say whether it would have required less customizing.
Auto-layout was not an initial requirement, but many of the frameworks support it and it will be put to use in particular after loading an existing XProc pipeline.
The choice of XSLT 3 and Saxon-JS for converting back and forth between the browser representation (be it SVG or Javascript/JSON) and XProc XML was never really disputed. This is in spite of Saxon-JS not meeting the open-source requirement that we imposed on the graph editing framework. The rationale for this is that we regard XSLT 3 in the browser as a strategic choice of technology, and we want to support the only existing implementation. Graph libraries for the Web, on the other hand, do too little for XProc-style graphs out of the box to justify an investment in a commercial graph library.