Hi Mark, Mark Nottingham <[EMAIL PROTECTED]> wrote:
> On 23/10/2005, at 1:04 PM, Peter Robinson wrote: > > > I prefer 'subscribe' because it better describes the meaning and > > intention behind the link, but I can live with 'current' if that is > > the consensus. > > Well, Tim seemed to have a pretty strong -1 on 'subscribe', whereas > you say you can live with 'current'. I can. The argument as I understand it is that relations should be nouns rather than verbs (describing what the link points to rather than what you should do with it). I can't argue that point, but I do feel that 'current' less encapsulates the intent than 'subscribe'. Someone else suggested 'subscription'. This should be my last word on the subject: Apparently it came as a surpise to some that rel='self' as defined is not the same as 'the url you should subscribe to' in the general case. I don't want to make the same mistake yet again. First example: consider a statically archived non-incremental OpenSearch-style feed split into pages: <http://www.example.com/feed/2001/page3> A reasonable interpretation (the only possible interpretation?) of rel='current' would be this: <http://www.example.com/feed/current/page3> which is certainly not the url you should subscribe to. Second example: a dynamic feed where cgi variables are used to set options, perhaps for use in building an html page of links rather than normal subscription, but you can come up with other uses: <http://www.example.com/feed?year=2001&no_atomcontent=yes> Rel='current' would point to <http://www.example.com/feed?no_atomcontent=yes> but it would be much better for PubSub or a desktop aggregator to go to <http://www.example.com/feed> if it ever got hold of such a feed. The second example is (essentially) something I already do. I don't expect urls like that to 'escape' into the wild, but I can't prevent it and I'd like to be able to give an aggregator something meaningful to do when it does happen. If we want to define a link relation meaning 'the url you should subscribe to' then that is what we should define. > So, at this point it looks like 'current', unless other people come > forward. I flirted with "recent" briefly; anybody strongly like that one? I don't think that is any better. > > I am also worried that this is being pushed through too quickly. > > I appreciate that, but it's a bit of a chicken-and-egg problem; we > won't get all of the implementation experience until it's defined and > widely deployed. That is true, but have you communicated with the OpenSearch people about this? I do strongly believe that *here* is the place for work like this, rather than behind closed doors at Amazon. But if I was them I'd feel pretty miffed that this WG appears to have basically stolen their idea in a desperate 'land grab', and turned it on its head so that it is (arguably) the complete opposite of their intended definition. [snips] > > OpenSearch uses 'next' to go from page=1 to page=2. The natural > > paging setup for an inremental feed that is also an OpenSearch results > > feed is to have rel=current (aka rel=subscribe) point to the first page > > of results (i.e. page=1). > > > > Is it the intention that history reconstruction uses 'next' links to go > > back into the past? [...] > Right now, the plan forward seems to be that 'next' et al will be > purposefully generic; i.e., they won't mean much until used in > conjunction with another extension (in my case, fh:incremental). > > My plan for feed history is to recommend people walk both 'previous' > and 'next' from the subscription feed, so that it doesn't matter > which "way" the feed goes. I see! That little nugget of an idea makes me feel a lot more comfortable about prev/next. So something that understands rel=previous, next et al will be able to reconstruct a complete logical feed, and the history extension will tell it 'which way is up' and whether it's a traditional 'incremental' feed. That makes a lot of sense. Regards, Peter
