Anyone who looks into my experimental outliner with notes, clown, is sure to notice that the native data format is EDN (Extensible Data Notation).
The canonical data representation for outlines is OPML (Outline Processor Markup Language) and it is well suited for that purpose. It’s a dialect of XML especially adapted to outliners.
So, why use EDN? Rich Hickey gives a good rationale at the link above. But for me it boils down to a few things.
You know how people use Node.js to let them use the same language on the server side and client side of an application? Clojure and Clojurescript serve that same purpose. EDN extends that to representing data. It’s a subset of the Clojure language well adapted to data.
It’s human readable (most programming languages are). And since it’s a smaller version of Clojure, manipulating it is already built into Clojure development tools. Also, parsing it is already built into Clojure/Script. There are no additional libraries to download and figure out.
After seeing it, some might argue that it is just a “Clojurey” version of JSON (Javascript Object Notation). Not really. EDN has more base data types built into it. But the key feature is its extensibility. You can extend it to handle essentially data type, including user-defined types by adding some simple functions to do the conversion. There are examples in this blog post
So, it’s all one big happy family – server, client and data.