Re: YAML Was: CommitFest status/management

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> YAML and JSON are pretty much interchangeable for our purposes.
> According to Wikipedia, "Both functionally and syntactically, JSON is
> effectively a subset of YAML." See
> <http://en.wikipedia.org/wiki/JSON#YAML> So the YAML parsers should be
> able to handle the JSON output. The only thing we'd be buying with this
> patch is making a bit happier some people who prefer reading the YAML
> syntax. For machine readability we'd be gaining precisely nothing.

Hmm. So the argument for it is "let's make a machine-readable format
more human-readable"? I'm not getting the point. People should look
at the regular text output.

> One consideration is this: the more formats we support the dumber the
> output will be. Already the XML output is arguably dumber than it should
> be, because XML elements are two-dimensional (they can have property
> lists (attributes) and child elements) but JSON/YAML nodes are
> one-dimensional, so we have made some things that one might normally
> expect to be attributes in XML into child elements. While adding YAML
> won't impose any additional burden of that kind, because its semantics
> are so close to those of JSON, other output formats well might.

I tend to look at it the other way around: having to support output
formats that have significantly different data models is a Good Thing
because it forces you to design sufficiently general code mechanisms.
If YAML had yet another data model it might actually be a useful
exercise to get the code to handle that. However, if it's not teaching
us anything we didn't learn from JSON, there's no gain from that
viewpoint either.

regards, tom lane