An Introduction to JavaScript Object Notation (JSON) / Page 3 | WebReference

An Introduction to JavaScript Object Notation (JSON) / Page 3


An Introduction to JavaScript Object Notation (JSON) [con't]

Translating Between XML and JSON

The emergence of AJAX is causing many developers to rethink the ways in which they create Web applications. Since many Ajax developers prefer handling data directly using JSON in browser-side JavaScript code, it will become increasingly necessary for middleware server programs to provide application data to the browsers in JSON format instead of the XML format. This means that developers need to convert data encoded in XML to JSON before sending it to the browser. There are currently many initiatives going on right now to do just that.

A particularly interesting one is the xml2json.xslt project, which is working on a XSLT 1.0 stylesheet to transform XML to JSON. On the downloads tab there's a zip archive which contains some test files. I think that you'll be quite impressed with the results.

The more common approach is to use a server-side scripting language such as PHP, C#, ASP, JSP, or Perl to intercept the XML-formatted data and convert it to JSON for the browser to parse. This offers the flexibility of being able to parse a textstream and dynamically convert the data format on the fly. Here's an example of an embedded C# subroutine that would execute on the server. It opens an XML document and calls a C# routine to apply the conversion to the XML. Again, JavaScript on the page could simply use the eval() function and access the data without any further massaging. The final line in the example is creating the client-side script. The JSON text is passed to the function as an argument:

Bi-directional Conversion

Bi-directional conversion is also a hot topic these days, as Web architects race to develop the mechanism that will be adopted as the standard. Converting back and forth between JSON and XML isn't trivial because the XML documents have to be converted to a JSON representation that preserves structure, order and the data.

The preservation of the document structure is achieved by outlining a set of rules to describe how each XML element will be translated into XML. The following table demonstrates some potential conversion patterns between XML and JSON.

Pattern XML JSON
1 <e/> "e": null
2 <e>text</e> "e": "text"
3 <e name="value" /> "e":{"@name": "value"}
4 <e name="value">text</e> "e": { "@name": "value", "#text": "text" }
5 <e> <a>text</a> <b>text</b> </e> "e": { "a": "text", "b": "text" }
6 <e> <a>text</a> <a>text</a> </e> "e": { "a": ["text", "text"] }
7 <e> text <a>text</a> </e> "e": { "#text": "text", "a": "text" }

Preserving the XML order is equally tricky. Consider the following XML element:

Using the above rules would result in the invalid JSON object syntax below:

The JSON is incorrect because you cannot have an associative array with the same key. Altering the JSON code to achieve a semantically equivalent JSON structure is not prohibitively difficult, but it can lead to irreversible output!

Data types are a particularly easy attribute to lose in conversion. Since there's no way to differentiate between different numeric types, a variable which might start as an integer could come back as an unknown numeric type. Therefore, unless the data types are contained in the XML itself, there could be a danger of trying to fit a value into a smaller type.


JSON has emerged as a promising alternative to the XML data-interchange format. In addition to being lightweight, its syntax also closely resembles OOP programming languages such as C++ and Java. Moreover, as a subset of JavaScript, parsing JSON-formatted data is simplified. Nonetheless, at this early developmental stage, the JSON format still has a lot of growing to do. Better date handling, the inclusion of data type definitions, and the development of greater overall standardization all need time to come to fruition. Finally, it remains to be seen to what extent JSON will catch on. Ultimately, the choice is up to you whether or not you want to take advantage of this exciting new tool, or wait to see how the story unfolds.


About the Author

Robert Gravelle is a Senior Programmer/Analyst for the Canadian Border Services Agency as well as a freelance IT consultant. Rob specializes in Java, Perl, ASP, Microsoft application automation, JavaScript, VBScript, Web Development and multi-tier systems. Feel free to contact Rob at should you like more information, but note that, although Rob will do his very best to respond in a timely manner, due to the volume of emails received, he cannot guarantee a response to every message.

Digg This Add to