On Oct 19, 2005, at 11:12 AM, Mark Nottingham wrote:
"next" "next-chunk" "next-page" "next-archive" "next-entries" are all workable for me.
...
Perhaps people could +1/-1 the following options: * Reconstructing a feed should use: a) a specific relation, e.g., "prev-archive" b) a generic relation, e.g., "previous"
I'd prefer "prev-page". "prev-archive" doesn't sound right for paging through search results. Also, "prev-archive" or "next- archive" (whichever ends up going forward in time) doesn't quite work if the final step forward points to the subscription feed URI (which isn't an "archive". That's a small matter since it's only that last step, but in search results type cases, "archive" would definitely be odd.
Just a little follow up on what I wrote last night about generic vs. specific link relations: "related" is a generic term that is likely to be a bit of a catch-all for links that don't have a specific relation defined for them. "alternate" is a specific relation created for one of the major historical use cases for rss/link. The proposed but not accepted "about" would have been the specific relation for the other major use case that rss/link was commonly used for.
"related" could conceivably handle the hypothetical use case of traversing a chain of different feeds--you'd just have to remember which "related" link to a feed document you had already traversed to know which one to follow next to continue down the chain. It wouldn't be quite as nice for such an application as having a "next" and "prev" for that use, but I'd rather see it done that way till it's clear that such a thing is even needed than see intrafeed paging links used for interfeed navigation.
