Here's another thought. Thus far, we've talked about
next/previous/first/last links appearing on the atom:feed element...
used as a means of linking Atom Feed Documents together. These same
link relations could be used on atom:entry as well.... used as a way of
creating a linked list of Atom Entry Documents.
<entry>
<id>tag:example.com,2005:/1</id>
<link rel="next"
href="http://www.example.com/entries/2.entry";
type="application/atom+xml" />
<link rel="previous"
href="http://www.example.com/entries/0.entry";
type="application/atom+xml" />
</entry>
The challenge comes when you want to link to entries that are contained
within a feed, in which case, we could use xml:id
<feed>
...
<entry xml:id="1">
<id>tag:example.com,2005:/1</id>
<link rel="next"
href="#2"
type="application/atom+xml" />
</entry>
<entry xml:id="2">
<id>tag:example.com,2005:/1</id>
<link rel="previous"
href="#1"
type="application/atom+xml" />
</entry>
</feed>
Again, this is just used to build a simple linked-list of entries and
does not imply any semantic order (e.g. order by date, order by
significance, etc).
the key challenge with this is that while I can definitely see how it
would work, I'm having a hard time envisioning a use case for this.
- James
Henry Story wrote:
I am ok with next, prev, ... but I suppose I do have a question that
is similar to Marks: how do I know in what order the results are
listed? Are they in historical order? Are these feeds grouping entries
in alphabetical order, in inverse historical order? Perhaps in
alphabetical order of author,...
Again next, prev, first, last deal very well with paging. how do we
specify the order? Is this related to the query? Should there be a
default order for subscription feeds? Should the ordering information
be specified in the feed?
In rdf we could say things like
iana:historicalNext a owl:ObjectProperty;
rdfs:subPropertyOf iana:next;
rdfs:comment "a historically ordered next relation" .
and then use historicalNext for the particular historical ordering
that we need to archive our feeds. This would allow processors who do
not understand or care about the historical ordering to still walk
through the linked list of feeds.
Henry
Ps. writing from Italy
http://dannyayers.com/archives/2005/10/15/welcome-to-the-atomowl/
On Sat, 15 Oct 2005, Mark Nottingham wrote:
Date: Sat, 15 Oct 2005 20:45:35 -0700
From: Mark Nottingham <[EMAIL PROTECTED]>
To: Eric Scheid <[EMAIL PROTECTED]>
Cc: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Feed History -04
OK, but that still leaves us with the question below -- who's doing
the paging, and why is it useful to have multiple ways around the thing?
On 15/10/2005, at 7:25 PM, Eric Scheid wrote:
On 16/10/05 6:54 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote:
Can you walk me through a use case where this would be desirable?
E.g. what would the subscription URI be, would any of the entries
be updated, and how if so? In what scenario would having a closed
set feed be useful?
An archive for a blog that is no longer being updated? An archive
of entries pertaining to an event with a fixed endpoint? A
discussion forum that has been closed.
How are implementations supposed to use this information? Stop
polling the feed? Consider its items immutable? I'm concerned if
something so innocent-looking as "last" has these sorts of
implications.
perhaps a better example would then be a feed of search results,
which at
any time of query is a finite and closed set, and also designed to
be paged
through.
e.
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
