W3C

XML, JSON, XSLT and XQuery

The XML work at W3C was rechartered this Summer until 2015, and new work includes adding some JSON support to XSLT and XQuery.

This is still work in progress, so the designs are not final: there are a lot of details to be worked out, not least because JSON and XML have some deep-rooted differences.

The biggest difference is social: JSON is often used in environments where programmers get to decide what format is used for data that their program will use. XML is often used where the same information is shared between many programs, possibly including some unknown programs, and where the data is owned by its creators, who are not necessarily programmers.

A consequence of this difference is that XML tends to be much harder for programmers to deal with than JSON, because it wasn’t primarily designed for them.

But to the point here, JSON parsing and generation can be harder than it looks using XML tools, and we want to make it easy for the XML world to interoperate with JSON APIs and data.

There are two main approaches that make sense when integrating data formats:

  1. Convert the data at the system boundary;
  2. Extend the core to handle both types of data

The current XSLT 3 draft provdes a parse_json() function to turn JSON into a specific internal representation in its existing tree-based data model, and another function to take such a data model instance and turn it into JSON. Then you can use standard XSLT templates, XPath, functions and operators to process the JSON data.

XSLT 3 also adds a dictionary type (often called a “hash”); XSLT calls it a map. The map can be used to work in a more JavaScript/JSON way with key/value pairs. There are no arrays: you use a map with integer keys right now.

XQuery will also add the new map data type, and will probably add arrays. In the database environment where XQuery often lives it’s not so easy to determine the proper relationship between the new data structures and the database, so that’s ongoing.

The upshot will be that XSLT 3 and XQuery 3.1 will have access to JSON data, the ability to generate JSON, and also tools to work with JSON in a query or transformation.

6 thoughts on “XML, JSON, XSLT and XQuery

  1. This is great. I’m glad to see that XML hasn’t been abandoned and that work on it will continue. I have to admit I was a bit worried with all that HTML5 stuff, although I love HTML5, that XML would be forgotten.

  2. I share Mark’s enthusiasm.

    Also, even if XML does not have a prominent spot on the presentation layer, it remains a crucial technology on the database backend and for data interchange. XML and its sister technologies are widely used in enterprise environments, and I think they will still be around for a while.

    Still, other data formats like JSON, BSON, protocol buffers, etc, probably also deserve their fair share in the NoSQL data landscape: they cover different use cases and have complementary readability vs. size in memory vs. value space coverage profiles.

    Several XQuery/XSLT implementations (Saxon, Zorba, MarkLogic, …) already have had map or JSON support for a while, and I think that standardizing this is a move in the right direction.

  3. XSLT is not being widely supported in browsers nor has fidelity proven to be the norm as I discovered when attempting to use XSLT to transform the XML from RSS web feeds into HTML5.

    Worse yet is no apparent support for SMIL which for our purposes of digital signage and connected TV has also been orphaned by browser vendors.

    Having to pay up to $700 for a media player hardware device which supports SMIL is not my idea of success on the part of W3C. I can only wonder why progress has not been made in this context of establishing standards for specific market applications that are best served using transformations and SMIL during this era of client-side processing.

  4. Clinton – thank you for commenting.

    Like you I’d like to see more SMIL support in Web browsers. Writing standards is important but doesn’t by itself cause people to implement or use those standards. W3C is of course doing work in the area of digital signage and if you’re not involved in that area of W3C I’d urge you to consider involvement. Similarly, I’d suggest contacting browser vendors and requsting improved SMIL support. If no-one asks, they won’t do it.

  5. for SMIL I think most likely it will be done via JS libraries these days? it’s a long shot to ask the browser vendors to support them, as it’s a niche market and fairly limited to digital signage only.

Comments are closed.