* chromatic <[EMAIL PROTECTED]> [2008-08-20T13:59:14]
> Aren't these two separate concerns, human versus machine readability? The
> latter rarely respects ambiguity.
Yes.
Right now, there seem to be two pro-YAML arguments.
(1) It's easier to for humans read.
Sure. I will admit that. It is easier for humans to read in probably every
likely case but one. It's harder for machines to read, though, so that cost
has to be weighed.
Also, given how few languages have reliable, conformant YAML emitters, I
imagine that it will often be easier to use a JSON emitter. Even if your
language has a YAML emitter, the JSON library will probably be in heavier use,
you're more likely to be familiar with it, etc. I admit that this is not a
strong argument, but I think it's pretty likely to be the case for a good long
time yet. (Even Perl doesn't have much by way of YAML libraries.) The one
case in which YAML is definitely not easier to read than JSON is when it is
formatted in the subset of YAML that is JSON.
So, how often, in non-Perl TAP emitters, will you see pretty YAML instead of
JSONic YAML? I predict: plenty.
So, yes, languages that can emit pretty YAML can do so, to make the protocol
stream easier for humans to read. That will, of course, limit the number of
consumers than can parse it.
So: how often is YAML going to realistically give this benefit outside of
Test::Builder and TAP::Harness?
(2) YAML is better suited for complex serialization than JSON.
This is pretty clearly just true. The ability to tag structures as
representing data more complex than YAML's native kinds allow, or just has
having greater significance than some raw data, is really great.
Your language won't need (say) pickle if it has YAML and a schema for mapping
complex native types to YAML. Many languages have their own serialization
system, though; how many will implement another one that stores in YAML,
especially in languages (like Perl) where YAML support for making use of tags
is paltry, at best.
It would be almost as easy, if not as easy or easier, to instead make your
language serialize to JSON. After all, these two things could easily mean the
same thing:
---
account: !yourcorp.biz!account 1234
..or...
{
"datatype": "yourcorp.biz/account",
"payload" : 1234
}
So, definitely it is cool that there is a build in way of saying "datatype" and
"payload" in YAML, and I'm glad it's so compact. How often will people be able
to reap this benefit if YAML is chosen over JSON?
I am really, really worried by statements like "we'll just keep pushing on YAML
implementors to get it implemented more places and better so that we can rely
on it for TAP."
--
rjbs
