This leads to:
Subscription feed:
- can contain link/@rel="prev", OR
- can contain fh:incremental = "false"
Archive feed:
- can contain link/@rel="prev" and/or link/@rel="next"
- can contain link/@rel="subscribe" (effectively gives you "last")
- link/@rel="subscribe" has a semantic of "if you want to
subscribe to this feed, use the linked document, not this one."
The reconstruction algorithm is pretty much the same as in -04.
The only dangling point is "first." I'm not especially against it,
but what's the use case?
On 14/10/2005, at 4:53 PM, Mark Nottingham wrote:
Right. A few questions that pop up:
1) Is it a closed or open set? If it's open (and I think 99% of
feeds are), what does "last" mean?
My answer is that it's probably an open set, so "last" doesn't mean
much that's useful (unless it's conflated with the subscription
feed; see below).
2) What's the relationship between these feed documents and the
feed document that people subscribe to?
I think the subscription feed needs to be pinned to one end of the
set (which is what FH does now). Otherwise, it becomes difficult to
figure out whether you have the complete set or not by polling.
On 14/10/2005, at 3:16 PM, James M Snell wrote:
The way I look at this is in terms of a single linked list of
feeds. The ordering of the entries within those feeds is
irrelevant. The individual linked feeds MAY be incremental (e.g.
blog entries,etc) or may be complete (e.g. lists,etc). Simply
because a feeds are linked, no assumption should be made as to
whether or not the entries in those feeds share any form of
ordered relationship.
<link rel="first" /> is the first feed in the linked list
<link rel="next" /> is the next feed in the linked list
<link rel="previous" /> is the previous feed in the linked list
<link rel="last" /> is the last feed in the linked list.
Terms like "top", "bottom", "up", "down", etc are meaningless in
this model as they imply an ordering of the contents.
For feed history, it would work something like:
<feed>
...
<link rel="self" href="...feed1" />
<link rel="next" href="...next" />
<link rel="last" href="...feed3" />
...
</feed>
<feed>
...
<link rel="self" href="...feed2" />
<link rel="previous" href="...feed1" />
<link rel="next" href="...feed3" />
<link rel="first" href="...feed1" />
<link rel="last" href="...feed3" />
...
</feed>
<feed>
...
<link rel="self="href="...feed3" />
<link rel="previous" href="...feed2" />
<link rel="first" href="...feed1" />
...
</feed>
- James
Mark Nottingham wrote:
At first I really liked this proposal, but I think that the kind
of confusion you're concerned about is unavoidable; the terms
you refer to suffer "bottom-up" vs. "top-down."
I think that defining the terms well and in relation to the
subscription feed will help; after all, the terms don't surface
in UIs, so it should be transparent.
On 14/10/2005, at 10:37 AM, Antone Roundy wrote:
Which brings me back to "top", "bottom", "up" and "down". In
the OpenSearch case, it's clear which end the "top" results are
going to be found. In the syndication feed case, the
convention is to put the most recent entries at the "top". If
you think of a feed as a stack, new entries are stacked on
"top". The fact that these terms are less generic and flexible
than "previous" and "next" is both an advantage and a
disadvantage. I think the question is whether it's an
advantage in a significant majority of cases or not. What
orderings would those terms not work well for?
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
____________________________________________________________________
____________
BEAWorld 2005: coming to a city near you. Everything you need
for SOA and enterprise infrastructure success.
Register now at http://www.bea.com/4beaworld
London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26
Oct| Beijing 7-8 Dec
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems