PANVEGA’s Blog

DotNet Development, SharePoint Customizing, Silverlight, MS Infrastructure and other tips and tricks

JSON vs. XML

Posted by PANVEGA on November 10, 2007

JSON and XML are the two programs that have been lovingly adapted to JavaScript to create Rich Internet Applications. JSON  is a data interchange format whose design goals were to be textual, minimal, and a subset of JavaScript, Standard ECMA-262 3rd Edition – December 1999. JSON is a text format that is completely language independent. It supports two structures: objects (unordered collections of name/value pairs) and arrays (ordered sequences of values), as well as four simple types: strings, numbers, booleans, and null. It’s not associated with any kind of data transportation pattern. When your data comes back from the server, it’s already in a JavaScript object format.

There has been a point of controversy over whether JSON or XML is better at dealing with communication between endpoints. For documents, XML is certainly the leader, supporting namespaces and mixed content. But for communications between live programs, JSON with its implicit hash and array support. With XML, on the other hand, it’s assumed that you might want to stream it in by the gigabyte, or load it into one of a many different in-memory data structures, or run a full-text indexer over the contents, or render it for human consumption, or, well, anything. In addition, XML has some glaring advantages what with XPath and XSLT offering powerful ways to sift through XML datasets and transform them to other formats. However JSON is more succint, but not as much as one might think. But because the syntax is simpler, it parses more quickly.

What is the right response format for XMLHttpRequest in Ajax applications? The answer is simple for most markup-oriented applications – use HTML. For data-oriented applications the choice is between XML and JSON.

Here i am going to show you some easy examples; A structure in XML and in JSON format:

This is the XML version.
For example, an address book application might provide a Web service that yields address cards in this XML format:

<?xml version=’1.0′ encoding=’UTF-8′?>
<card>
<fullname>Bala Arjunan</fullname>
<org>PH</org>
<emailaddrs>
<address type=’work’>abcd@xyz.com</address>
<address type=’home’ pref=’1′>me@mailme.com</address>
</emailaddrs>
<telephones>
<tel type=’work’ pref=’1′>+12345678</tel>
<tel type=’mobile’>+1234 1234</tel>
</telephones>
<addresses>
<address type=’work’ format=’B’>1234 Oil Mill St
Chennai, IND</address>
<address type=’home’ format=’B’>5678 Oil Mill St
Chennai, IND</address>
</addresses>
<urls>
<address type=’work’>http://balaarjunan.wordpress.com/</address&gt;
<address type=’home’>http://balaarjunan.wordpress.com/</address&gt;
</urls>
</card>

Here is the JSON strucure:

