On 17/10/2005, at 4:07 PM, Thomas Broyer wrote:
- Attribute Value: first
- Description: A stable URI that, when dereferenced, returns a
feed document containing those entries furthest preceding those in
the current document at the time it was minted. 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:
- Attribute Value: last
- Description: A stable URI that, when dereferenced, returns a
feed document containing those entries furthest following those in
the current document at the time it was minted. 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: Undefined.
- Security considerations:
+0.5 (adding the circular references issue raised by James),
because some people will use "first" to link to the "live" feed
(the one you subscribe to) and "next" to link to the first archive
document and so on, and some will use "last" and "prev" for the
exact same roles…
The given definition is not precise enough.
"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).
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.
- Attribute Value: subscribe
- Description: A stable URI that, when dereferenced, returns a
feed document containing the most recent entries in the feed. This
URI is intended to be subscribed to to keep abreast of changes in
the feed. When different from the URI of the feed document it
exists in, it indicates a URi that should be used for this purpose
in place of the current document's URI.
- Expected display characteristics: Undefined.
- Security considerations: Users should always be informed of the
actual URI they are subscribing to, and subscription should only
take place when it is explicitly requested.
Depends whether @rel="self" was really meant for subscribing and
the spec wording is not precise enough about it; this could then be
fixed with an errata rather than create a new link relation…
I think there's value in the current reading of "self"; it's
sometimes useful for a document to know what URI it's available at.
Also, when it occurs in another feed, "self" is a very non-obvious
name for what's happening.
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).
Cheers,
--
Mark Nottingham http://www.mnot.net/
