On Oct 17, 2005, at 11:06 AM, Byrne Reese wrote:
5. Is the issue of whether a feed is incremental or not (the
fh:incremental
element) relevant to this proposal?
non-incremental feeds wouldn't be paged, by definition, would they?
Why not? Why wouldn't I have a "Top 100 DVDs of All Time" broken out
into 10 feeds of 10 entries each?
Although one could say that the presence of 'next' and 'prev' links
indicate that the feed is incremental, and the absence of those links
indicates the feed is complete.
Ugh! This suggests yet another feed model. First, what we've
already got:
1) Incremental feed document: a feed document that contains a subset
of the entries that are currently in the feed (resource), where new
entries are added to the feed without replacing old entries.
2) Non-incrememental feed document: a feed document which contains
representations of every entry which is currently part of the feed,
where new entries replace old entries.
and then...
3) ??? feed document: a feed document which contains representations
of a subset of the entries that are currently in the feed (resource),
where new entries replace old entries.
Linking up #3 documents to show a history of the feed will be even
more complicated than what we've been discussing. Do we need such a
beast? I wish I could unequivocally say "no", but I'm forced to
equivocate: are not search result feeds #3? It seems that indeed we
need two separate mechanisms--a paging mechanism and a history
mechanism. Unless both are going to go into the same extension, the
extensions should be explicit about the the fact that they describe
one and not the other. And we should choose link/@rel names
carefully so that one doesn't end up using names better suited fore
the other.
