Susan Potter

Software Development Blog (formerly called 'Snakes, Gems & Coffee') A technical blog with articles on a number of topics from Erlang, Ruby idioms, Javascript, semantic web, Rails tips, graph databases, distributed systems.

Why JSON Pointer falls short (and why XPath for JSON would be great)

%h3 Overview %p My Twitter timeline this morning went crazy with references to the %a{:href => ""} JSON Pointer draft proposal or specification (and the %a{:href => ""} Erlang JSON Pointer implementation on GitHub by janl). I was all excited for all of two minutes as I read the couple of non-boilerplate paragraphs in the JSON Pointer spec draft. %p The problem is that it doesn't appear to return all matching nodes in the JSON document representation tree for a given "pointer". Let us look at a few examples. %h3 JSON Pointer Examples %p Let us pretend that we have this JSON document: %p Now let us say we want all the names of actors from this movie (OK, it is a spoof trailer, but I might watch it if they did make it). We would need to access each one by index like so: %ul %li %code /actors/1/name %li %code /actors/2/name %li %code /actors/3/name %li %code /actors/4/name %li %code /actors/5/name %p This is really very inelegant and verbose (not to mention pretty inefficient) to use JSON Pointers to look these names up one by one. %p Now let us suppose that instead of the JSON document only holding the details of one movie, it contains a list of movies in a category. Now when we do /actors/X/name (where X is a valid index for the first movie in the list) we retrieve the Xth actor name for the first movie (as per the spec draft linked to earlier). How droll! %h3 Enter XPath %p I know it isn't fashionable to like anything XML related any more, but there are some things that XML brought that are quite useful. One is (IMHO) XPath. %p I first came across XPath 7-8 years ago when building a canonical OO model of a broad set of financial products spanning many asset classes that would represent (eventually) every financial product of varying complexity using the same fundamental modeling building blocks (not a small feat - and not sure it ever realized its full objective, but anyhoo...). (A subset of) XPath was being use to query the rich object model (often represented as XML at the periphery of the system i.e. at integration endpoints). This may have been one of the bigger successes of the project. XPath demonstrated its value by the following characteristics: %ul %li being flexible: it is able to describe a number of "paths" of data representation. %li being descriptive: most people can read an XPath and most of the time understand what data it will access. %li being representation agnostic: allowing clients to use XPath on either a fully realized object representation or an unparsed XML document (the runtime could be lazy when it made sense to be) %p You might be wondering how XPath is flexible? Well despite my appreciation of the JSON Pointer draft spec being pretty short to read, the XPath spec describes ways to start matching in mid path (by adding an extra '/' as prefix), to select the parent of a matching node (by appending '..' to XPath), to select attributes (by prepending '@' to attribute name in the XPath - ok, not so useful, perhaps in a JSON document) as well as the ability to use a number of predicates (e.g. last(), position(), index numbers, >, <). However, the key differentiator of XPath over JSON Pointer isn't all these extra path describing features, it is that it returns a result set of all elements (or values) that match the given selector. %p Let us look at what would be returned using the JSON document of the movie above with the following XPaths: %ul %li %code //actors/name => ["Scala Johansson", "William Windows", ..., "Lenny Linux"] %li %code title => ["Java 4-ever"] %li %code //actors/character => ["A", "B", "C", "D", "C (Young)"] %li %code //actors[2]/character => ["C"] %p As we can see this provides a lot of flexibility. Now if we had a JSON document that contained movie documents like this under a subtree then the above XPaths would still select what we want. %p The above examples only touched the surface of XPath, but I think it already demonstrated how much more flexible it would be applied to JSON documents. %h3 Great, but what is the point, Susan? %p Not sure I can really say there is a lot of point to this post other than griping and moaning about the lack of a good selector language for JSON documents currently. However, if anyone else feels that an XPath subset that is relevant to applying to JSON documents and would like to work with me to distill such a useable subset into a draft/proposal (or whatever), then %a{:href => "/contact"} contact me so we can get the ball rolling. Even HTML has a decent way to select elements ("values") in the DOM to be able to apply styles or behavio(u)r.