RSS expired
I’ve written a proposal for an RSS module that will mark a feed as expired. You can view the proposal here. Feel free to leave feedback as a comment in this posting or email me.
This work is licensed under a Creative Commons License.
November 29th, 2004 at 7:55 pm
In order to avoid “an endless discussion of architecture”, I’ll try to be brief.
1) Tag location (<rss> ve <channel>) might be important if existing consumers don't parse anything but the <channel> and its descendants. I don't know the answer to that, but it might be worth looking in to. Might also be irrelevant.
2) The namespace <expired> might be misleading, since the feed might not actually be expired. I'm being pretty damn picky here, I know – it's the little bits of English major left in me. Namespace *could* be disambiguated, but not essential.
3) have you considered using date not as an attribute, but instead as the contents of the tag" <expired :expired>2004-11-30</expired>? More like Dave Winer's ISSN module that way, if you care.
My main concerns are 1) generic so that it can be used for other than podcasts – I think you've accomplished that, and 2) allows for date-specific expiry – either of the options will accomplish that. Anything else is gravy. I don't know to what extent you've thought about the myriad of ways this *could* be used, but what you've got serves the basic purpose.
cori
aka kinrowan
p.s. I suspect your proposal page has a couple of copy-paste errors where you left in the data from Dave Winer's page that you borrowed from without updating. Specifically the namespace line and the line describing the example file (both still reference ISSN and <number>).</number></expired></channel></channel></rss>
November 29th, 2004 at 10:09 pm
On the issue of the expired tag being a child of rss or channel, I still don’t think it makes a big difference. Either way the consuming application is going to have to make some adjustments.
On the issue of naming the namespace, I’m pretty sure the creator of the RSS feed can actually use whatever they want for the name of the namespace, so long as it references the proper URL.
I’m definitely going to add a date aspect, but probably as an attribute. I’ll probably actually make it date and time. However I’m still open to suggestions.
p.s. thanks for the pointers on the typos, they’ve been fixed, I think.
November 30th, 2004 at 4:41 pm
Again, personally I prefer the ISO 8601 date format, much simpler and it doesn’t seem to me that expiry is more senitive than 24 hours. However you probably have a better feel for this – I’m not anticipating developing any feeds that expire any time soon. Also, the ISO 8601 date spec is not the one that RSS uses, so maybe it would be better to use that date spec instead of the one I prefer.
Attribute or text of node – don’t think that matters much, either – I usually try to avoid attributes unless I need them for something; if there’s data to be had then it should be in the node – at least that’s my interpretation of the spirit of XML. However either will work as far as I can see.
Naming – I think you’re right – the alias is handled by the producer when it’s produced. And we’ve already discussed the <rss> vs <channel> thing on the list.
Thanks for your work on this!
cori
November 30th, 2004 at 5:08 pm
Cori-
You make a good point regarding date formats. I forgot that RSS uses the old RFC 822 format rather than the newer 8601 format. I think consistency would be good in this case.
Also on the attribute vs. node issue I think you may be right. It certainly is easier to parse if the data is in the node. However, to maintain the self-descriptiveness, I think it would have to be like this:
<expired :expired> <expired :date>Sat, 07 Sep 2002 09:42:31 GMT</expired> </expired>December 9th, 2004 at 3:22 am
When I saw your post on a mailing list I assumed the purpose was to express the same thing as HTTP 410 Gone. But I get the impression that though the feed will no longer change, it will still be available – is that correct? (Maybe mentioning 410 in the spec may help clarify?)
btw, if the data appeared within the rdf:RDF element, this would also be valid RSS 1.0 (there may be better ways of making the “expired” statement, this way it wouldn’t be semantically associated with the channel resource).
December 9th, 2004 at 7:14 am
Ryan;
Your spec still calls out the ISO 8601 datetime spec but the sample files use the RFC822 specification (the one used in RSS: http://blogs.law.harvard.edu/tech/rss#optionalChannelElements).
As discussed before (and much as I hate it), I think that the RFC822 spec is the right way to go for this module, so I think your spec just has an error re: the datetime reference.
While we’re on errors, I think the intro line needs to be updated to refletct the change to make the module operate at the <channel> level. Also, I suspect that “this feed to every change” should read “this feed to ever change”. Sorry, I’m a little nitpicky about this stuff – it’s the remnants of the English degree….
cori
December 9th, 2004 at 10:50 am
Danny-
You’re right, this module is for feeds which need to still be availble, though they aren’t being added to anymore. It’s a way to signal to the feedreader that they can stop checking the feed after this time.
Also, re:RSS 1.0- I’m not planning on making this compatible with RSS 1.0 because the main reason to do this is for podcasts feeds which have enclosures.
Cori-
Thanks for your pointers. I’ve fixed the errors you found.