XML is a mistake. There's rarely a practical advantage to a novel XML schema. If you're not using a well known schema (e.g., Atom) then omit XML support.
{ 'a' :
{
'attributes' : { 'href' : 'http://www.google.com/' },
'val' : 'Google Search Engine'
}
}
<a href="http://www.google.com/">Google Search Engine</a>
{
'tag': 'a',
'href': 'http://www.google.com',
'val': 'Google Search Engine'
}
['Peter', 'Paul', 'Mary']
<ul>
<li>Peter</li>
<li>Paul</li>
<li>Mary</li>
</ul>
YAML is just annoying and requires extensive documentation. I still can't figure out why it's popular in the Ruby community as opposed to much clearer Ruby files.
JSON FTW. The only major issue is multiline support, but overall it's a readability win anyhow.
When working with JSON, you must load the whole JSON document before you can start processing it. If the JSON gets big enough, you start having performance / memory issues. One might argue that you can just get more powerful hardware, but that's only half of the equation: you'd solve your problem, but not that of your clients. Are you going to tell every single one of them that they just need to spend more money on hardware?
When working with XML, you can choose to store the whole document in memory, but it's merely convenient, not compulsory. Using a SAX-like parser, you can stream the whole process and get a much smaller memory footprint.
Having never worked with YAML, I don't know whether the same argument applies.
This is more of a personal issue than an actual one, but another problem I have with JSON is that once you support it, people are going to demand you support JSONp - terribly convenient, but a major security hole.
Aside from that, JSON is obviously a great format for small, self-contained responses that can be consumed by both browsers and heavy applications. It just doesn't scale well with large responses.
JSONp is only a security hole for the client, not the API provider. I suppose it puts a bit more pressure on the API provider to not get compromised, though.
Let me amend that to the more qualified "the libraries I've used so far don't allow you to stream JSON". My point is still somewhat valid - most XML libraries I know offer stream-based parsing out of the box, most JSON libraries I know don't - but it's not the show stopper I made it out to be, since it turns out you can, after all, implement your own streamed based parser.
As for JSONp, you're obviously and entirely right. My point was that, in case something happens on the client side (through an entirely different security hole - and let's face it, people who feel comfortable consuming JSONp are likely to take other insecure shortcuts), I'd much rather not be implicated at all than have to prove I had nothing to do with it.
This is not the case; JSON is every bit as amenable to streaming as XML, in my experience. Fewer implementations may support that, of course, but that's not really the fault of JSON. The Jackson parser for Java, for example, has a complete streaming API.
Customers demanding JSONp is not a good reason to not use JSON.
So having dismissed your two points, I think it's safe to say XML does not have any huge advantage over JSON. Certainly minor advantages, though those are of mixed value and often disadvantages.
Actually, having just googled I find a couple, but the only C one I can find (yajl) seems to be mostly abandoned, with a huge number of open issues.