{ "attachments": [], "comments_archived": true, "date": "2005-05-05T15:08:42.000Z", "layout": "post", "title": "The right place for data in your feed", "wordpress_id": 641, "wordpress_slug": "the-right-place-for-data-in-your-feed", "wordpress_url": "http://www.decafbad.com/blog/?p=641", "year": "2005", "month": "05", "day": "05", "isDir": false, "slug": "the-right-place-for-data-in-your-feed", "type": "entry", "postName": "2005-05-05-the-right-place-for-data-in-your-feed", "html": "

I've suddenly gotten very interested in microformats, especially since it struck me very soundly that they belong in this final chapter of my book about extending feeds.

\n

I started off writing a bit about mod_event and RVW with respect to extending feed formats with additional metadata, but then the microformat thing hit me: Why extend the feed format metadata when you can extend the feed content? This seems so obvious to me that it's either got to have been covered by someone else already, or it's so wrong that I just haven't seen it yet.

\n

For one thing, extending the format limits your extension to that format, unless you craft it in such a way that makes it compatible with other feed formats. This is not impossible or even hard in some cases, but it's more of a problem of adoption and buy-in than a technical issue. mod_event is an RSS 1.0 extension; how many RSS 2.0 or Atom 0.3 feeds have you seen using some adaptation of mod_event? (Though, to be fair, how many RSS 1.0 feeds have you seen using mod_event in the first place?)

\n

Just what do calendar events have to do with syndication feeds, other than that feeds are a convenient carrier wave? Why should we try to shoehorn calendar data into the fabric of a feed itself?

\n

All the feed formats I care about can carry (X)HTML content, and these microformats are just XHTML content constructed along a certain set of conventions. So, any feed supporting XHTML content can carry microformat-enriched content--without, necessarily, any feed format alterations, convincing of feed format authors, or buy-in from aggregator developers. (Of course, you might need those developers to actually do something with the microcontent when it arrives, but that's another story.)

\n

Leave the feed to manage the business of facilitating push-via-poll with aggregators and decouple the markup and structure of rich microcontent items from feed formats altogether.

\n

Furthermore, this helps address the question of \"Is a feed the right place for your data?\" My tentative answer to this is, \"No, but it doesn't hurt if it's in there, too.\"

\n

Think of the feed as just a mechanism to facilitate content delivery--and not as the embodiment of the content itself. Mind you, feed entries do make nice representations of content, covering many common attributes. But, keep feeds themselves constructed in terms of metadata about content. Although items of content might also be carried in full in feed entries, the \"real\" content should exist somewhere else as well.

\n

Things like mod_event should be used to provide hints to aggregators whose authors, for instance, might not care to bundle in and maintain a full-blown microformat parser.

\n

Think of a MySQL table: You can define columns in a table, and then you can define zero or more indexes on those columns. The data's still there if you don't define any indexes, and queries are still possible--it's just that queries are more laborious. And, your indexes don't need to be matched up one-to-one with your columns--they can be concatenations of columns, or just about whatever else you want.

\n

Consider mod_event like an index for aggregators on hCalendar content--hCalendar defines the columns, mod_event facilitates better routing/filtering. Although getting buy-in from feed format authors and feed aggregator developers helps get indexes created, you don't necessarily need that to get the content into the feed in the first place.

\n

Okay... I think all that made sense. I had to get that spewed out of my head before I lost it. :)

\n

Archived Comments

\n\n\n\n
\n\n\n", "body": "I've suddenly gotten very interested in [microformats][mf], especially since it struck me very soundly that they belong in this final chapter of my book about extending feeds. \r\n\r\nI started off writing a bit about [`mod_event`][me] and [RVW][rvw] with respect to extending feed formats with additional metadata, but then the [microformat][mf] thing hit me: Why extend the feed format metadata when you can extend the feed content? This seems so obvious to me that it's either got to have been covered by someone else already, or it's so wrong that I just haven't seen it yet.\r\n\r\nFor one thing, extending the format limits your extension to that format, unless you craft it in such a way that makes it compatible with other feed formats. This is not impossible or even hard in some cases, but it's more of a problem of adoption and buy-in than a technical issue. [`mod_event`][me] is an RSS 1.0 extension; how many RSS 2.0 or Atom 0.3 feeds have you seen using some adaptation of [`mod_event`][me]? (Though, to be fair, how many RSS 1.0 feeds have you seen using [`mod_event`][me] in the first place?)\r\n\r\nJust what do calendar events have to do with syndication feeds, other than that feeds are a convenient carrier wave? Why should we try to shoehorn calendar data into the fabric of a feed itself?\r\n\r\nAll the feed formats I care about can carry (X)HTML content, and these [microformats][mf] are just XHTML content constructed along a certain set of conventions. So, any feed supporting XHTML content can carry microformat-enriched content--without, necessarily, any feed format alterations, convincing of feed format authors, or buy-in from aggregator developers. (Of course, you might need those developers to actually *do* something with the microcontent when it arrives, but that's another story.)\r\n\r\nLeave the feed to manage the business of facilitating push-via-poll with aggregators and decouple the markup and structure of rich microcontent items from feed formats altogether.\r\n\r\nFurthermore, this helps address the question of \"[Is a feed the right place for your data?][fd]\" My tentative answer to this is, \"No, but it doesn't hurt if it's in there, too.\" \r\n\r\nThink of the feed as just a mechanism to facilitate content delivery--and not as the embodiment of the content itself. Mind you, [feed entries do make nice representations of content][au], covering many common attributes. But, keep feeds themselves constructed in terms of metadata about content. Although items of content might also be carried in full in feed entries, the \"*real*\" content should exist somewhere else as well.\r\n\r\nThings like [`mod_event`][me] should be used to provide *hints* to aggregators whose authors, for instance, might not care to bundle in and maintain a full-blown [microformat][mf] parser. \r\n\r\nThink of a MySQL table: You can define columns in a table, and then you can define zero or more indexes on those columns. The data's still there if you don't define any indexes, and queries are still possible--it's just that queries are more laborious. And, your indexes don't need to be matched up one-to-one with your columns--they can be concatenations of columns, or just about whatever else you want. \r\n\r\nConsider [`mod_event`][me] like an index for aggregators on [hCalendar][hc] content--[hCalendar][hc] defines the columns, [`mod_event`][me] facilitates better routing/filtering. Although getting buy-in from feed format authors and feed aggregator developers helps get indexes created, you don't necessarily need that to get the content into the feed in the first place.\r\n\r\nOkay... I think all that made sense. I had to get that spewed out of my head before I lost it. :)\r\n\r\n[au]: http://www.decafbad.com/blog/2004/05/17/use_atom_for_a_universal_blog_transfer_protocol\r\n[hc]: http://developers.technorati.com/wiki/hCalendar\r\n[fd]: http://bitsko.slc.ut.us/blog/feed-data.html\r\n[me]: http://web.resource.org/rss/1.0/modules/event/\r\n[rvw]: http://www.pmbrowser.info/wiki.pl?RVW\r\n[mf]: http://developers.technorati.com/wiki/MicroFormats\r\n\r\n
\r\n

Archived Comments

\r\n \r\n \r\n \r\n
\r\n ", "parentPath": "./content/posts/archives/2005", "path": "2005/05/05/the-right-place-for-data-in-your-feed", "needsBuild": true, "prevPostPath": "2005/05/05/more-random-tiger-and-mac-thoughts", "prevPostTitle": "More random Tiger and Mac thoughts", "nextPostPath": "2005/05/06/idempotency", "nextPostTitle": "Idempotency: It's not just for APIs (or, the web is an API)" }