On 17/10/2005, at 12:31 PM, James M Snell wrote:
Debating how the entries are organized is fruitless. The Atom spec
already states that the order of elements in the feed has no
significance; trying to get an extension to retrofit order-
significance into the feed is going to fail... just as I discovered
with my Feed Index extension proposal.
+1
I do believe that a "last" link relation would be helpful for
completeness and I do believe the use cases are there (e.g. search
results, etc) but I am ok with dropping that for now as it can
easily be defined later once the use cases do become more prominent.
Over the next week I'll see if I can draft up the spec. I'll use
what MarkP put together as the basis for what I write up and submit.
We actually don't need a spec, according to -11; we just need to send
an e-mail to IANA requesting the registrations, and get IESG
approval. Assuming we can come to WG consensus, that should be easy.
I took a look at doing this over the weekend, and this is what I came
up with;
- Attribute Value: prev
- Description: A stable URI that, when dereferenced, returns a
feed document containing entries that sequentially precede those in
the current document. 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: Because automated agents may follow
this link relation to construct a 'virtual' feed, care should be
taken when it crosses administrative domains (e.g., the URI has a
different authority than the current document).
- Attribute Value: next
- Description: A stable URI that, when dereferenced, returns a
feed document containing entries that sequentially follow those in
the current document. 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: Because automated agents may follow
this link relation to construct a 'virtual' feed, care should be
taken when it crosses administrative domains (e.g., the URI has a
different authority than the current document).
- 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:
- 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.
I have one concern about this approach, which I'll outline separately
(in response to Robert).
--
Mark Nottingham http://www.mnot.net/
