On 19/10/05 10:58 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
>>> I already have code that uses "next" for this. Why do we want to change it? >> >> Why did you choose "next"? > > Because that is what's already been deployed and what my software uses. -1. Someone else made a poor choice*, you copied that, it's confusing, why enshrine it into official specs? Why not take this opportunity to make a better choice? I looked at Pilgrim's atom feed document for March 2004 ... it said the next document was February 2004 and the previous document was April 2004. Try explaining to anyone that isn't writing an aggregator why that makes sense. There are entries written in March which are a continuation of a story written in February. So no, his feed is not reverse chronological. You might want your aggregator to process various feeds in a reverse chronological manner ... so please use the 'prev' link to go _backwards_ through the feed, and the 'next' link to go _forward_ through the feed. Though there may be many Atom 0.3 feeds out there now, all those Atom 0.3 feeds will need to be rewritten for Atom 1.0. Even so, all those Atom 0.3 feeds are, you must admit, just a drop in the ocean of the potential deployment of Atom 1.0 feeds from many many content publishers. Count the number of websites that have semi-regular news, count the number of websites that have feeds (of any flavour) ... it's a drop in the ocean. Now count the number of aggregator developers.. e. * and it's not the only poor choice that we're stuck with right now. Consider how you might link from an HTML page which is the monthly archive of your blog to an Atom Feed Document which is the XML representation of that same content. We know what @href and @type to use ... but the @rel='alternate' is already taken for the semantic of "subscribe to this feed for ongoing updates". Thankfully we're avoiding that snafu with @rel='self' vs @rel='subscribe'.
