Antone Roundy wrote:
On Oct 17, 2005, at 3:44 PM, Mark Nottingham wrote:
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.
Here's what the spec says: "This specification assigns no
significance to the order of atom:entry elements within the feed."
...but there may be some. ...but there's no action you can take
based on it unless something else tells you what the significance
is. ...which, yes, is very difficult to specify.
Not only difficult to specify, impossible to enforce. There's no way we
can expect implementations to preserve the order of entries
For the purposes of this discussion, it doesn't matter what the order
of atom:entry elements within a feed document is. But the order of
chunks of atom:entry elements within a linked series of feed
documents may have significance, and in fact, unless you just want to
reconstruct the complete feed state, working with a series of feed
documents with no specific order would be fairly unwieldy. Imagine
paging though a feed of search results with no idea of whether you'd
just jumped from the most to the least significant results, or to the
second most significant results. Imagine trying to catch up on a
fast-moving incremental feed without having any idea whether a link
would take you to the first entries ever added to a feed or the one's
you just missed.
That's what incremental=true is for, or the feed rank mechanism, etc.
Basically, the next/prev mechanism should be used in conjunction with
something else that specifies the ordering of the entries, etc. The
next/prev link relations should imply nothing more than a linked list of
feeds.
I do believe that a "last" link relation would be helpful for
completeness
...and "last" certainly seems to imply SOME sort of ordering of
chunks, even if we know nothing about the order of the entries in
each chunk.
Nope. It implies nothing more than a closed-set linked list of feeds.
No ordering is implied. We could achieve the same result with
rel="start" and rel="end"
To each of the following, perhaps we could add something to indicate
that these link relations are all used to page through the current
state of a feed, and not to navigate among various states of a feed.
The fact that most people wouldn't have a clue what that means
without some discussion of incremental and non-incremental feeds may
be an argument for having a spec document to provide more explanation
(rather than embedding an identical explanation in each
Description). Example:
When I think of next/prev I'm not thinking about any form of temporal
semantic. I'm thinking about nothing more than a linked list of feed
documents. If you want to add a temporal semantic into the picture, use
a mechanism such as the Feed History incremental=true element.
In other words,
this does not imply a feed history thing...
<feed>
...
<link rel="next" href="..." />
</feed>
this does...
<feed>
...
<fh:incremental>true</fh:incremental>
<link rel="next" href="..." />
</feed>
"At any point in time, a feed may be represented by a series of Feed
documents, each containing some of the entries that exist in the feed
at that point in time. In other words, a feed may contain more
entries than exist in the Feed document that one retrieves when
dereferencing the subscription URI, and there may be other documents
containing representations of those additional entries. The link
relations defined in this specification are used to navigate between
Feed documents containing pages or chunks of those entries which
exist simultaneously within a feed.
Again, you're thinking in terms of Feed History. I'm separating the
link rel's out from Feed History and making them more generic. I would
fully expect that the Feed History spec would define some ordering and
processing semantic for the linked documents.
- James
