On Oct 17, 2005, at 10:17 PM, James M Snell wrote:
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.
I don't think I expressed the point I wanted to make quite clearly
enough, so let me try again.
Chains of Feed documents are going to be ordered in some way, whether
it's specified or not, whether they explicitly indicate it or not.
For example, the chain of Feed documents representing an incremental
feed is going to naturally be in temporal order. You're not going to
be tacking on new entries willy nilly to whichever of the documents
in the chain fits your fancy at the moment. You're going to create a
new document when the one you were most recently adding entries to
gets "full", and then your going to add entries there till that one
is "full", and so on. There may be exceptions, but by and large,
whether the temporal order is explicit or not, that's what's going to
happen.
Chains of pages of search results feeds are going to naturally be
ordered with the best matches "on top".
The point I was trying to make was that you're not going to create
all the documents without links between then and then randomly assign
links between them in no specific order. You're going to link
between then in an order that makes sense within the context of how
the feed was created.
I don't know how client applications are going to adapt to deal with
the difference between incremental feeds and, for example, search
results feeds, but I can't imagine that client software isn't going
to rely on there being some sort of sense to the order of the Feed
documents.
What I was trying to say further down with the example spec text I
wrote was, let's state explicitly that this link relation does not
have a temporal semantic, and if somebody want's a link relation with
a temporal semantic, they should create another link/@rel value for it.
In other words...
In other words,
this does not imply a feed history thing...
...let's have this be a link for navigating among the pages of the
current state of the feed (whether it be incremental or not--noting
that some non-incremental feeds will only have one page, and won't
need it). The entries in the current state of the feed are not in
any specific order (though we know that naturally they will be in
some sort of order):
<feed>
...
<link rel="next" href="..." />
</feed>
How does the following have anything to do with history? In an
incremental feed, all of the entries, whether part of the Feed
document at the subscription end or not, are part of the present
state of the feed--they don't just exist back in history. History is
for non-incremental feeds. I'm saying let's not work on navigation
through history right now, but let's recognize that unless we say not
to, people might try to use the mechanism designed for paging through
the current state of a feed to navigate through the history of a feed
too, so let's say not to. I understand (or at least suppose) that
you don't think we need to say not to, because you don't see the harm
in making the link relation more generic. I disagree. I think we're
going to end up with a mess if we don't make it specifically for
navigating the current state.
this does...
<feed>
...
<fh:incremental>true</fh:incremental>
<link rel="next" href="..." />
</feed>
