XML has its uses but honestly when it comes down to it working with JSON is a lot easier. When picking a data interchange format you need to consider indirect advantages as well. JSON is easier to read on a screen, type out, and overall skim. Skimming XML is a pain.
I disagree on readability, a big chunk of deeply nested JSON is not easy to read at all. Most smart XML viewers, including most browsers, have folding and coloring which make it pretty easy to read.
I agree about the smart xml viewers and the fact that most browsers support the friendly treeview's etc... However shouldn't browsers just as easily be able to do the same with JSON? And I believe most JSON viewers I've seen give you the same type of presentation of objects and lists...
If you don't care about the standard, you can use / * * / to comment out stuff in JSON. It's a shame this wasn't in the spec. Along with making quotes optional for keys.
It's a real shame that the native JSON object, and the spec missed out these useful features...
var obj = eval("({foo:3 /*,bar:7*/ })");
Works fine, but JSON.parse and probably most other JSON libs throw a hissy fit for no good reason.
I love JSON, but making quotes compulsory for keys, and missing out comments are both a PITA.
Formats targeted strictly at machine/machine interchange ultimately get used for much more. JSON is no exception.
Configuration tends to be the first place that interchange formats are "abused"; even for such a mild abuse, comments are essential. (Hard-core abuses, like XML-based programming languages, are another thing entirely. :-)
To deal with JSON's lack of comments, I've considered writing services and apps that produce JSON, but consume YAML. Here, the interesting qualities of YAML are (1) it's a superset of JSON, and (2) it supports comments.
YAML isn't a strict superset of JSON, although since YAML 1.2 it is very nearly so; with just a little bit of care you can avoid the edge cases (eg. you can have hash keys longer than 1024 characters in JSON but not in YAML), provided you are cognizant of them.
I had a chef json configuration file which I was creating and testing as I went. In this file I had to remove 3 "recipes" and one "attribute" temporarily.
Because of the lack of comments I copied the old version to a new file etc.
Depends on your language - in Scala XML is so much easier than JSON, mostly because Scala allows you to do pattern-matching and do functional programming on Xml.
But if you are working in Javascript, then yeah it is properly easier.
A little rude, isn't that? There's different fundamental metaphors: XML is a way of representing a tree with labeled nodes, and also a markup format; JSON is the representation of arrays, simple maps, and basic types in unicode. Each has its uses.
Their uses overlap in that they both broadly serve as a language for defining structured data being transfered between two different systems. For most use cases in this space, JSON is a) expressive enough and b) far easier to render, read and parse.
XML has its uses but honestly when it comes down to it working with JSON is a lot easier. When picking a data interchange format you need to consider indirect advantages as well. JSON is easier to read on a screen, type out, and overall skim. Skimming XML is a pain.