Re: mapping data formats imported from C libraries

[Ted Zlatanov]

On Tue, 25 Nov 2014 18:06:37 +0100 Lars Magne Ingebrigtsen <address@hidden> 
wrote: 

LMI> Ted Zlatanov <address@hidden> writes:
>> Yes, but in a really sucky way. If you look at the libjson and json.el
>> output, it's much leaner. Mapping JSON up to XML pretty much guarantees
>> pain when you use it and on the way back.  Do you want to inflict that
>> on everyone in the name of a unified DOM?

LMI> The Emacs DOM is quite non-sucky.  It's just a tree.

LMI> (thing ((attrib . value)) (foo) (bar))

LMI> JSON maps onto it really nicely.  The attributes are always nil, though.

Yeah, I've seen the mess that libxml2 and json.el produce (not the
coder's fault, it's just a pain to adapt without native types).  It
doesn't help that XML/SGML and Lisp are inbred cousins :)

* it's a pain to distinguish JSON's `false' and `null' while using them
  in code

* in json.el you pick the key-value storage method! yay!

* in json.el you pick the array storage method! yay!

* JSON data is not a tree

My ideal mapping from libjson and libyaml would be:

* unambiguous: you can reconstruct a canonical version of the input
  stream from the parse data, as much as possible (JSON is better at this)

* native: you can iterate over JSON arrays as Lisp lists, and JSON
  key-value mappings as alists.  JSON's `false' and `null' are both
  false in Lisp boolean context.

* clean: no extra cons cells for attributes

* readable: this is huge IMO, to be able to pretty-print the data and
  quickly see what it contains... one of the things I like about JSON
  vs. SGML/XML.

The ideal thing may be a "libjson/libyaml native" data format that can
then be bidirectionally mapped to the DOM you suggest...

Ted