08
May
06

application/atom+json

JSON looks to be an extremely useful data format for Ajax (client-side web) applications because it is javascript, and so it can be parsed efficiently and loaded from any URL (not just the host that served the web page), opening up the door to a new class of applications that do client-side data integration in the browser. Yahoo has a great writeup of how to use JSON services.

Now, most of the services that are currently coming out are in the lingua franca, XML. XML is great, but it doesn’t have the specific advantages that JSON does for Ajax (ironically, since the “x” in Ajax is XML… but then Ajax sounds better than Ajaj). So what to do? There does exist a universal mapping from XML to JSON called Badgerfish. This is good, but the problem is that the JSON output is funky. Who wants to have variables named “$”?

Can we do a nicer mapping in the case of a particular XML schema, namely Atom? Atom doesn’t use attributes too much, and that’s the stumbling block when mapping from XML to JSON. What if we came up with a JSON representation of Atom that was as similar to the XML as possible, but was actually a different representation. Let’s call it application/atom+json.

Looking at the canonical Atom example, we can picture the atom+json starting something like this:

feed={
  title:"Example Feed",
  link:{href="http://example.org"},
  updated:"2003-12-13T18:30:02Z",
  author:{name:"John Doe"},
  id:"urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6", ...

Ok, but with entry we have a bit of a problem, because there are typically more than one. So do we rename it to entries, and have it refer to a list? Seems reasonable…

  entries: [{
    title:"Atom-Powered Robots Run Amok",
    link:{href:"http://example.org/2003/12/13/atom03"},
    id:"urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a",
    updated:"2003-12-13T18:30:02Z",
    summary:"Some text."
   }, ...]
}

But wait, it can’t be that simple? Well, I guess there can be multiple authors, so do we make the authors always a list (frequently with only one element), or do we allow author to refer to be the same as authors with only one entry? The other issue is that in this example, link had no body, and none of the tags with bodies had attributes. The reason badgerfish goes into “$” and “@attr” syntax is because it’s possible to have both. But why pollute the Atom mapping with awkard constructs that rarely occur? An alternate mapping might be to say that, say you wanted to put an attribute on the title tag, you’d say, title_attr:value.

Hmmm….

Advertisements

4 Responses to “application/atom+json”


  1. May 9, 2006 at 2:31 pm

    Thanks Dennis — Actually, it was writing the same PHP script (with Magpie and JSON, but not quite as clean as yours) that lead me to write my post. The problem with this approach is that the schema is reflective of Magpie’s internal data structures which I think are lossy (they don’t preserve everything from the atom feed, but convert it to a lowest common denominator of atom and rss) and are non standard. I should be able to get an atom+json feed from most sites that already support atom+xml and rely on its structure.

    James Snell (also at IBM) has agreed to work on this with me… hopefully we’ll have an IETF draft soon.

  2. May 12, 2006 at 4:43 am

    I just spent couple of minutes and looked in the MagpieRSS source code. I see what you are talking about.

    This chunk of code in rss_parse.inc seems to explain the problem.

    // if inside an Atom content construct (e.g. content or summary) field treat tags as text
    elseif ($this->feed_type == ATOM and $this->incontent )
    {
    // if tags are inlined, then flatten
    $attrs_str = join(‘ ‘,
    array_map(‘map_attrs’,
    array_keys($attrs),
    array_values($attrs) ) );

    $this->append_content( “” );

    array_unshift( $this->stack, $el );
    }

    The PHP code takes the below Atom data:
    Gibberish
    Code

    And turns it in to (output as JSON):
    “dc”:{“subject”:”GibberishCode”}

    Which I agree is not a good solution, and would go as far as saying that it is just wrong. Flattening the data structure destroys a lot of the stored information (which does not have to happen).

    I can see at least one solution off the top of my head, but I do not know the ramifications of the modifications without studying the library a good bit more.

  3. May 12, 2006 at 4:48 am

    WordPress stripped out some of my Atom code.

    “Gibberish
    Code”

    Should be:
    <dc:subject>Gibberish</dc:subject>
    <dc:subject>Code</dc:subject>

    Hopefully this will work.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: