So, an aggregator comes across a feed in the woods. It sees it has
"previous" and maybe "next" link relations.
The point that (I think) Thomas is making is that the people who
leave that feed document in the woods had better be comfortable with
the aggregator following the links and reconstructing the feed. After
all, most of them already keep feed history without any hints about
previous archives at all; if you give them a "previous" link, it'll
be a red flag to a bull, no matter what my spec says.
So, a feed that used "next" and "previous" to link to different weeks
of the top 100 (for example) would get jumbled up pretty bad, and not
display too well in aggregators.
My thinking is that if we go down this road, one of two things will
happen;
a) Aggregators will start paying attention to special flags (like
fh:incremental) that tell them the nature of the feed, and feeds will
start using them real quick.
b) Non-incremental uses of "previous" and "next" will die off,
because people who use them for those purposes will see aggregators
do strange things with their feeds.
I think (b) is somewhat more likely. Either way, I'm OK, but I do
note that (a) leads to two separate extensions being required in the
feed, when the same purpose could be served by a more specialised
link relation, and (b) will lead to other, more specialised link
relations being created anyway.
So I'm not sure why it's so important we have an effectively semantic-
free "previous" and "next", but if that's what happens, I'm
reasonably confident my use case will still be met.
So, Thomas -- are you still -1 on this? I don't see how we can come
to consensus on a more specific set of relations, given the flood of
+1s on the generic ones.
On 21/10/2005, at 2:23 PM, Thomas Broyer wrote:
James Holderness wrote:
Thomas Broyer wrote:
You didn't answer my last question:
How do you expect a newsreader to *automatically* download this
week's 50 entries without downloading last week's entries instead?
(and show you links/buttons for you to ask download and display
of previous/next week's Top 50)
I see where you're coming from, but this kind of thing is already
a problem without even taking links into consideration.
For an aggregator to be able to do anything vaguely meaningful
with a feed it has to be able to assume that the feed is
incremental in nature.
As I already explained, paging is orthogonal to the incremental
nature of a feed. An incremental feed will be chunked as explained
in Mark's current Feed History draft (just use an atom:link
[EMAIL PROTECTED]"previous"] instead of the fh:prev extension element) and a
non-incremental feed as described in the OpenSearch result 1.1
draft. The difference is that an incremental feed is sorted by date
so the older parts will become more or less "stable" over time;
while a non-incremental feed is replaced as a whole each time it is
updated, with no other relation to time.
When the feed is updated an aggregator will by default assume that
any new items can safely be added to the top of an inbox, any
updates are updates to existing items, and any removed items have
merely "fallen off the bottom" of the feed.
However, as soon as we introduce the concept of non-incremental
feeds, an aggregator that is not aware of the concept will fail to
process such a feed in a meaningful way. We've created a situation
where an aggregator has to be aware of the (still to be specified)
fh:incremental extension, Microsoft's simple list extensions for
RSS, and whatever future extensions may arise; basically the
ability to see into the future.
This problem merely repeats itself when it comes to processing
archives. When we receive a "next" link, ideally we would like to
assume it's a pointer to the next archive to be processed. For a
regular incremental feed this isn't a problem. Even a search feed
could be processed safely if ordered the right way. However, when
it comes to non-incremental feeds we're screwed again. I agree
that it sucks, but we're already stuck with that situation so I'm
not sure that these links will make things any worse.
What's the difference between a search feed and a non-incremental
feed? Aren't search feeds one facet of non-incremental feeds?
The difference between incremental and non-incremental feeds is
that, when dealing with incremental feeds, paging can be seen as a
link to archives, as the feed is tightly related to time. When
dealing with non-incremental feed, the "previous page" is totally
different than the "previous archived snapshot".
However, an incremental feed could take advantage of
differentiating between paging and "archive linking": if linking to
archives uses an atom:[EMAIL PROTECTED]"archives"] (or call it "history"
if you prefer) to point at an incremental feed where each entry
describes an archived set of entries (see [1] for a more detailed
example); such a feed has the advantage of paging that it allows
direct access to a specific point of time inside the feed "pages".
Each "archived set of entries" could for example cover one or two
week, so a user could navigate through the "feed state" or "feed
history" not only by going from pages to pages but also by
accessing archived chunks via an "index" or "table of contents".
--
Thomas Broyer
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
--
Mark Nottingham http://www.mnot.net/
