Bill Kearney writes referring to Edd Dumbill's article Addressing RSS's logical model:
Basically what Edd's saying is that there could be more than one channel in a feed document and that the items could be shared among those different channels. This as opposed to sending out a separate feed for each channel and duplicating items all over the place. The channel itself has a sequence container that indicates not only what order to use but what items to use. That rdf:Seq container is telling you what items to use in the channel.
So, once again, the strange way RSS-1.0 appears to be doing things has a much deeper value.
While in theory RSS 1.0 may be doing something of deeper value, that value is generally not a feasable realization in practice. This was a question I raised some time ago and never got a satisfactory reply that justifed such a need for this "value."
Recent threads have indicated that RSS bandwidth consumption, whether centralized or decentralized, is becoming a major issue. Part of this can be solved by designing smarter aggregators which has begun to happen. Another part to handling this issue rests on publishers to develop a feed that conserves bandwidth while still remain useful to its taraget audience.
In certain circumstance having one item in multiple channels may help conserve bandwidth, but overall I believe it would not. In fact, if put in practice this would enlarge RSS feed files even further and make it more difficult for consumers to conserve bandwidth. Suppose I where to use RSS 1.0 to create one "uber" RSS file with channels for my latest posts overall and in each category. If a consumer wanted the items in one channel, they would have to download all the items and channels then resolve my channel's <Seq> list with the items. Perhaps the item in the channel of interest has not been updated while another has thereby changing the modified on timestamp -- more wasted bandwidth. Since I use a tool that generates my RSS feeds, as do most others, creating separate files for each channel is trivial. This approach can conserve bandwidth by containing only relevant information to the channel. (This is of the utmost importance when the end user is in a low-bandwidth resource constrained environment such as a mobile phone.) It also allows end users to subscribe to only receive the channels that interest them by a unique URI. (Multiple channels in one file/URI is not very RESTful. RESTonians have railed against SOAP's one URI, many methods approach how is this different?) Its also more straight-forward to process and allows for HTTP Modified-Date and ETags to be reliable and accurate.
I'm of the mind that the <rss> and <channel> tags should get folded together into one tag -- preferably just <channel>. Assuming the window has not already closed, I'm also of the mind that rather then try and justify its design decisions with theoretical idealism the RSS 1.0 working group spend its making modifying the specification to be useful and more practical -- or perhaps they should be the ones to take up knitting.
Leave a comment