Microformats and JSON

Today at the office we were chatting about MicroFormats when suddenly the subject of MicroFormats and JSON came up. This struck me as an awesome idea, so I registered MicroJSON.org where I plan to start documenting some approaches to tying MicroFormats and JSON.

Why would these two sit together so well?

JSON has become very popular in the API world, almost all the big web2.0 names are now offering their RSS feeds as JSON feeds as well. It’s a natural progression for the web2.0 AJAX driven world, where mashups are occurring more and more on the client.

A good example is the proliferation of ‘widgets’ that people can add to their blog, MySpace account, or web page. These widgets usually come in the form of a JavaScript include added tip website A that loads a JS file from a website B, which loads data from website C, that is then parsed and displayed on website A. If you’re working with JavaScript as your main parsing and display medium, JSON is by far the best data transfer mechanism as it requires no costly parse overhead - it’s naturally just a JavaScript object.

But why get JSON involved with Microformats?

For all the same reasons that using Microformats in HTML is a good thing, and some more. One of the reasons I like Microformats is because you can standardize a set of data to be formatted in the HTML in such a way that they can be ‘recognized’ by rendering agents and added functionality applied. A prime example is the Tails Export add-on for Firefox which will identify any MicroFormats on a page, highlight them and make them accessible to the user in practical ways.

We’ll get to a point where you could browse pages that contain HCards and add them to your Address book with ease, come across music events and add them as a calendar item to Outlook, eventually adding products listed on e-commerce sites to a local wish list application with the press of a button.

The standardization of the data format within the HTML, making it easily identifiable increases the ease of that data being accessed and used by an application on behalf of a user. (which is an interesting side effect as one the MicroFormats.org’s mantra’s is human readable over machine readable).

Now if that ease of identification and interpretation occurs within the HTML realm, it’s easy to apply the same logic to JSON data that is being returned as part of an API. If I’m writing widgets, or tools that could communicate with a number of different API’s from multiple application developers it would be really nice and easy if they all used the same format (or style of format) for common data groupings (people, places, dates, products, etc.)

You could then have common code that could be used to access those data formats. Custom handler functions in JS, PHP, Java, Python, Ruby, etc that is designed to sniff out and handle each of the microjson formats.

Flipping that round, you could also have common code to generate the JSON format as it comes out. So you’d have a single function call to write out the JSON for HCard data.

All of this common standard formatting should make both in out and in sides more efficient.

As of right now the MicroJSON site is empty. I’ll try and get something up there this weekend. Initially I’m thinking of mirroring the Microformats.org site, and just have a blog for posting news and updates, and a wiki for collaborative input. I’ll start by taking the confirmed formats, and porting them across into JSON with some example code for generation and parsing of the data.

I’ve installed the Blog and the Wiki and am progressing into adding some initial ideas and concepts. I’ve enlisted both Jim and Rick here at the office to add some of their thoughts, if anyone else is interested in contributing and collaborating on this, just let me know, everyone is welcome.

I think my first order of business is to find an acceptable schema system that can be used, then develop schema’s for the initial formats then make some validation tools available - once there we’ll have made a big step in the right direction - but there’s a long way to go.

Hopefully it will be of use to someone out there.