On Fri, Dec 18, 2009 at 7:05 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> One problem is that there is not a single well-defined mapping between
>> these types. I would say generally that XML and YAML both have more
>> types of constructs than JSON. The obvious ways of translating an
>> arbitrary XML document to JSON are likely not to be what people want
>> in particular cases.
> Right. XML semantics are richer, as I pointed out when we were discussing
> the various EXPLAIN formats.
You say "richer"; I say "harder to map onto data structures". But we
can agree to disagree on this one... I'm sure there are good tools out
there. :-)
>> I think the performance argument is compelling, too, but we can't even
>> try benchmarking it unless we can define what we're even talking
>> about.
>
> Yes, there is indeed reason to think that JSON processing, especially
> parsing, will be more efficient, and I suspect we can provide ways of
> accessing the data that are lots faster than XPath. JSON is designed to be
> lightweight, XML is not.
>
> Mind you, the XML processing is not too bad - I have been working much of
> the last few months on a large custom billing system which produces XML
> output to create paper/online invoices from, and the XML construction is one
> of the fastest parts of the whole system.
That doesn't surprise me very much. If there's a problem with
operations on XML, I think it tends to be more on the parsing side
than the generation side. But even there I agree it's not terrible.
The main reason I like JSON is for the simpler semantics - there's
exactly one way to serialize and deserialize a data structure, and
everyone agrees on what it is so the error cases are all handled by
the parser itself, rather than left to the application programmer.
...Robert
