Using tree-structured data and reference data types,
programmers can represent arbitrary graphs.
This is very convenient with a single process,
but it isn't well supported (let alone standardized)
by most serialization formats.
Nor is there common support for (say) multiply-indexed data.
So, the reader and writer have to agree -- out of band --
on ways to specify the necessary post-load processing.
Consequently, programmers commonly find themselves
defining ad hoc
idioms (and writing the code to support them).
This seems like a massive waste of effort,
with many opportunities for confusion and error.
Here are some approaches I've encountered;
please let me know about anything interesting that i've missed:
Rich Hickey's edn-format
(extensible data notation) proposal has no provision for graphs or reference types.
However, its extensibility can be used to generate them (and much more).
Basically, the idea is that the writer can precede any readable element
by a tag
that indicates how the reader should process the element:
... A tag indicates the semantic interpretation of the following element.
It is envisioned that a reader implementation will allow clients
to register handlers for specific tags.
Upon encountering a tag, the reader will first read the next element
(which may itself be or comprise other tagged elements),
then pass the result to the corresponding handler for further interpretation,
and the result of the handler will be the data value yielded by the tag + tagged element,
i.e. reading a tag and tagged element yields one value.
This value is the value to be returned to the program
and is not further interpreted as edn data by the reader.
Because the writer is limited to tags that the reader supports,
this seems both flexible and safe.
However, a possible downside is that readers and writers
have to agree in advance about the tags that they intend to use.
So, perhaps we need a "standard vocabulary" of tags.
(see also JSON-LD 1.0
has various approaches (eg, Data Indexing, Named Graphs) that look promising.
I'm still looking into this, so I'll withhold comment for now.
provide a direct,
if somewhat limited, solution to the problem:
In this YAML snippet,
refers to the same list
that the key path
Unfortunately, YAML does not support
This keeps YAML from supporting arbitrary graphs,
which can contain cycles.
Even when no cycles are involved,
the ordering limitation may result in awkward code.
This wiki page is maintained by Rich Morin
an independent consultant specializing in software design, development, and documentation.
Please feel free to email
comments, inquiries, suggestions, etc!