Having not spoken up so far, I'd like add my 2c. My atom feeds are all dynamic OpenSearch-style search results. By default they also happen to be traditional 'incremental' blog-style feeds. Instead of static archives, I have dynamic page=N sliding windows.
I'd like to be able to include machine-interpretable 'prev'/'next' links so that a user agent that wants to can reconstruct a complete (logical) feed whether that means a 'history' or just the current snapshot of results (and at a single instant in time it will get the same set of entries in either case). I'd also like to be able to include a machine-interpretable rel=subscribe link since in general the url I have to put in rel=self is not the optimal link for subscription. Mark Nottingham <[EMAIL PROTECTED]> wrote: > - Attribute Value: previous > - Attribute Value: next > - Attribute Value: first > - Attribute Value: last With regret I am -1 to those since I cannot use them consistently (with those definitions) from 'page 1' of my feeds depending whether I have my OpenSearch hat on or my incremental feed hat. I need a 'pure paging' definition of those relations that can also be used to reconstruct feed history as a side-effect in the special case where my feeds happen to be 'incremental'. > - Attribute Value: subscribe > - Description: A URI that refers to a feed document containing a > set of the most recent entries in the feed. This URI is intended to > be subscribed to to keep abreast of recent changes in the feed. When > different from the URI of the document where it occurs, it indicates > that its value should be used for this purpose in place of the > current document's URI. +1 I am happy with that wording, though it may have been improved later in the thread. Whatever may have been the original intention, the Atom spec is very clear that rel=self is very different from any possible rel=subscribe. Regards, Peter -- Peter Robinson <http://www.ticketswitch.com/> Concerts, sport and theatre tickets
