I spent last night explaining, in 30 seconds or less, RSS and blogging and XML and VFP consumption of RSS and news aggregators and RSS production - whew! - and I'm pleased to see the discussion heat up again here (in the blogosphere) again today. Here's a sample of the links I'm trying to keep up with:
Fixing RSS's public-relations problem. Yesterday I spoke with two acquaintances, both of whom have decades-long track records in the high-tech biz, and neither of whom has ever used an RSS newsreader. When I mentioned RSS as an alternative to mailing lists, both said the same thing: "But I don't have time to visit 30 different websites in order to find things out." Of course, that is exactly the problem that RSS solves. And has been solving, for me, since 1999.
... [Jon's Radio]
Post IDs. FWIW, in RSS 2.0, I thought there should be a core-level post ID element, but I thought there was a pretty good chance, based on experience with the Blogger API, that each tool would have a different way of expressing it.
The compelling app for post ID's is backup and restore. If I'm using RSS to back up a weblog, and if I need to do a restore, the post ID's must be preserved, or when I regenerate the site after a restore, permalinks will break. Also since Radio and Manila are programming environments, developers may have created applications that depend on post ID's being preserved. The same is true of many other blogging tools.
Rather than put this in the core, I decided to put it in a namespace, specifically for Radio, and to revisit the issue after other blogging tools started using RSS 2.0 seriously. [Scripting News]
The lizard brain of RSS. Simon Willison is helping a friend get an RSS feed together for her weblog, and had some questions and had to guess because there is no FAQ. Of the three decisions he made, I strongly agree with two of them. Now for the third -- should he use link or guid to represent the permalink to the post? I believe he should use guid because that's what it was designed for. Link was designed for something else.
First, link has the easier name because it predates guid by three years, and its design is central to the initial design of RSS, to model items with three bits of data, title, link and description. Look at a News.Com story as the prototype for early, lizard-brain-level RSS. Every story they produce has all three items. My.Netscape presented each "channel" in a box, with TLD's. Now when weblogs started using RSS, almost immediately, not every post would have all three, in fact since Frontier was the main weblog tool at the time, and didn't support the common weblog-post model so familiar today, you might say that no weblog posts supported this model. It wasn't until Blogger came along in mid 1999 that TLDs were possible in weblogs. It wasn't until mid-Y2K that Manila supported TLD-type posts.
Anyway, I'm explaining all this background for a purpose, to say that, imho, link should be used only to link to the article being described by the post, it should only be used in the TLD context. I believe that was a very solid application and shouldn't be muddied. Of course many feeds these days take link seriously, like for example all 68 of the BBC feeds announced yesterday.
Now that said, Radio uses link the way Simon uses it. But then guid didn't exist when Radio shipped. Now that it does exist, I really feel strongly that people should use it, and let link be pure.
See also: Guids are not just for geeks anymore.
See also: RSS2-Support mail list. [Scripting News]
5:59:09 PM 
|
|
