Skip to toolbar

Community & Business Groups

Misconception: JSON is easier than XML

Another misconception about Widgets revolves around the choice to use XML over the now in vogue JSON format.

Proponents of JSON argue that XML is too complicated for developers and for implementers, while other more conspiratorial individuals claim that there is a “W3C strategy tax” at work. Proponents of this misconception ignore the fact that JSON can also easily be abused to make overly complicated data structures (see British museum’s near criminal use of JSON), and has a lot of restrictions that mirror XML’s complexity in many ways (e.g., JSON also needs to be “well-formed” and valid, some characters are reserved, only certain data types can be used, etc.).

Having said that, I personally can agree that XML, when used badly (e.g., RDF/OWL, XML Schema, XACML) can overwhelm authors to the point of wanting to rip one’s eyes out. But, the use of XML in Widgets has never been proven to be an issue for Widget developers. This is because the Working Group was well aware of authoring issues with XML authoring and so the configuration document was designed to be as simple as possible to author: the document format is mostly flat in structure, taking away most authoring complexity found in XML. In other words, we knew “the tools won’t save us”: so we designed everything assuming it would be written by hand.

Further, to make Widget’s use of XML as developer-friendly as possible, the Widget packaging specification provides a meticulously defined XML processing model, which handles error conditions gracefully, provide sensible defaults and fallback, and only halts processing in the most extreme of cases.

The processing model, which draws heavily from HTML Standard’s processing model, is also designed to be future proof: allowing the format to be easily expanded as needed through either proprietary extensions or through new W3C specifications.

The choice to use XML for W3C Widgets was for legacy reasons: all the Widget runtimes from when we first started the widget standardization effort were using XML.

The logic of the Working Group at the time was that if we used XML, then it would be easier for implementers to adapt their runtime and developer tools to use the XML W3C Widget format, and it would make it easier for existing content to be migrated to the XML W3C Widget format. Furthermore, when we started this effort in 2006, JSON was just appearing on the scene so it was not as popular a format as it is today (5 years on at the time of writing).

So, although we could have chosen to go against the grain in 2006 and used JSON, the parsing and error-handling models needed for either format would have been essentially identical: i.e., there is still little reason to choose one over the other, and choice of XML has helped other groups use the format for their own purposes (e.g., WAC defines a few additions to the format through their own namespace). If the industry moves towards Google’s and Mozilla’s use of a JSON format for packaged client-side Web applications, a new parsing model specifically for JSON will need to be standardized. This is not a big deal; it just needs to be written down by someone (and no one has found time to do that yet).

Regarding the mythical “W3C strategy tax”, certain individuals seem convinced that the W3C’s membership has some evil conspiracy to push XML on the World and seem convinced that W3C widgets are part of that conspiracy. As much as I would love to be part of some evil conspiracy (and get a few kick-backs from this “strategy tax”), there is no such conspiracy to my knowledge (and last I checked, I’m still broke but happy to receive kick-backs;)).

In spite of all this, I’m would still be happy to help standardize a JSON flavour of the widget configuration document format.

Other posts in this series:

Leave a Reply

Your email address will not be published. Required fields are marked *

Before you comment here, note that this forum is moderated and your IP address is sent to Akismet, the plugin we use to mitigate spam comments.