Mark Nottingham wrote:
"A stable URI" was intended to capture that, but I see that wasn't
good enough. How about:
- Attribute Value: first
- Description: A stable URI that, when dereferenced, returns a feed
document containing the set of entries furthest preceding those in
the current document at the time it was minted. The set of entries in
this document should not change over time; i.e., this link points to
a stable snapshot of entries, or an archive of feed entries. Note
that the exact nature of the ordering between the entries and
documents containing them is not defined by this relation; i.e., this
relation is only relative.
- Expected display characteristics: ...
- Security considerations: ...
Another thought would be "first-archive", "last-archive", "prev-
archive" and "next-archive" (just expanding a previous thought).
-1. The first/next/prev/last link rels should not specify any
restrictions on how the contents of the feeds should or should not be
updated. If a specific use of these link rels wishes to impose such a
restriction (e.g. for feed history), then great, so-be-it, but the link
rels themselves should not.
And wrt "prev", why not "previous"? both could also be registered as
aliases…
I'd prefer one or the other; don't care much which it is, but two
seems wasteful. HTTP-WG didn't alias Referer even tho it's spelled
incorrectly, for example. That worked out OK.
+1, it doesn't matter... but I do prefer "previous" because I don't like
abbreviations in things like this
Otherwise, +0.5, because it seems to overlap @rel="first" (or
"last"?) – or I missed something…
I think we're kind of short on use cases for first and last, but
people seem to want them. 'subscribe' is more explicit; as they're
written, 'first' and 'last' should definately NOT be subscribed to
(because the set of entries in them won't change).
+1
- James
