Wednesday, September 9th, 2009

Getting hyper about JSON namespacing

Category: JSON

<p>Kris Zyp, JSON hero, has been cooking up some more good stuff on his path to reinventing a new path to all.

In JSON namespacing he discusses JSON Hyper Schema which aims to cure JSON from XML namespacing colon cancer.

JSON Hyper Schemas can be referenced from instances by Link headers or media type parameters. A simple example illustrates how JSON properties have universally locatable definitions:

javascript
< view plain text >
  1. Content-Type: application/json; schema=http://www.book-warehouse.com/book-schema
  2. [
  3.   {"title": "Oliver Twist", "price": 16.99},
  4.   {"title": "Robinson Crusoe", "price": 15.99}
  5. ]

This message gives the authoritative URI for the schema. With a look at the schema, we can see how each property has a corresponding definition with an authoritative URI as well:

javascript
< view plain text >
  1. Content-Type: application/schema+json; schema=http://json-schema.org/hyper-schema
  2. {
  3.   "properties": {
  4.      "title": {"type": "string", "description": "The title of the book"},
  5.      "price": {"type": "number", "description": "The price of the book in US"},
  6.   }
  7. }

JSON Hyper Schema is a sufficient building block upon which we can realize the goals of namespacing, namely, meanings from distributed parties can be authoritatively ascribed to elements of a data structure with property name sharing and conflict resolution control. What is elegant about this approach is that basically nothing needs to be modified in the actual instance data structures themselves. URI attribution is done through media type parameters in combination with schemas. The actual data stays unchanged, it is still the original simple, easy to read, compact JSON. JSON namespacing not only fits with JSON technically, but it fits in spirit: data is simple and light.

Related Content:

Posted by Dion Almaer at 6:42 am
9 Comments

++++-
4 rating from 21 votes

9 Comments »

Comments feed TrackBack URI

OK, what about mixed-namespace documents, of what all the namespacing hype in XML is about?

Comment by Aadaam — September 9, 2009

@Aadaam: That’s the main topic of the article.

Comment by kriszyp — September 9, 2009

I’m with Aadaam. I must be missing something, but does this allow for a single json object to use properties from multiple namespaces? How would you have a “title” attribute from namespaces “a” and “b” on the same object. In xml this would just be

<book a:title=”Oliver Twist” b:title=”Other title”/>

Obviously a contrived example, but you get my point.

Comment by genericallyloud — September 9, 2009

@genericallyloud: You map the title property to another property name with the schema (explained under “Collisions (how to really avoid them)” section).

Comment by kriszyp — September 9, 2009

My gut reaction to that approach to collision avoidance is that it’s too complex (although I totally groove on the idea of schemas for JSON in general). I totally get where you’re going Kris, and it makes sense, it just seems like to much of XML in JSON, in terms of definitional (if you’ll let me invent a word!) complexity.

I do have an alternate idea to offer…

What if you did something like this:

Content-Type: application/json; schema=ns1:http://www.book-warehouse.com/book-schema,ns2:http://www.mybokos.com/book-schema
{
“books” : [
{ "ns1.title" : "Oliver Twist", "ns2.title" : "Oli_Twi",
"ns1.price" : 16.99
},
{ "ns2.title" : "Robinson Crusoe", "ns2.title" : "Tob_Cru",
"ns1.price" : 15.99
}
]
}

That would allow for multiple schemas to be specified, each identified by a namespace identifier. When this JSON is used to reconstitute the object it defined, you would have to do…

alert(o.books[0]["ns2.title"]);

…to access its data and still maintain namespace awareness, so you lose the pure dot notation approach. Not ideal, but I could live with that I think.

You might not have to give that up though… I could certainly envision a JSON processor that took in the JSON and created an object from it where the structure would wind up being:

{
“books” : [
{
"ns1" : { "title" : "Oliver Twist", "price" : 16.99 },
"ns2" : { "title" : "Oli_Twi" }
},
{ "ns1" : { "title" : "Robinson Crusoe", "price" : 15.99 },
"ns2" : { "title" : "Rob_Cru" }
}
]
}

The processor, being namespace-aware, could create the namespaces within the object on the fly, and put the data in the appropriate place. Developers would have a choice between speed (no processing, but have to use bracket notation) or a more robust data structure (processing to give the namespace-based structure).

What do you think? Am I nuts? (err, don’t answer that! LOL)

Comment by fzammetti — September 9, 2009

RDFa annotated JSON Webservices as a foundation for the Semantic Web.

Comment by BonoboBoner — September 10, 2009

Might just stick with xml, oh wait.. is that ‘XML SUCKS’ trend still going? ah well, think I’ll stick to being productive anyway.

Comment by meandmycode — September 10, 2009

@fzammetti: You are certainly correct that in certain cases, XML-style namespacing is simpler than schema-based property name remapping. However, a key point is that the complexity is pay-per-use. The vast majority of use cases (single namespace, multiple namespace without any collisions, and multiple namespaces where collisions share meaning) are much simpler with schema-based namespacing, since the document doesn’t require any namespace prefix resolution, it can be interpreted as a plain JSON document, and the client can assert understanding by simply matching on recognized schemas. This is far simpler and less obtrusive than any strategy that forces changes to the actual data documents. Increased complexity is only necessary in rare edge cases (even though it is really easy to theorize about those edge cases), and remains unobtrusive.

Comment by kriszyp — September 10, 2009

Leave a comment

You must be logged in to post a comment.