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.

Answer 1

JSON is the native encoding for javascript. It should be much faster and easier to work with.

Answer 2

JSON is easy and faster to parse. XML is a little more difficult to parse, and is slower to parse and transfer (in most cases).

Since you're using jQuery, I suggest using JSON: jQuery can retreive JSON data and convert it into a Javascript object automatically. In fact, you can convert JSON data into a Javascript object using eval. XML would have to be transversed manually by you (I don't know how this works in Javascript, but it's difficult/more annoying in most languages I've used XML libraries with).

Answer 3

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.

Answer 4

I use JSON for any kind of configuration, data interchange or messaging. I use XML only if I have to for other reasons or to semantically mark up document-like data.

Answer 5

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() 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, on the client-side.

• 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

Answer 6

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.

Answer 7

I'd choose XML over JSON if I need to validate the chunk of incoming data, because XML nativly supports this through XSD.

Answer 8

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

Answer 9

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.

Answer 10

JSON is always preferable in terms of the processing the client browser has to do for parsing the data. Also, JSON is light weight data exchange format.

XML parsing always consumes lot of browser resources and should be avoided as much as we can unless otherwise required.

Answer 11

Both XML and JSON are supported by Microsoft. XML literals were the new cool feature in VB 9. In the upcoming version of ASP.NET 4.0 JSON is a must to leverage the power of client side templating.

From the question you have asked it seems JSON might be the choice for you as it is easy to process on client side with or without jQuery.

Answer 12

from JSON - the last feet

When you go down the JSON route, you run into the same issues that XML faced 10 years ago:

Mixing data from two different sources into one JSON packet can cause element labels to bump into each other. Mix up a packing slip and an invoice, and suddenly the From address may mean something quite different. That’s why XML has namespaces.

Converting between different JSON structures would require writing mundane code. A more declarative way to map data would make the job easier. That’s why XML has XSLT.

Describing a JSON packet’s structure—its fields, data types, etc.—is necessary in order for people to hook into your services. It’s essential to have a metadata language for this. That’s why XML has Schemas.

Carrying on two simultaneous client-server conversations takes care. If you ask the server two questions and get one answer back, how do you know what question it answers? That’s why XML has WS-Correlation.

Answer 13

I have a blog post on the subject detailing the history of web protocols (i.e. SOAP, XML, JSON, REST, POX, etc) providing a summary as well as some advantages and disadvantages of each: http://www.servicestack.net/mythz_blog/?p=154

I actually think you can draw many similarities between XML and JSON by comparing the differences between dynamic (JSON) and static (XML) languages.

Basically XML is a stricter, more rigid serialization format that can be optionally be verified with an accompanying schema (which is either an XSD or DTD). XSD's are quite elaborate and allows you to describe many different types e.g. Dates, Times, Enumerations, User Defined Types and even Type inheritance, etc. SOAP effectively builds on top of the XML feature-set providing a standardized way to describe your web services (e.g. types and operations) through a WSDL. The verbosity and complexity of the WSDL spec means that it can be more tedious to develop with but at the same time there is a lot more tooling available to you and most modern languages provide automated tools to generate your client proxies taking some some of the burden off when trying to interoperate with external services. (Although at the same time I find generated proxies a burden themselves when dealing with frequently changing web services).

I would still recommend using XML for your web services if you have a well defined 'enterprise service' that is not subject to frequent change or your web service needs to be accessed from many different languages.

For all its benefits XML comes with downsides as well. It relies on namespaces in order to provide a typed extensible format and enables you to specify attributes and elements within the same document. Having different namespaces within the one document means a lot of the time when using a Xml Parser to extract data, you will also need to provide the namespace of each element you want to retrieve/traverse. It also extrapolates the payload making it more verbose than it needs to be. Having the option to output attributes as well as elements means your classes do not map nicely to an XML document. These features alone make it a poor programmatic fit for most languages making it more tedious and cumbersome to work with. Microsoft has recognized and simplified this somewhat with in their DataContract serializer by doing away with XML attributes and just having the properties of your class map to Xml elements only.

JSON on the other hand is the complete opposite to XML in many ways as it is very loosely-typed and only has simple support for basic types: Number, Bool, string, Objects and Arrays. Everything else essentially has to fit in a string. This is not great when trying to communicate across language boundaries as you will need to adhere to some out-of-band non-standard specification if you want to support more specific types. On the upside its limited feature-set makes a good programmatic fit to most languages - and is perfectly suited for JavaScript as a JSON string can be eval'ed directly into JavaScript object.

Size and Performance

I have some northwind database benchmarks available comparing the size and speed between Microsofts XML and JSON implementations. Basically XML is more than 2x the size of JSON but at the same time it looks as if Microsoft put in a lot of effort in optimizing their XML DataContractSerializer as it is more than 30% faster than their JSON one. It seems that you have to make trade-off between size and peformance. Not happy with this fact, I decided to write my own fast JsonSerializer which is now 2.6x faster then MS's XML one - so best of both worlds :).