Indeed! One way to think about it is that there could be many export programs, even to the same file type. So it would really be more like:
[graphviz engine=dot]
digraph {
rankdir=LR
subgraph cluster1 {
whateverIn [label=whatever]
}
subgraph cluster2 {
peripheries=0
json [label=JSON]
}
subgraph cluster3 {
latex1Out [label=latex1]
latex2Out [label=latex2]
latex3Out [label=latex3]
HTML1Out [label=HTML1]
HTML2Out [label=HTML2]
HTML3Out [label=HTML3]
}
whateverIn → json
json → latex1Out
json → latex2Out
json → latex3Out
json → HTML1Out
json → HTML2Out
json → HTML3Out
}
[/graphviz]
The advantage is that import is factored out from export, even if there is a lot of experimentation going on in what the structure of the export is within a given format — getting to a “templating” situation where there is a single workflow but lots of “templates” is still progress.
In the case of your (very 
) tree builder, I would suggest you have actually written two “renderers”:
- your own renderer code to draw a tree to a
<canvas>element (wow!). - A LaTeX generator which produces code that can be pasted into a LaTeX document
If I may, here’s how you might consider using a “JSON in the Middle” approach for this project. Right now, you’ve got a system which has a kind of “wizard” UI — buttons are generated dynamically as the user is progressing down the tree (again, ).
I would argue that there is a kind of conversion going on here, but it’s an implicit one, and in your current design, it’s done progressively. So you fill out an input and then click to add a node, and then 1) the LaTeX tree and 2) the canvas are updated. So it’s essentially like (yes, I am having too much fun with the graphviz plugin:
[graphviz]
digraph {
rankdir=LR;
click → “update canvas”;
click → “update LaTeX”;
}
[/graphviz]
But those things could be factored I to their own modules, I guess you would say:
[graphviz]
digraph {
rankdir=LR;
gui → JSON;
JSON → “update canvas”;
JSON → “update LaTeX”;
}
[/graphviz]
In other words, you think of it as a two-step process. This is good because maybe you can re-use the canvas or latex generation code. Or maybe you can plug your tree structure into some other visualization library.
I think it might sound like I’m in the land of wishful thinking in terms of how realistic it is that JSON is any more “universal” than anything else. It’s not, it’s just that it’s much easier to parse in most programming languages.
Tree data specifically is kind of quasi-standardized — glottolog for instance offers something called newick format, which is actually from biology. (Their JSON format is kind of disappointing actually since it just stick newick in a string.)
But you basically have nodes with attributes
and a list of children — these are typically represented as an object with an array of other nodes as the value of a “children” or “data” property. In fact your tikz thing is quite close to that.
Anyway. I’m not sure I’m making much sense but I do think there is a commonality form the problem you’re solving and the one @rgriscom was solving in his Flextext to Plaintext post. First build the data structure, then build the output whatever could work in both cases.