{
“fullname”: “Bala Arjunan”,
“org”: “PH”,
“emailaddrs”: [
{“type”: “work”, “value”: “abcd@xyz.com”},
{“type”: “home”, “pref”: 1, “value”: “me@mailme.com”}
],
“telephones”: [
{“type”: “work”, “pref”: 1, “value”: “+12345678”},
{“type”: “mobile”, “value”: “+1234 1234”}
],
“addresses”: [
{“type”: “work”, “format”: “us”,
“value”: “1234 Oil Mill St Chennai, IND”},
{“type”: “home”, “format”: “us”,
“value”: “5678 Oil Mill St Chennai, IND”}
],
“urls”: [
{“type”: “work”, “value”: “http://balaarjunan.wordpress.com/&#8221;},
{“type”: “home”, “value”: “http://balaarjunan.wordpress.com/&#8221;}
]

}

Some of the main points raises for why JSON is well-suited as a data-interchance format were:

  • It’s simultaneously human- and machine-readable format;
  • It has support for Unicode, allowing almost any information in any human language to be communicated;
  • The self-documenting format that describes structure and field names as well as specific values;
  • The strict syntax and parsing requirements that allow the necessary parsing algorithms to remain simple, efficient, and consistent;
  • The ability to represent the most general computer science data structures: records, lists and trees.
  • JSON may be something like 100x faster to parse than XML in today’s browsers (but I doubt very much if the best JSON parsers are anywhere near that much faster than the best XML parsers … it would be interesting to know!),
  • JSON parsing ends up with something akin to a  typed “business object” rather than an untyped DOM tree
  • To do that in XML requires yet another layer or two of cruft (a schema and a databinding tool)
  • The bottom line argument for JSON comes down to elegance — it does what is does simply and cleanly, and simply refuses to worry about many of the things that complicate XML such as metadata (attributes), comments, processing instructions, a schema language, and namespaces.

Common arguments against JSON:

  • JSON Doesn’t Have Namespaces.  But every object is a namespace. Its set of keys is independent of all other objects, even exclusive of nesting. Also, JSON uses context to avoid ambiguity, just as programming languages do.
  • JSON Has No Validator. Ultimately, every application is responsible for validating its inputs. This cannot be delegated. A YAML validator could be used however.
  • JSON Is Not Extensible. It doesn’t need to be. JSON is flexible. It can represent any non-recurrent data structure as is.New fields can be added to existing structures without obsoleting existing programs.

The sweet spot for JSON is serializing simple data structures for transfer between programming languages. If you need more complex data structures (maybe with some kind of schema for validation), use XML.

If you want to do full blown RPC use SOAP or XML-RPC. If you just want a light-weight format for moving data around, JSON fits the bill admirably.What do we lose from not using XML? The ability to use XML tools. If you’re someone who breathes XSLT that might be a problem;

Problems with Cross Domain Policies:

Another important point choosing JSON over XML as the output format for a Web service solves is that it works around security features built into modern browsers that prevent web pages from initiating certain classes of communication with web servers on domains other than the one hosting the page. This “problem” is accurately described in the XML.com article Fixing AJAX: XMLHttpRequest Considered Harmful which is excerpted below

But the kind of AJAX examples that you don’t see very often (are there any?) are ones that access third-party web services, such as those from Amazon, Yahoo, Google, and eBay. That’s because all the newest web browsers impose a significant security restriction on the use of XMLHttpRequest. That restriction is that you aren’t allowed to make XMLHttpRequests to any server except the server where your web page came from.

So, if your AJAX application is in the page http://www.yourserver.com/junk.html, then any XMLHttpRequest that comes from that page can only make a request to a web service using the domain http://www.yourserver.com. Too bad — your application is on http://www.yourserver.com, but their web service is on webservices.amazon.com (for Amazon). The XMLHttpRequest will either fail or pop up warnings, depending on the browser you’re using.

On Microsoft’s IE 5 and 6, such requests are possible provided your browser security settings are low enough (though most users will still see a security warning that they have to accept before the request will proceed). On Firefox, Netscape, Safari, and the latest versions of Opera, the requests are denied. On Firefox, Netscape, and other Mozilla browsers, you can get your XMLHttpRequest to work by digitally signing your script, but the digital signature isn’t compatible with IE, Safari, or other web browsers.

The XML chacking answer for this issue:

There is hope, or rather, there are gruesome hacks, that can bring the splendor of seamless cross-browser XMLHttpRequests to your developer palette. The three methods currently in vogue are:

1. Application proxies. Write an application in your favorite programming language that sits on your server, responds to XMLHttpRequests from users, makes the web service call, and sends the data back to users.
2. Apache proxy. Adjust your Apache web server configuration so that XMLHttpRequests can be invisibly re-routed from your server to the target web service domain.
3. Script tag hack with application proxy (doesn’t use XMLHttpRequest at all). Use the HTML script tag to make a request to an application proxy (see #1 above) that returns your data wrapped in JavaScript. This approach is also known as On-Demand JavaScript.

Although the first two approaches work, there are a number of problems with them. The first is that it adds a requirement that the owner of the page also have Web master level access to a Web server and either tweak its configuration settings or be a savvy enough programmer to write an application to proxy requests between a user’s browser and the third part web service.

A second problem is that it significantly increases the cost and scalability impact of the page because the Web page author now has to create a connection to the third party Web service for each user viewing their page instead of the user’s browser making the connection. This can lead to a bottleneck especially if the page becomes popular.

A final problem is that if the third party service requires authentication [via cookies] then there is no way to pass this information through the Web page author’s proxy due to browser security models. The third approach avoids all of these problems without a significant cost to either the Web page author or the provider of the Web service.

Summary:

Why JSON?

Essentially JSON is built for Data Structuring. When you take a look at it, JSON takes care of the Data Architecture of the Ajax based program. It has been widely accepted because it caters to the general need of Ajax. When you take a look at it, Ajax is a very broad program that needs to be harnessed. JSON is very easy to configure and it generally answers the need of every programmer. Compared to XML, JSON is also shorter to configure. In XML you could go as far as 7000 lines and could only go 75% of the data configuration. However, for JSON you can actually reduce it to a mere 1,500 lines. That’s far easier and controllable. Debugging is also easy and as far as any developer is concerned, a thousand lines could even be manually checked.

Why XML?

As we have noted, XML takes the longer route in developing the specific program. The reason for this is that XML is more concerned with the specifics of the program compared to JSON. Besides XML is a general purpose program so you have to configure it for JavaScript. The great thing about this program is that it gives you more freehand expression in your Application. Some see it as XML’s disadvantage but the way I see it, XML’s longer version of coding is a good thing since its full customization. Security is also better because surprisingly, XML is very simple. Because of its long lines it usually requires an expert developer.

So what now?

My personal take in this debate is that XML and JSON has their own claim to fame. Some are suggesting that JSON is the new XML in relation to Ajax. However, Ajax is one of the highly flawed programs when it comes to security. JSON might be able to answer Ajax based programs in some ways however XML could also answer some of the problems in Ajax especially when you’re talking about security and customization.

More references:

http://www.json.org/

http://www.subbu.org/blog/2006/08/json-vs-xml

http://www.techyouruniverse.com/software/json-vs-xml-vs-serialize-for-data

http://weblogs.java.net/blog/robogeek/archive/2008/01/json_versus_xml.html

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: