On 18/10/05 12:43 AM, "James Holderness" <[EMAIL PROTECTED]> wrote:
> Eric Scheid wrote: > >> I'd prefer that our use of 'prev' and 'next' be consistent with other uses >> elsewhere, where 'next' traverses from the current position to the one that >> *follows*, whether in time or logical order. Consider the use of >> 'first/next/prev/last' with chapters or sections rendered in HTML. >> > I'm still not exactly sure which of the two options you're in favour of. This > is the reason why the point is being debated - it's not immediately obvious > which way is most consistent with usage elsewhere. Nottingham or Pilgrim? > hmmm ... I did say "Consider the use of 'first/next/prev/last' with chapters or sections rendered in HTML"... Chapter #1 comes first, followed by chapter #2, and you go from chapter #1 through to chapter #nnn via 'next'. Think too of Pepys' Diary. What would you consider the 'first' entry? Would the 'first' entry be 1st January 1660, or would it be 16th October 1662? Note well though that sometime tomorrow the latter point would be neither 'first' or 'last' because there would be a new entry for the 17th October 1662 (and yet another one the day after). >>> 2. Are next and prev both needed in the spec if we only require one of them >>> to reconstruct the full history? >>> >> Knowing that the most recently published archive won't likely remain the most >> recently published archive, there will be use cases where it's better to >> reconstruct the full history by starting at the one end which is fixed. Not >> much sense starting at the other end which is constandly shifting. >> > The way I understand it, both sides are fixed as soon as there is at least one > archive. At the one end you have the oldest archive. At the other end you have > the current syndication document (to which the end-user would subscribe). Both > URIs are fixed. What I mean by fixed is that it doesn't move or change as the set grows. Adding one onto the end and resetting where 'last' points to means that 'last' is *not* fixed. What you mean is that as soon as there is at least one archive then both ends are *established*. One end is fixed, and the other will grow. >>> 5. Is the issue of whether a feed is incremental or not (the fh:incremental >>> element) relevant to this proposal? >>> >> non-incremental feeds wouldn't be paged, by definition, would they? >> > This has been debated. There have been those who have expressed an interest in > having next and prev links traverse an archive of old non-incremental feeds. > Say you have a feed with the top 10 books for this month. The next link (or > prev link, depending on your preference) would point to the archive document > with the top 10 books from last month. That makes sense. > Personally I think that is an issue that should be argued and subsequently > specified in a separate proposal on the use of non-incremental feeds. Just > make sure the history spec is open enough to allow for either possibility once > it is decided. I agree. So .. the issue of (not-)incremental is orthogonal to feed history then. e.
