Dave Winer posted some Ideas for the evolution of RSS and is soliciting feedback. He has proposed the addition of 3 new optional tags to RSS. I will give feedback on each element individually.
The first element proposed is pubDate. This element is unnecessary. The Dublin Core module of RSS 1.0 contains a 'Date' element for this exact purpose.
The second proposed element is guid. I like the idea of this element though I disagree with it's proposed implementation. I think the idea of a globally unique identifier for each 'item' is good. I would prefer to see it as the 'ID' attribute of the 'item' element and not as a seperate element. Setting it as the 'ID' attribute would allow validating parsers to enforce the uniqueness requirement at least across a single document.
The third proposal is for the addition of a tty element. This element, like 'pubDate' is redundant. Much more information is available by using two already standardized mechanisms. The first is the 'updatePeriod', 'updateFrequency', and 'updateBase' elements available in the Syndication module of RSS 1.0. The second mechanism is using the ETag header available in HTTP/1.1. Simon Fell gives a very clear explaination of how this works. With these two mechanisms, already supported in current standards, you get much more information than the 'tty' element would bring.
The last suggestion I would offer is that when these elements are included in RSS feeds they should be in their own namespace. http://backend.userland.com/ideasForEvolutionOfRss would be a perfect namespace qualifier for such elements.
Hi Mike. Mike is Steven's father and has a very nice woodworking blog. I have done a lot of woodworking and I am always torn about posting more woodworking items on this blog. I would like to keep this blog focused on technical topics and I am considering enabling categories or creating a whole separate blog. Until then, I'll read Mike's postings to keep me motivated.
Aggie 1.0 RC is available for download here.
I have found and corrected a bug in Aggie RC1 and also added one feature. The bug is in handling namespaces. Some RSS feeds, like Ugu Cei's RSS 1.0 feed have all the elements namespace qualified. This is perfectly valid and it was a bug in Aggie that it was not able to parse his 1.0 RSS feed.
The enhancement is the addition of a 4th column to the display which contains detailed error information for channels that do not process properly.
The same install instructions apply, but be careful if you have added files to myChannels.opml that you either back it up before installing Aggie 1.0 RC2 or make sure not to extract myChannels.opml from the ZIP file.
There is more movement in the RSS arena, so let me summarize my opinions:
Half the fun of writing Aggie is now having a client platform to play with when experimenting with feeds, new elements, and how to display that info. My life as the author of Aggie becomes much easier if extensions are in their own namespace. I can ignore them safely and selectively honor them as I see fit. (It's also open source software so you can honor elements as you see fit by modifying the software yourself.) Keeping extensions in their own namespace is such simple and fundamental idea in XML that my mind boggles when someone violates it.