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.
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.
At Yell we're currently working on our first public API, and only on Friday did we have the conversation and decided that doing JSON well was far more important than supporting XML at all.
The decision was a quick one, we just asked the iPhone, Android and web devs where we should focus, what they wanted most. The answer was unanimously JSON.
Direct mapping to most (dynamic) programming languages' datatypes, such as arrays, dictionaries, numbers and strings.
Once you get used to working with a combination like JSON and Python, you really don't want to go back to the complexity and inconvenience of parsing and generating XML.
But still, deprecating XML means lots of already functional apps won't work anymore. Maybe a "All new app registered after X date will only be able to use JSON formatted data" would be better.
XML is actually very hairy and complicated. Consider entity encoding, whitespace (as in xml:space="preserve"), and namespaces. In contrast, the complete syntax of JSON is given in 5 simple flowcharts: http://json.org/
Nearly any competent programmer could hand-roll a tested, production-ready JSON parser in under a week. Try doing the same with XML. In practice there are plenty of JSON parsers out there to choose from, but being able to completely wrap your head around something is useful.
I upvoted your comment for the info, but I have no idea why this is an advantage for anyone except the handful of people who create an implementation. Hand-rolling an XML parser is a pretty sure sign of a certain kind of incompetence. Wouldn't the same be true of hand-rolling a JSON parser, unless you're one of the (rare) first guys to solve the problem for your language or language platform? To put it another way, wouldn't this only have been an advantage before XML libraries became commonplace? The last time I reached for an XML library and found there was none already installed with my platform, I was using Tcl (and it wasn't hard to find TclXML.)
Benefits JSON > XML: Less bandwidth for same data, Quick to load, quick to parse. Very web friendly.
Benefits of XML > JSON: Easy to validate structure and content (via schemas), and transform content in a language neutral manner (via xslt). Older, thus supported in more places.
Use what works - JSON is fine for web stuff, XML is better for things that need strict validation and/or long term data storage.
We've been using this pretty extensively at work. The Java guys wrote something to generate their model from it and on the JavaScript side we've used it to do all kinds of nice things like automagically generating forms that validate according to the schema and verifying that the data we receive from the backend conforms to it in our tests.
From what I can gather very few people are using it. It's not exactly fun to write but a co-worker of mine wrote a dsl to make that less painful.
Of course when you write JavaScript, it's a joy to work with.
On the transformation side there are a few ideas floating, notably JSON-T
I never really got the 'why' behind XML Schemas. Why would you validate a document with a schema vs actual code? It's just a bigger pain in the ass, and more limited.
On XML vs. JSON, I used to hate XML until I started programming in ActionScript which has a really nice syntax for it (except a few oddities here and there). I use Enunciate at work ( http://enunciate.codehaus.org/ ) which generates XML, JSON, AMF, SOAP/REST endpoints all by itself from base Java services and classes, which works well too.
Can't say I'm disappointed, back when I did twitter dev I used JSON for everything, plus it was really easy to interface with our JavaScript client (duh).
I haven't used Action script but Scala has really nice support for Xml - it is properly the only language that allows you to do pattern matching on XML.
Readit News
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.
It's a real shame that the native JSON object, and the spec missed out these useful features...
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.
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.
Deleted Comment
But if you are working in Javascript, then yeah it is properly easier.
What's next? HTML? {"head":{"title": "JOHN"},"body:"{"div": "Javascript Object Hypertext Notation"}}
The decision was a quick one, we just asked the iPhone, Android and web devs where we should focus, what they wanted most. The answer was unanimously JSON.
Once you get used to working with a combination like JSON and Python, you really don't want to go back to the complexity and inconvenience of parsing and generating XML.
Nearly any competent programmer could hand-roll a tested, production-ready JSON parser in under a week. Try doing the same with XML. In practice there are plenty of JSON parsers out there to choose from, but being able to completely wrap your head around something is useful.
Benefits of XML > JSON: Easy to validate structure and content (via schemas), and transform content in a language neutral manner (via xslt). Older, thus supported in more places.
Use what works - JSON is fine for web stuff, XML is better for things that need strict validation and/or long term data storage.
http://json-schema.org/
http://tools.ietf.org/html/draft-zyp-json-schema-02
We've been using this pretty extensively at work. The Java guys wrote something to generate their model from it and on the JavaScript side we've used it to do all kinds of nice things like automagically generating forms that validate according to the schema and verifying that the data we receive from the backend conforms to it in our tests.
From what I can gather very few people are using it. It's not exactly fun to write but a co-worker of mine wrote a dsl to make that less painful.
Of course when you write JavaScript, it's a joy to work with.
On the transformation side there are a few ideas floating, notably JSON-T
http://goessner.net/articles/jsont/
Neither of these things are as mature as XSD and XSLT, but if you love JSON and JavaScript, they're definitely worth investigating.
Deleted Comment
I just implemented my project's API in XML. Time to switch I guess...
Can't say I'm disappointed, back when I did twitter dev I used JSON for everything, plus it was really easy to interface with our JavaScript client (duh).
http://www.codecommit.com/blog/scala/working-with-scalas-xml...