When to prefer JSON over XML?

Question

My requirement is just to display a set of values retrieved from database on a spread. I am using jquery.

Solution 1

Favor XML over JSON when any of these is true:

• You need message validation
• You're using XSLT
• Your messages include a lot of marked-up text
• You need to interoperate with environments that don't support JSON

Favor JSON over XML when all of these are true:

• Messages don't need to be validated, or validating their deserialization is simple
• You're not transforming messages, or transforming their deserialization is simple
• Your messages are mostly data, not marked-up text
• The messaging endpoints have good JSON tools

Solution 2

I use JSON unless I'm required to use XML. It's simpler to understand, and (because it requires less configuration overhead) it's easier to program for reading and writing if the libraries are available in your context, and they're pretty ubiquitous now.

When Amazon first exposed their catalogs as a web service, they offered both JSON and XML. Something like 90% of the implementers chose JSON.

Solution 3

Considering your specific case where you're already doing javascript on the client side, I'd go with JSON for these reasons:

• Since JSON is native to javascript you'd have to write less code on the client side - Just eval() (or, better yet, JSON.parse()) the JSON string and get an object you can use.

• At the same time evaluating JSON on the client-side will be more efficient, and therefore faster.

• JSON serialization produces shorter strings than XML. Using JSON will reduce the amount of data running across the wire and improve performance in that respect.

Here's some further reading: http://www.subbu.org/blog/2006/08/json-vs-xml

Solution 4

Some other things that I have run into in the XML vs JSON relm:

JSON is very good for

• name/value pairs
• nesting those pairs

Which means it tends to like an array or nested array. However JSON is missing both

• attributes
• namespacing

So if you were to combine two or more JSON services there could be potential namespace conflicts. That being said JSON can be used for about 90% of the same things XML can be used for when exchanging data in my experience.

Solution 5

Usually JSON is more compact, and faster to parse.

Prefer XML if:

• You need to process the data on the client, and you can leverage XSL for that. Chances are the XML + XSL chain will work faster than JSON + JavaScript especially for big chunks of data.
  • One good case is to convert the data into an HTML snippet.
• Various legacy cases:
  • There is an existing XML service, and it is a hassle to rewrite it with JSON for some reasons.
  • You have to post this data back as XML after some light processing using user's input.

One important case of (almost) XML: try to detect when sending HTML snippets is more beneficial than sending raw data. AHAH can do wonders in simple applications, yet frequently overlooked. Usually this style assumes that a server sends HTML snippets that will be inlined in the web page without processing.

Usually in AHAH cases CSS is being leveraged to the max to massage snippets visually and implementing simple conditionals like hiding/showing relevant parts of the snippet using user-specific or application-specific settings.

View more solutions

Comments

[Brian Gianforcaro]

JSON is by definition a JavaScript object, jQuery isn't really doing anything special "converting". Just thought It should be clarified.

[dkretz]

JSON is not a javascript object unless it's instantiated in javascript. It happens to follow the format used for serializing javascript objects, but it's accessible (with the proper add-ons and built-ins) from most languages, at least as easily as XML is.

[shoosh]

isn't eval()ing JSON a big no-no?

[strager]

Ah, sorry, didn't catch that.

[perimosocordiae]

"I use JSON unless I'm required to use XML." ~ Exactly.

[Ankur Gupta]

Taken from json.org: The eval function is very fast. However, it can compile and execute any JavaScript program, so there can be security issues. The use of eval is indicated when the source is trusted and competent. It is much safer to use a JSON parser

[13ren]

So the deeper question is "For what reasons would you be required to use XML?" Are those reasons idiotic; or do they just reflect different concerns, from a different point of view from yours?

[dkretz]

Several possible reasons, including existing software I don't want to rewrite. But the most important is using XML as a data interchange format where I don't control both ends, or there is a formal standard that applies and requires XML. I can only choose arbitrarily when I'm the only developer involved.

[vtd-xml-author]

Another issue of Json is that you can not merge two json messages easily to create a new json message. It usually won't be wellformed..

[Robert Rossney]

JSON doesn't offer any advantage over XML in handling marked-up text. But I see your point; that's maybe overstated.

[foo]

What would you need attributes for? If your element contains other values, make it an object - the members are your "attributes". Frankly, I think the bifurcal attributes/container structure of XML entirely detrimental.

[foo]

Namespaces are just another workaround; you can do the very same in JSON if you want to. The WS-Correlation too was added as an afterthought to XML and isn't "built-in". You may as well add it to JSON, too. Structure description (Schemas) is not special to XML; you can do that in a number of ways to any formal language since the invention of eBNF. XSLT is a valid selling point, though.

[Havvy]

Prefer JSON.parse() to eval().

[Roger Barreto]

When all the conditions are equal, favor JSON for two reasons: JSON is a lot lighter to parse than XML (CPU friendly) and requires lot less data to be transfered (Network friendly).

[Admin]

Your answer doesn't bring any new information... But I guess it's still true

[Lawrence Dol]

This answer and the excerpts provided completely misrepresent the tenor of the cited article, which strongly favors JSON. The quotes are of a third party with whom the author of the article disagrees. The cited article is a very good read - so no downvote on this answer, despite the misrepresentation.

[Spencer]

When would you be using XSLT and not be using XML? XML is a given if you're already using XSLT. That shouldn't be supporting the argument to use XML. It's like saying use JSON if you're using JSON.parse(). Also, I would argue that it is easier to transform a JSON object than it is to write an XSLT transform, but that might be my personal bias.

[brian]

I'd argue that JSON not having attributes is a feature.

[sotn]

I don't fully agree with the validation part in JSON. JSON is also validatable. Check this IETF draft: link It's a draft but still..

[Dmytro Melnychuk]

@sotn You haven't PL/SQL for JSON as have XML (e.g. XQuery). It's base for some NoSQL DB (eXist, MarkLogic Server, EMC Documentum xDB, BaseX, Zorba)