Sorry I did not participate in the previous discussion for format 00.
I only just
realized this was going on. What is clear is that this is really needed!
I agree with Stefan Eissing's random thought that it may not be a
good idea to use
Atom for a "top 10" feed. Atom entries are not ordered in a feed for
one. Also as I
understand it an entry in a feed is best thought of as a state of an
external resource
at a time. Making a feed of the top x entries is to use the feed as a
closed collection
whereas I think it is correctly interpreted as an open one.
If that is right, and so fh:stateful is not needed, then would it not
be simpler to
extend the link element in the following really simple way:
<link rel="http://purl.org/syndication/history/1.0"; type="application/
atom+xml"
href="http://example.org/2003/11/index.atom"; />
Just a thought.
In any case I really look forward to having this functionality.
Thanks a lot for the
huge effort you have put into presenting this idea so clearly and
with such patience.
Henry Story
On 18 Jul 2005, at 09:59, Stefan Eissing wrote:
Am 16.07.2005 um 17:57 schrieb Mark Nottingham:
The Feed History draft has been updated to -02;
http://ftp.ietf.org/internet-drafts/draft-nottingham-atompub-
feed-history-02.txt
The most noticeable change in this version is the inclusion of a
namespace URI, to allow implementation.
I don't intend to update it for a while, so as to gather
implementation feedback.
Just a couple of thoughts on reading the document:
Ch 3. fh:stateful seems to be only needed for a newborn stateful
feed. As an alternative one could drop fh:stateful and define that
an empty fh:prev (refering to itself) is the last document in a
stateful feed. That would eliminate the cases of wrong mixes of
fh:stateful and fh:prev.
Ch 5. inserting pseudo-entries into an incomplete feed: would it
make sense to have a general way to indicate such pseudo entries? A
feed entry can also get lost at the publisher and the publisher
might want to indicate that there once was a feed entry, but that
he no longer has the (complete) document.
//Stefan
Random thoughts:
The example of a "top 10" feed (Ch 1) needs some thinking: there
are quite some people interested in the history of "top 10" when it
comes to music charts. One _could_ make this an atom feed and use
the feed history to go back in time. But the underlying model is
different from the one atom has, so maybe its not such a good idea
after all. (Is there any ordering in a feed, btw.? I know a client
can sort by date, but does someone rely on document order of xml
elements?)
