Limitations are good. I find it really easy to read. You can install browser extensions to make it even more readable.

Schema can come from a well written specification.

> Was ditching XML for JSON just due to cosmetic / trending reasons?

No, as said before, it's easy to write / read / generate / parse. No awkward DOM style management if you want to parse out a value. I really hated it with XML.

HTML is fine also for what it was invented for.

Most browsers can display XML readably by default.

> Schema can come from a well written specification.

That doesn't replace a schema though.

> No, as said before, it's easy to write / read / generate / parse. No awkward DOM style management if you want to parse out a value.

"DOM-style management" of XML documents which can be replaced by JSON is equivalent to hand-rolling a JSON parser from the raw bytes. It's not the hardest thing in the world, but it's not exactly easy either.

With most XML applications equivalent to JSON, that part would be tucked away in the relevant library, e.g. the XML-RPC serialisation format is almost isomorphic to JSON[0], and in Python converting between native objects and the XML-RPC serialisation is just `loads` and `dumps`[1] — though you don't usually have to do that at all since the XML-RPC client will handle the serialisation and deserialisation for you automatically — which is more or less what the JSON library provides[2].

And JSON is convenient in dynamically typed languages because it maps more or less directly to their native dynamic structures, that's not quite the case for languages like C++ or Haskell.

[0] null (nil) is an extension but it natively supports binaries and datetimes

[1] https://docs.python.org/3/library/xmlrpc.client.html?highlig...

[2] https://docs.python.org/3/library/json.html?highlight=json#b...

True, but a JSON string is already more readable than XML.

If you open your devtools it's inspectable by default: http://imgur.com/a/eW0Rv

> that's not quite the case for languages like C++ or Haskell.

So handling XML in those languages are easier?

BTW if your server / services feel more native with XML serialization / parsing to native data structures use that. Picking JSON just because everybody else does it is not a good idea.

However if you make a public web API consumed mostly by browsers (JS), then yeah, pick JSON and REST.

That also works for XML documents: http://i.imgur.com/NmcWdaO.png

> So handling XML in those languages are easier?

Both are "crap" since they're dynamic information which has to be brought into a statically typed world. However depending on the schema it might be possible to automatically generate the binding and hide the dynamic resolution.

> BTW if your server / services feel more native with XML serialization / parsing to native data structures use that. Picking JSON just because everybody else does it is not a good idea.

> However if you make a public web API consumed mostly by browsers (JS), then yeah, pick JSON and REST.

Agreed.

And everyone uses a web browser.

Ergo, if you develop an HTTP API, you should do it with JSON so it can work easily in web browsers.

Browsers had native XMLHttp support before they had JSON support.

The fact JSON (use to be) a subset of JavaScript and the browser runs JavaScript natively is not convincing.

Other than evil eval(jsonString) (before JSON.parse was available) which is basically asking for XSS, what benefit you get from JSON being consumable by JavaScript?

I think XMLHttp was available in browsers (in a vendor specific annoying way perhaps but still available) way before JSON.parse was available... am I missing something?

eval() was present from day 1 and is the reason JSON looks like it does. Obviously it requires complete trust in the source (historically, the same origin).