Daytime Running Lights

The future is here, it's just not evenly distributed yet.

Elsewhere: Tumblog / Twitter / MP3 Blog / Reader / Email

• Livin'
• Coding
• Music
• Vinyl
• Quote
• All

ATOM over JSON

ATOM over JSON

By jchris in Coding 11 months ago.

This was posted as a comment to Sam Ruby’s discussion on the merits of a verbose JSON serialization of ATOM entries’ HTML content to CouchDB-style map/reduce jobs. I found the direction a potential ATOM -> JSON serialization was heading to be troubling. JSON variants best serve user uptake by being the simplest thing that can possibly work.

We had a similar discussion about XSPF -> JSON serializations thread on the XSPF mailing list about crafting a JSON transform. The tension in that thread was between a more verbose (generic and reversible XML -> JSON) transformation, or one which took the known aspects of the XSPF schema as a prerequisite for simplifying the JSON.

We ended up using the later, with the compromise that the one area of the XSPF spec which allows for arbitrary XML, allows for arbitrary JSON (allowing rather than requiring a verbose XML -> JSON transform).

I know this isn’t quite a discussion about standardizing ATOM in JSON, but should such a discussion arise, bear in mind that JSON’s principle virtue is simplicity, and that coders want to use it because it makes their lives easier. Perhaps providing a node in the JSONified ATOM which allows for arbitrary JSON is just the ticket. In that node, Sam, you could store your DOM-style parse tree of the entry’s content, and your CouchDB jobs could reference it.

Thinking about it this way separates concerns – ATOM should have the simplest JSON serialization that could possibly work, and it looks like that serialization will need a bucket where users can pour extra complexity (like parse trees and other application-specific data). Keeping the extra complexity out of the standard JSON elements lowers the barrier to entry and raises the readability of the rest of the format.

2 comments