Fetch Me A Rock
We have all experienced the pleasure of trying to please either customers or bosses who don’t really know what they want. It isn’t fun.
Dare Obasanjo recently identified the top 5 sites that, in his opinion, need to get RSS feeds. When told that the second on his list already had a feed, his response was that “It does have the annoying characteristic of not having dates in it.”.
In some corporate contexts, this process is referred to as “Fetch me a rock”. It goes something like this: “Fetch me a rock. No, not that one. Fetch me another. Now jump through this hoop.”
Just a few days before, Dare had stumbled across a related date problem. It seems that RSS 2.0 didn’t have the date he needed, so proposed using a Dublin Core element in a manner other than the way it was defined. So far, Dare seems to have obtained little traction on this idea.
RSS History
Some trace RSS back to 0.90. In those days, RSS was viewed as a vehicle for metadata only — whose sole purpose was to direct eyeballs back to one’s site.
At that time, there was one visionary who saw things differently. His name was Dave Winer. He saw RSS not as a vehicle for delivering metadata, but for delivering content. He saw RSS 0.90 as woefully inadequate. It’s missing the key thing web writers and readers need. He had a competing format, named ScriptingNews, from which RSS 0.91 borrowed the description element.
Apparently, Dave was savvy enough to know that if description was mandatory that he would be flamed royally for doing so. So in RSS 0.91, the most important element for using RSS as a channel for delivering content was the one and only optional element of item.
Dave then followed up by RSS 0.92 which leveled the playing field and made every subelement of item optional. This was OK, as the other elements that RSS 0.91 had weren’t the vital ones that people really wanted, namely ids and dates. Those came later.
Boring Committee Work
Fast forward to 2005. All of the important elements remain more or less optional in RSS, which leads to “interesting” interoperability factors. Such as the ones that Dare alludes to above.
After literally months of exhaustive discussion, the AtomPub IETF working group has come to consensus on requiring an id and a date on every entry (incidentally, this date is exactly the one that Dare expressed a need for). Entries also require either a summary or a content which can be rendered as text.
What about people who simply want to syndicate metadata [despite there being a more than adequate format defined for such purposes]? What about people who are simply trying to scrape together whatever bits they have in the hopes that it might be useful for somebody [despite there being a more than adequate format defined for such purposes]?
Alas, it seems to be the destiny of all standards bodies to take every fork. If there is somebody who might reasonably be able to produce something, by all means lets enable it, even if it creates downstream confusion.
This leads to the following controversial proposal from PaceTextShouldBeProvided:
atom:entry elements which do not contain an atom:content element, or whose atom:content element’s type attribute indicates a MIME media type, SHOULD contain an atom:summary element.
To some, this is not permissive enough.
Lets hear from users
What, ideally, would people like to see in syndication feeds?
What I am seeking to know is what can we do so that we can get as close as we can to the point where getting a valid Atom feed means that you already know that you are going to have all the information you want. Even if it means that the producers have to do a little more work.
Once we know what it is, we can decide what goes into the spec itself, and what can go into a BCP document.