While there has been plenty of debate on the whole XML vs JSON argument, I’d like to express a sincere IMHO towards just using JSON whenever possible. It has several real life key advantages that I take advantage of on practically daily basis. XML has its place and is leaps and bounds better than CSV or, god forbid, fixed with column files, but JSON often times is a more practical solution and here’s why:

JSON Describes Objects:

XML can do this as well, but consider the following case:

<movies>
    <movie>
        <title>Austin Powers: International Man of Mystery</title>
        <actors>
            <actor>Mike Myers</actor>
            <actor>Elizabeth Hurley</actor>
        </actors>
    </movie>
</movies>

While this structure seems fairly self-explanatory, let’s consider the following: Does the object “movie” have a property called <title> which is a string, or does it have an array of strings of type <title>? Looking at the XML we can certainly infer that the <title> node is only present once in each movie, but the XML parser would not know that and you would have to hint to it that <title> is a property while <actor> is an array.

The problem can be solved if we make <title> into an attribute of <movie>: <movie title=”Titanic”>. However, the same cannot be done for <actors> as it is an array and attributes cannot be arrays.

Consider the JSON version:

{ "movies": [
                {
                     "title": "Austin Powers: International Man of Mystery",
                     "actors": [ "Mike Myers", "Elizabeth Hurley" ]
                }
            ]
}

The structure here is also apparent to us, but the ambiguity is removed: “title” is a string and “actors” is an array of strings.

JSON Takes Less Code to Manipulate

In a JavaScript/LAMP environment JSON takes a lot less code to get from interpreting the data structures to actually using the data. Because of some built in ambiguity of XML, you generally need to instantiate some XML object native to your environment, and then extract the data out of it. For example PHP includes 14 different frameworks for dealing with XML. Typical PHP code that you would have to write to encode XML of our “movies” data structure looks like this:

$xml = new SimpleXMLElement('<movies></movies>');

$movie = $xml->addChild('movie');
$movie->addChild('title', $movie['title']);
$actors = $movie->addChild('actors');
foreach($movie['actors'] as $actor) {
    $actor = $actors->addChild('actor', $actor);

echo $xml->asXML();

This seems pretty straightforward, but is a lot of code to write. Consider this:

json_encode( $movies );

Notice that not only do you have to write less code and make less method calls, but also you are dealing with native PHP structures: in this case arrays. This reduces the amount of time it takes to go from your data to the data exchange format.

On the client side, JavaScript can often have built-in JSON decoder and if it does you still may use JSON parsing libraries. JavaScript’s eval() will also interpret JSON, but it is insecure.

Sometimes You Want XML Anyways

XML still has some key advantages of JSON: it contains type information, it can be transformed using XSL and it is more widely supported. The XSL functionality often is particularly desirable since it can efficiently transform an XML document into any other format, for example HTML. This is the kind of thing that is not easily possible with JSON in a general case because it contains less data about the objects it is encapsulating. In BU Maps, I use JSON as the data exchange format, but transform the data into XML and then into HTML because it is simpler than writing the JavaScript code to create XHTML nodes.