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?
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. The most recent archive will keep changing
over time, but that is the second item in the list (or second last,
depending on which direction you prefer to travel).
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.
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.
Regards
James
