On 10/17/05, Mark Nottingham <[EMAIL PROTECTED]> wrote: > Robert, > > It's a matter of personal preference as to whether one likes 'prev' > or 'next'; if there had been wide implementation and a good > specification of what MarkP did, I could see a strong argument for > using it.
I think the spec is perfectly clear. Is there something about it you don't understand? I do think your addition of an indicator that the feed is an archive is a good idea. I have to disagree with your characterization of deployment. Most AtomAPI implementations work this way--see for example typepad.com. > My concern is that if there is more than one use of a link relation > like 'next' or 'prev', those uses could conflict. For example, if I > use 'prev' for Feed History, will that cause a problem with feeds > using Amazon OpenSearch if they want to use it in a slightly > different way? To put it in Thomas' terms, what if there are > different concepts of paging using the same terms -- which there seem > to be already? > > This shows up perfectly with the whole "next or previous?" > discussion. If we don't assign specific, functional semantics to the > links, people will interpret -- and use -- them differently. Folks who have written Atom clients know which way 'next' points. > > This is why I'm leaning towards "prev-archive". Mmm. I think 'prev-archive' means exactly the same thing that 'next' does in the feeds you're describing, and people will certainly use it in ways that don't reflect whatever you lay out in the spec. They will look at a feed, and think "oh, I use prev-archive to get the next 10". I know for a fact that other feeds So, now we have two ways to say the same thing -- The Tower of Babel problem. http://tantek.com/log/2005/07.html#towerofbabelproblem Robert Sayre
