Subject: RE: Feed History -04

From: "Lindsley Brett-ABL001" <[email-masked]>
Date: Fri, 14 Oct 2005 12:22:26 -0400

I have a suggestion that may work. The issue of defining what is "prev"
and "next" with respect to a time ordered sequence seems to be a
problem. How about defining the link relationships in terms of time -
such as "newer" and "older" or something like that. That way, the
collection returned should be either "newer" (more recent updated time)
or "older" (later updated time) with respect to the current collection
doc.

Brett Lindsley, Motorola Labs

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of James Holderness
Sent: Friday, October 14, 2005 11:09 AM
To: Mark Nottingham; Antone Roundy
Cc: [email-masked]
Subject: Re: Feed History -04

Mark Nottingham wrote:
> The approach I took in -04 was to say that the pseudo-ordering
introduced 
> by the mechanism was ONLY meaningful for the purposes of
reconstituting 
> the feed; it's still up to the feed itself to  determine what the
ordering 
> of entries means (or doesn't). That  avoids a lot of problems,
although it 
> does require some careful wording.

The ordering of the entries may not matter, but the ordering of the 
documents does. Starting with the active feed document, you need to know

whether you should be following a series of "prev" links or "next" links
in 
order to traverse the archives back through time. While your feed
history 
spec used "prev" for that purpose, previous implementations of atom:link

appear to have used "next".

I can see the justification for both choices and don't particularly mind

either way. However if the final decision is to go with "prev" rather
than 
"next" I think there should at least be a note to the effect that there
may 
be existing implementations of Atom 0.3 using "next".

> Also -- I'd think that the "last" link is already covered by "self,"
no? 
> If not, there's some pretty serious confusion about what 'self'
means.

I was going to suggest that initially but I don't think it's strictly
true. 
The spec says that "self" identifies a resource *equivalent* to the 
containing element. Considering that an archived document and the active

feed document will quite likely have no entries in common I think it's a
bit 
of a stretch to claim them equivalent. "Derived" would be a better 
relationship IMHO.

Not that I care, mind you. Just pointing out that such a usage may
conflict 
somewhat with the spec.

Regards
James

---

From: Thomas Broyer <[email-masked]>
Date: Fri, 14 Oct 2005 18:39:18 +0200

> or "older" (later updated time) with respect to the current collection
Wouldn't it be "better" to share the same link relations between feeds 
sorted by date/time or some other "priority" (e.g. OpenSearch results)?

-- 
Thomas Broyer

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 14 Oct 2005 10:13:35 -0700

On 14/10/2005, at 9:22 AM, Lindsley Brett-ABL001 wrote:
> I have a suggestion that may work. The issue of defining what is  
> "prev" and "next" with respect to a time ordered sequence seems to  
> be a problem. How about defining the link relationships in terms of  
> time - such as "newer" and "older" or something like that. That  
> way, the collection returned should be either "newer" (more recent  
> updated time) or "older" (later updated time) with respect to the  
> current collection doc.

A feed isn't necessarily a time-ordered sequence. Even a feed  
reconstructed using fh:prev (or a similar mechanism) could have its  
constituent parts generated on the fly, e.g., in response to a search  
query.

> documents does. Starting with the active feed document, you need to  
> know whether you should be following a series of "prev" links or  
> "next" links in order to traverse the archives back through time.  
> While your feed history spec used "prev" for that purpose, previous  
> implementations of atom:link appear to have used "next".

I agree that it's important to honour the document order; that's what  
FH tries to do. I'm a little surprised to hear you say that people  
thought that this was previously 'next'; I'd never heard that (but  
will be happy to put a note in).

> I was going to suggest that initially but I don't think it's  
> strictly true. The spec says that "self" identifies a resource  
> *equivalent* to the containing element. Considering that an  
> archived document and the active feed document will quite likely  
> have no entries in common I think it's a bit of a stretch to claim  
> them equivalent. "Derived" would be a better relationship IMHO.

Hmm. Yeah, I see what you're saying. Actually, I think this is an  
opportunity -- we we define a new link relation to the subscription  
document, and specify that it can only occur in archive documents, it  
obviates the need for a separate fh:archive flag, which in turn means  
that you don't have to declare two namespaces to use fh in RSS  
archive documents -- which was one of the things making me reluctant  
to switch over to atom:link.

How about:

<atom:link rel="subscription" href="..."/>

?

--
Mark Nottingham     http://www.mnot.net/

---

From: Thomas Broyer <[email-masked]>
Date: Fri, 14 Oct 2005 19:28:22 +0200

> <atom:link rel="subscription" href="..."/>
I always thought this was the role of @rel="self" to give the URI you 
should subscribe to, though re-reading the -11 it deals with "a resource 
equivalent to the containing element".

1. Isn't "a resource equivalent to the containing element" the same as 
"an alternate version of the resource described by the containing element"?
2. Is the answer to 1. is no then what does "a resource equivalent …" 
mean? Is it really different than "the URI you should subscribe to" (at 
least if @type="application/atom+xml")?

-- 
Thomas Broyer

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 14 Oct 2005 10:35:56 -0700

That's what I thought too, but the words in the spec don't bear it  
out; a "resource equivalent to the containing element" is a little  
hard to interpret (there is no equivalence function for Web  
resources, by definition), but it's a lot closer to "something you  
dereference to get the same thing as what's in the containing  
element" than to "something you dereference to get a potentially  
completely different thing."

Arguably, there is sometimes a use case for the current definition of  
"self", so it's probably best to just define a new link relation.

On 14/10/2005, at 10:28 AM, Thomas Broyer wrote:

> I always thought this was the role of @rel="self" to give the URI  
> you should subscribe to, though re-reading the -11 it deals with "a  
> resource equivalent to the containing element".
>
> 1. Isn't "a resource equivalent to the containing element" the same  
> as "an alternate version of the resource described by the  
> containing element"?
> 2. Is the answer to 1. is no then what does "a resource equivalent  
> …" mean? Is it really different than "the URI you should subscribe  
> to" (at least if @type="application/atom+xml")?
>
> -- 
> Thomas Broyer

---

From: Antone Roundy <[email-masked]>
Date: Fri, 14 Oct 2005 11:37:44 -0600

On Oct 14, 2005, at 11:13 AM, Mark Nottingham wrote:
>> be a problem. How about defining the link relationships in terms  
>> of time - such as "newer" and "older" or something like that. That  
> constituent parts generated on the fly, e.g., in response to a  
> search query.
>
The OpenSearch case mentioned by Thomas is what convinced me that  
terms related to temporal ordering aren't appropriate (what a pity,  
since "newer" and "older" are the perfect terms for time ordered  
sequences of feed documents!)

"Previous" and "next" suffer from the fact that they could easily be  
interpreted differently in different use cases. For example, for  
OpenSearch results "pages", clearly "prev" points to the search  
results that come up "on top" and "next" to the lower results. But in  
a conventional syndication feed, "next" could easily be taken to mean  
either "the next batch of entries as you track back towards the  
beginning of time from where you started (which is usually going to  
be the growing end of the feed)", or "a batch of entries containing  
the entries that were published next after the ones in this batch."   
I'd have to look at the document to remind myself of which "next"  
means, because either makes just as much sense to me.

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?

Antone

---

From: Antone Roundy <[email-masked]>
Date: Fri, 14 Oct 2005 11:52:51 -0600

> resource equivalent to the containing element".
That's what some of us wanted it to be and thought it was intended to  
be.  The language that made it into the spec certainly falls short of  
expressing what was in PaceFeedLink, which is the proposal that added  
@rel="self" [1].

> as "an alternate version of the resource described by the  
That's how I would read that language knowing nothing of the history  
of that part of the spec.  I think some people intended "equivalent"  
to mean "it may not be a different copy of the same bits, but  
whatever it is, it contains the same bits" (or at least the same code  
points, if it happens to be transcoded).

> to" (at least if @type="application/atom+xml")?
I think what some people want that to mean is "here's a place you  
could get the feed, but I'm not making any assertions regarding  
whether it's preferable to get it from there or somewhere else."

[1] http://www.imc.org/atom-syntax/mail-archive/msg15062.html

---

From: "James Holderness" <[email-masked]>
Date: Fri, 14 Oct 2005 19:00:44 +0100

Mark Nottingham wrote:
> I agree that it's important to honour the document order; that's what  FH 
> tries to do. I'm a little surprised to hear you say that people  thought 
> that this was previously 'next'; I'd never heard that (but  will be happy 
> to put a note in).

Mark Pilgrim's article on XML.com discussing the Atom Link Model:
http://www.xml.com/pub/a/2004/06/16/dive.html

I can't say I've seen it widely used, but there is at least one occurrence 
in the wild (Mark's archives).

> that you don't have to declare two namespaces to use fh in RSS  archive 
> documents -- which was one of the things making me reluctant  to switch 
> over to atom:link.
>
> How about:
>

Yeah, I think that's a great idea. I'm not sure about the name though. Would 
it not be better as a verb (say "subscribe") since the link is effectively 
providing you with a url with which you can subscribe to the feed. This 
seems to me more in line with the verb-based link relations being used in 
the Atom publishing protocol.

Admittedly in this case the link could just as easily be interpreted as a 
passive pointer to a document rather than an operation as such. I'm not 
really arguing strongly either way. Just something to think about.

Regards
James

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 14 Oct 2005 11:27:34 -0700

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:

> 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

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 14 Oct 2005 20:55:46 +0200

Am 14.10.2005 um 20:00 schrieb James Holderness:
> Yeah, I think that's a great idea. I'm not sure about the name though. 
> Would it not be better as a verb (say "subscribe") since the link is 
> effectively providing you with a url with which you can subscribe to 
> the feed. This seems to me more in line with the verb-based link 
> relations being used in the Atom publishing protocol.
>
> Admittedly in this case the link could just as easily be interpreted 
> as a passive pointer to a document rather than an operation as such. 
> I'm not really arguing strongly either way. Just something to think 
> about.

The idea is excellent. As for the naming sugar of the relation "head", 
"anchor" or "origin" could work also.

//Stefan

---

From: Joe Gregorio <[email-masked]>
Date: Fri, 14 Oct 2005 16:40:00 -0400

> means, because either makes just as much sense to me.

True, but I don't think that means that the terms have to be
abandoned, but that these examples need to be supported by spec text.
That is, define 'next' as pointing to the next document in a series
of documents, the whole series of documents containing
a series of Atom Entries whose order is specific to the service
providing it.

   -joe

--
Joe Gregorio        http://bitworking.org

---

From: James M Snell <[email-masked]>
Date: Fri, 14 Oct 2005 15:16:11 -0700

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:

>> 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?
>
>
>
> --

---

From: Henry Story <[email-masked]>
Date: Fri, 14 Oct 2005 15:28:27 -0700 (PDT)

This looks good.

Is the 'first' the feed document that changes, whereas 'next' and 'last' 
point to the archives? (in a feed history context?)

Henry

On Fri, 14 Oct 2005, 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.
>

+1

> Terms like "top", "bottom", "up", "down", etc are meaningless in this model 
> as they imply an ordering of the contents.
>
>> 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.
>> 
>> 
>>> 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?
>> 
>> 
>> 
>> --

---

From: Robert Sayre <[email-masked]>
Date: Fri, 14 Oct 2005 18:34:36 -0400

> The way I look at this is in terms of a single linked list of feeds.

James is 100% right. Think of any feed as a google search result,
ordered in terms of relevance. On your average blog, the newest post
is always the most relevant :). I would support mnot's draft moving
onto the standards track if it followed the linking scheme outlined by
James. The "RSS way" of doing it could be kept alongside, if that's
politically necessary. If Mark opts not to support atom:link, my
support changes to silence, and I will go right ahead and implement
the three link relations I need in my Atom implementations: next,
prev, and profile.

Robert Sayre

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 15 Oct 2005 01:35:32 +0200

* James M Snell <[email-masked]> [2005-10-15 00:25]:
> Terms like "top", "bottom", "up", "down", etc are meaningless
> in this model as they imply an ordering of the contents.

head/tail?

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: James M Snell <[email-masked]>
Date: Fri, 14 Oct 2005 16:40:41 -0700

What in the world is wrong with first and last? ;-)  I just don't get it.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 14 Oct 2005 16:53:00 -0700

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.
>
> Terms like "top", "bottom", "up", "down", etc are meaningless in  
> this model as they imply an ordering of the contents.
>
>> 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."
>>
>> subscription feed will help; after all, the terms don't surface  
>> in  UIs, so it should be transparent.
>>
>>
>>> 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?
>>>
>>
>>
>>
>> -- 
>> BEAWorld 2005: coming to a city near you.  Everything you need for  
>> SOA and enterprise infrastructure success.
>>
>>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 14 Oct 2005 18:23:47 -0700

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:

> 1) Is it a closed or open set? If it's open (and I think 99% of  
> feeds are), what does "last" 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?
>
>> whether or not the entries in those feeds share any form of  
>> ordered relationship.
>>
>>> of  confusion you're concerned about is unavoidable; the terms  
>>> you refer  to suffer "bottom-up" vs. "top-down."
>>>
>>>> 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  
>>> BEAWorld 2005: coming to a city near you.  Everything you need  
>>> for SOA and enterprise infrastructure success.
>>>
>>>

---

From: "James Holderness" <[email-masked]>
Date: Sat, 15 Oct 2005 04:01:41 +0100

>   - can contain fh:incremental = "false"

I never did understand this. Why is fh:incremental needed here? From a feed 
history point of view you either have a history (a prev link is present) or 
you don't. That's all an Atom processor needs in order to reconstruct the 
feed.

I get that a feed producer may want to provide a non-incremental feed (top 
10, todo lists, playlists, etc), but I don't see what that has to do with 
feed history. Wouldn't that be better suited in a separate extension along 
with whatever other meta-information might be appropriate for 
non-incremental lists?

>   - link/@rel="subscribe" has a semantic of "if you want to  subscribe to 
> this feed, use the linked document, not this one."
>
> The only dangling point is "first." I'm not especially against it,  but 
> what's the use case?

I'm not especially for it, but it's theoretically possible that someone 
subscribing to a feed for the first time may want to download the full 
archives. Depending on their processing model, this may be more convenient 
starting with the oldest archive and working forwards in time

Regards
James

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 14 Oct 2005 20:15:18 -0700

On 14/10/2005, at 8:01 PM, James Holderness wrote:

> I never did understand this. Why is fh:incremental needed here?  
> From a feed history point of view you either have a history (a prev  
> link is present) or you don't. That's all an Atom processor needs  
> in order to reconstruct the feed.
>
> I get that a feed producer may want to provide a non-incremental  
> feed (top 10, todo lists, playlists, etc), but I don't see what  
> that has to do with feed history. Wouldn't that be better suited in  
> a separate extension along with whatever other meta-information  
> might be appropriate for non-incremental lists?

It's more relevant than it seems at first glance. Currently, most (if  
not practically all) feed aggregators will keep a history by default,  
without information otherwise. Introducing a standard extension to  
enable that necessitates that there be a way to say "don't do that."

>> The only dangling point is "first." I'm not especially against  
>> it,  but what's the use case?
>
> I'm not especially for it, but it's theoretically possible that  
> someone subscribing to a feed for the first time may want to  
> download the full archives. Depending on their processing model,  
> this may be more convenient starting with the oldest archive and  
> working forwards in time

Yeah, that's pretty much where I'm at; supplying effectively gives  
*two* ways to reconstruct the state of a feed, meaning that both  
would need to be supported (and optimised) by implementations, which  
isn't so great unless there's a compelling need for it.

---

From: James M Snell <[email-masked]>
Date: Fri, 14 Oct 2005 20:32:24 -0700

> much that's useful (unless it's conflated with the subscription feed;  
My answer would be: if "last" is used, it's a closed set; if "last" is 
not used, it's an open set.

> figure out whether you have the complete set or not by polling.
I think this will be dependent on the context in which the link rels are 
used.  The "subscription" link rel you've suggested is a good solution 
to this problem.  Within any of the feeds in the set, the "subscription" 
link rel would point to the feed that should be subscribed to -- 
regardless of whether the subscription feed appears at the start or end 
of the set.

>>>> 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

---

From: James M Snell <[email-masked]>
Date: Fri, 14 Oct 2005 20:35:18 -0700

Mark Nottingham wrote:

>   - link/@rel="subscribe" has a semantic of "if you want to  subscribe 
> to this feed, use the linked document, not this one."
>
The "first" may not be relevant in the Feed history case but does come 
into play when thinking about paged search results, sequences of linked, 
non-incremental feeds, etc.

- James

---

From: Eric Scheid <[email-masked]>
Date: Sat, 15 Oct 2005 14:25:49 +1000

> point to the archives? (in a feed history context?)

My thinking is that of the two ends, 'first' and 'last', it would normally
be the 'first' end that is anchored, while the 'last' end would shift as
more is added.

e.

---

From: Eric Scheid <[email-masked]>
Date: Sat, 15 Oct 2005 14:51:01 +1000

> not used, it's an open set.

+1 ... if it's an open set and you've put 'last' links into every archive,
then every time you extend the set you have to rewrite all the previous
archives to update the 'last' link. This would not only be a pain for the
publishers, but also any consumers.

+1 to 'subscribe' over 'subscription', by the way.

e.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 14 Oct 2005 21:54:04 -0700

On 14/10/2005, at 8:32 PM, James M Snell wrote:
> My answer would be: if "last" is used, it's a closed set; if "last"  
> is not used, it's an open set.

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?

Separately, you say:
> The "first" may not be relevant in the Feed history case but does  
> come into play when thinking about paged search results, sequences  
> of linked, non-incremental feeds, etc.

How? Can you give us a bit more flesh for the use case? Again, I'm  
not saying it's bad, but I don't see how it's useful in a feed (as  
opposed to a Web page).

>> 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.
>>
> I think this will be dependent on the context in which the link  
> rels are used.  The "subscription" link rel you've suggested is a  
> good solution to this problem.  Within any of the feeds in the set,  
> the "subscription" link rel would point to the feed that should be  
> subscribed to -- regardless of whether the subscription feed  
> appears at the start or end of the set.

What would the algorithm be for assuring that you have the complete  
state of the feed, without necessitating traversal of the entire feed  
every time?

Cheers,

---

From: James M Snell <[email-masked]>
Date: Fri, 14 Oct 2005 22:24:39 -0700

> updated, and how if so? In what scenario would having a closed set  
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.

> not saying it's bad, but I don't see how it's useful in a feed (as  
Suppose that I perform a search on some feed searching service and get 
back an entry from a feed in the middle of a set.  I see the next and 
previous links and realize that the entry I found is part of a larger 
set.  In order to get the full context, I want to navigate to the 
beginning of the set and work my way down through the links to the end. 

>>> set (which is what FH does now). Otherwise, it becomes  difficult 
>>> to  figure out whether you have the complete set or not  by polling.
>>>
>> I think this will be dependent on the context in which the link  rels 
>> are used.  The "subscription" link rel you've suggested is a  good 
>> solution to this problem.  Within any of the feeds in the set,  the 
>> "subscription" link rel would point to the feed that should be  
>> subscribed to -- regardless of whether the subscription feed  appears 
>> at the start or end of the set.
>
>
Not sure. I suppose that it would be the same as it is with your 
existing fh:prev element.

- James

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 15 Oct 2005 13:54:00 -0700

On 14/10/2005, at 10:24 PM, James M Snell wrote:
>>> My answer would be: if "last" is used, it's a closed set; if  
>>> "last"  is not used, it's an open set.
>>
>> 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.

>>> The "first" may not be relevant in the Feed history case but  
>>> does  come into play when thinking about paged search results,  
>>> sequences  of linked, non-incremental feeds, etc.
>>
>> How? Can you give us a bit more flesh for the use case? Again,  
>> I'm  not saying it's bad, but I don't see how it's useful in a  
>> feed (as  opposed to a Web page).
>>
> Suppose that I perform a search on some feed searching service and  
> get back an entry from a feed in the middle of a set.  I see the  
> next and previous links and realize that the entry I found is part  
> of a larger set.  In order to get the full context, I want to  
> navigate to the beginning of the set and work my way down through  
> the links to the end.

You seem to have a human in mind for your use case, when these  
relations are just there to allow machines to reconstruct the feed.  
In other words, the ordering used for presentation to people is  
logically separate from the ordering of feed documents (although the  
reconstructed, native feed ordering may be used). As such, your use  
case could be met without specifying 'first'; just follow the normal  
walk-back-from-the-subscription-feed method to reconstruct state.

>>>> difficult to  figure out whether you have the complete set or  
>>>> not  by polling.
>>>>
>>> rels are used.  The "subscription" link rel you've suggested is  
>>> a  good solution to this problem.  Within any of the feeds in the  
>>> set,  the "subscription" link rel would point to the feed that  
>>> should be  subscribed to -- regardless of whether the  
>>> subscription feed  appears at the start or end of the set.
>>
>> What would the algorithm be for assuring that you have the  
>> complete  state of the feed, without necessitating traversal of  
>> the entire feed  every time?
>>

It would have to be modified to specify the rules for walking forward  
from the first document, and then subsequent updates would need to be  
caught by working backwards from the subscription document using "prev."

My current take is that "last" is actively harmful if it implies a  
closed set, and misleading if it doesn't, and "next" and "first" are  
mostly harmless, but don't really have supporting use cases and add  
complexity to both the spec and implementations. I'd really like to  
keep it simple. Are there any other use cases?

---

From: Eric Scheid <[email-masked]>
Date: Sun, 16 Oct 2005 12:25:39 +1000

> 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.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 15 Oct 2005 20:45:35 -0700

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?

---

From: Robert Sayre <[email-masked]>
Date: Sun, 16 Oct 2005 00:59:44 -0400

> the paging, and why is it useful to have multiple ways around the thing?

James is 100% wrong :)... about
last/first/top/head/bottom/hole-in-the-ground. There's no reason to
specify these things in Mark's draft. If they prove useful in
implementations, they can be layered on the existing specs.

Mark has his next/prev turned around, IMHO. link rel=next should go
deeper into the past. Think of how you would write a SQL query with a
limit clause.

Robert Sayre

---

From: Henry Story <[email-masked]>
Date: Sun, 16 Oct 2005 02:54:46 -0700 (PDT)

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-masked]>
> To: Eric Scheid <[email-masked]>
> Cc: Atom Syntax <[email-masked]>
> 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?
>
>

---

From: Henry Story <[email-masked]>
Date: Sun, 16 Oct 2005 01:41:56 -0700 (PDT)

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?

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

---

From: James M Snell <[email-masked]>
Date: Sun, 16 Oct 2005 14:05:13 -0700

Henry Story wrote:

> are listed? Are they in historical order? Are these feeds grouping 
> entries in alphabetical order, in inverse historical order? Perhaps in 
Ordering of the entries is orthogonal to the paging of the feeds. Some 
other means of specifying the order of entries would be used (e.g. feed 
rank or whatever else)

> subscription feeds? Should the ordering information be specified in the
Take a look at my feed rank proposal and let me know what you think.

- James

---

From: James M Snell <[email-masked]>
Date: Sun, 16 Oct 2005 16:44:20 -0700

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 
> 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?
>
> 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

---

From: "James Holderness" <[email-masked]>
Date: Mon, 17 Oct 2005 08:09:44 +0100

> 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 

Interesting thought, but if it doesn't have anything to do with feed 
history, would it not be best to set it aside for later and concentrate on 
getting the history spec out the door? The issues I think we still have left 
to resolve are:

1. Which relationship,  next or prev, is used to specify a link backwards in 
time to an older archive. Mark Nottingham's Feed History proposal used prev. 
Mark Pilgrim's XML.com article used next.

2. Are next and prev both needed in the spec if we only require one of them 
to reconstruct the full history?

3. Are the first/last relationships needed?

4. Is the order of the entries in a feed relevant to this proposal?

5. Is the issue of whether a feed is incremental or not (the fh:incremental 
element) relevant to this proposal?

6. What to name the link relation that points to the active feed document? 
subscribe, subscription, self, something else?

My answers would be:

1. I prefer "next" pointing back in time (as per Pilgrim).
2. I would make the one that points back in time MUST, and the one the 
points forwards in time MAY.
3. No to both.
4. No.
5. No.
6. subscribe

Is there anything I've left out?

Regards
James

---

From: Eric Scheid <[email-masked]>
Date: Mon, 17 Oct 2005 18:20:13 +1000

> Mark Pilgrim's XML.com article used next.

I'd prefer that our use of 'prev' and 'next' be consistent with other uses
elsewhere, where 'next' traverses from the current position to the one that
*follows*, whether in time or logical order. Consider the use of
'first/next/prev/last' with chapters or sections rendered in HTML.

> to reconstruct the full history?

Knowing that the most recently published archive won't likely remain the
most recently published archive, there will be use cases where it's better
to reconstruct the full history by starting at the one end which is fixed.
Not much sense starting at the other end which is constandly shifting.

> 3. Are the first/last relationships needed?

See (2) above for 'first'. Meanwhile 'last' could be followed by a user to
jump ahead to the end of the set of archives to see if the butler did it.
Who said 'first/next/prev/last' would only be used by machines?

> 4. Is the order of the entries in a feed relevant to this proposal?

not to this proposal.

> element) relevant to this proposal?

non-incremental feeds wouldn't be paged, by definition, would they?

> subscribe, subscription, self, something else?

'subscribe'

e.

---

From: "James Holderness" <[email-masked]>
Date: Mon, 17 Oct 2005 15:43:31 +0100

> 'first/next/prev/last' with chapters or sections rendered in HTML.

I'm still not exactly sure which of the two options you're in favour of. 
This is the reason why the point is being debated - it's not immediately 
obvious which way is most consistent with usage elsewhere. Nottingham or 
Pilgrim?

> Not much sense starting at the other end which is constandly shifting.

The way I understand it, both sides are fixed as soon as there is at least 
one archive. At the one end you have the oldest archive. At the other end 
you have the current syndication document (to which the end-user would 
subscribe). Both URIs are fixed. The most recent archive will keep changing 
over time, but that is the second item in the list (or second last, 
depending on which direction you prefer to travel).

> non-incremental feeds wouldn't be paged, by definition, would they?

This has been debated. There have been those who have expressed an interest 
in having next and prev links traverse an archive of old non-incremental 
feeds. Say you have a feed with the top 10 books for this month. The next 
link (or prev link, depending on your preference) would point to the archive 
document with the top 10 books from last month.

Personally I think that is an issue that should be argued and subsequently 
specified in a separate proposal on the use of non-incremental feeds. Just 
make sure the history spec is open enough to allow for either possibility 
once it is decided.

Regards
James

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Oct 2005 08:23:05 -0700

> 'first/next/prev/last' with chapters or sections rendered in HTML.

I'm starting to think that the way to fix this is to make it more  
specific, so that it doesn't get conflated with other uses; e.g.,  
"prev-archive".

---

From: Eric Scheid <[email-masked]>
Date: Tue, 18 Oct 2005 01:29:39 +1000

On 18/10/05 12:43 AM, "James Holderness" <[email-masked]> wrote:

> I'm still not exactly sure which of the two options you're in favour of. This
> is the reason why the point is being debated - it's not immediately obvious
> which way is most consistent with usage elsewhere. Nottingham or Pilgrim?
> 

hmmm ... I did say "Consider the use of 'first/next/prev/last' with chapters
or sections rendered in HTML"... Chapter #1 comes first, followed by chapter
#2, and you go from chapter #1 through to chapter #nnn via 'next'.

Think too of Pepys' Diary. What would you consider the 'first' entry? Would
the 'first' entry be 1st January 1660, or would it be 16th October 1662?
Note well though that sometime tomorrow the latter point would be neither
'first' or 'last' because there would be a new entry for the 17th October
1662 (and yet another one the day after).

>> Knowing that the most recently published archive won't likely remain the most
>> recently published archive, there will be use cases where it's better to
>> reconstruct the full history by starting at the one end which is fixed. Not
>> much sense starting at the other end which is constandly shifting.
>> 
> The way I understand it, both sides are fixed as soon as there is at least one
> archive. At the one end you have the oldest archive. At the other end you have
> the current syndication document (to which the end-user would subscribe). Both
> URIs are fixed. 

What I mean by fixed is that it doesn't move or change as the set grows.
Adding one onto the end and resetting where 'last' points to means that
'last' is *not* fixed.

What you mean is that as soon as there is at least one archive then both
ends are *established*. One end is fixed, and the other will grow.

> This has been debated. There have been those who have expressed an interest in
> having next and prev links traverse an archive of old non-incremental feeds.
> Say you have a feed with the top 10 books for this month. The next link (or
> prev link, depending on your preference) would point to the archive document
> with the top 10 books from last month.

That makes sense.

> make sure the history spec is open enough to allow for either possibility once
> it is decided.

I agree. So .. the issue of (not-)incremental is orthogonal to feed history
then.

e.

---

From: Antone Roundy <[email-masked]>
Date: Mon, 17 Oct 2005 10:04:21 -0600

> 'first/next/prev/last' with chapters or sections rendered in HTML.
...so do you follow forward through time or backward?  Is the  
starting "current position" "now" or the "the beginning of time"?   
Especially if we're talking about history, following backward makes  
as much sense as following forward.

I prefer "next" to go back in time (if temporally ordered--from the  
most current chunk to the next most current chunk) or to less  
significant pages (in things like search results).  But I'll probably  
have to stop and think what "next" means in temporally ordered feeds  
from time to time since it'd be the reverse of temporal order.

> Not much sense starting at the other end which is constandly shifting.
Is this only going to be used to reconstruct full history?  What  
about just reconstructing the last 3 months (in which case you'd want  
a link from closer to the live end to close to the fixed end), or  
reading from the beginning before deciding whether to continue  
reading what comes later (in which case you'd want a link from closer  
to the fixed end to closer to the live end).

> Who said 'first/next/prev/last' would only be used by machines?
As mentioned above, there may be cases where you'd prefer to start at  
either the fixed or live end, so as long as complete feed  
reconstruction isn't the only goal, I'd say yes.

But what's "first"?  It'd be the top results in a search feed, but  
would it be the start of time or the start from the present (before  
possibly traveling backward through time) in a temporally ordered  
feed?  Making it the start of time would prevent it from matching up  
well with how significance ordered feeds match up (ie. does start  
point to the thing you'd most likely want to see if you subscribed to  
the feed?)  If we're not careful, we'll be traversing out of "first"  
through "prev" and "last" through "next"!

>> 4. Is the order of the entries in a feed relevant to this proposal?
If you mean not just the order within each chunk of the feed, but the  
order of the chunks, then not central, but certainly related.  Two  
cases come to mind:

1) A chain of temporally ordered chunks in the history of a feed  
where new entries are tacked onto the end.
2) Search results, where the order of everything all along the entire  
chain shifts around all the time.

If you're not going to reconstruct the whole thing, then your  
decision function for when to stop may have to be different depending  
on how things are ordered.

BTW, case 2 destroys the idea of a "fixed" end and a "live" end.

Having a means to indicate what the ordering is might make it easier  
to make the distinction between "next" and "prev" more intuitive.   
I'm not sure how else we're going to reconcile terminology for  
significance and temporally ordered feeds.

> non-incremental feeds wouldn't be paged, by definition, would they?
This week's top ten on the first page, last week's ten on the second  
page...

Since this proposal is defining a paging mechanism, I think that what  
each page represents is relevant.  Is it an earlier part of the feed  
or an earlier state of the feed?

>> subscribe, subscription, self, something else?
I just noticed something about the definition of "self" in the format  
spec.  In one place it says:

    o  atom:feed elements SHOULD contain one atom:link element with a  
rel
       attribute value of "self".  This is the preferred URI for
       retrieving Atom Feed Documents representing this Atom feed.

Does that mean that it's the preferred <option>subscription</option>  
URI, or the preferred place to retrieve <option>this chunk</option>  
of the feed history?  The format spec didn't define paging, so it  
didn't contemplate talking about chunks of the feed--so here it  
sounds like it's talking about a subscription URI (else it would say  
"for retrieving this Atom Feed Document.").  Moving on...elsewhere,  
the spec says this:

    3.  The value "self" signifies that the IRI in the value of the href
        attribute identifies a resource equivalent to the containing
        element.

In a historical chunk, wouldn't that have to mean "this chunk"?

Can "self" be polymorphic--the subscription URI in the live end of a  
feed, and "this chunk" in a historical chunk?  Can an extension speak  
authoritatively about the meaning of something from the core spec?

I'd think that if the feed history extension is an official Working  
Group document, then it wouldn't be out of line to use it to nail  
down the meaning of "self" more tightly, especially since we don't  
currently seem to have agreement about the meaning of "self".  Let's  
let "self" mean "a place to get what you're looking at right now,  
which may or may not change over time", and add "subscribe" with it's  
obvious meaning.  If a document contains both and they're different,  
then "self" should NOT be used to subscribe (although that arguably  
conflicts with the first part of the spec quoted above).  If "self"  
weren't a "SHOULD", I'd think this would lead to "self" being used  
only in historical chunks, and "subscribe" being used in both  
historical chunks and live documents to point to the subscription  
URI, which would be nice and clean.  But since "self" is a "SHOULD",  
I'm afraid this will lead to "self" pointing to live documents in  
documents without a "subscribe" link, and historical chunks in  
documents that do have "subscribe".  A bit ugly, but is there a  
better way available to us?

---

From: Antone Roundy <[email-masked]>
Date: Mon, 17 Oct 2005 10:31:20 -0600

...
> 2) Search results, where the order of everything all along the  
> entire chain shifts around all the time.
>
> decision function for when to stop may have to be different  
> depending on how things are ordered.
>
> Having a means to indicate what the ordering is might make it  
> easier to make the distinction between "next" and "prev" more  
> intuitive.  I'm not sure how else we're going to reconcile  
> terminology for significance and temporally ordered feeds.

Okay, I've got another idea--switch to totally generic terminology, a  
la:

"end-a": the URI of "most significant", "most current",  
"prerequisite"[1], etc. end of a sequence of documents, or a randomly  
selected end if there is no order.
"end-b": the URI of the "least significant", "least current",  
or ...uh, "postrequisite"? end of a sequence of documents or  
otherwise the opposite end from "end-a".
"a-ward": the URI of the document next closest to "end-a" in the  
sequence.
"b-ward": the URI of the document next closest to "end-b" in the  
sequence.

If you have neither "end-a" nor "end-b", then you should use "b-ward"  
to traverse out of the subscription document (ie. the subscription  
document in that case is assumed to be "end-a").

[1] if the sequence should be read first to last, for example, if  
it's a novel broken down into entries, "end-a" points to the place  
from which one should start.  Which end is "end-a" and which is "end- 
b" is somewhat subjective. For example, in a temporally ordered feed,  
is it most important to read what's most current, or to understand  
the origins of the present first before reading what's most current?

One more thing occurs to me--if this extension is going to be used to  
handle things like paging in search results, then it's not really  
"feed history", it's "paging".

---

From: Eric Scheid <[email-masked]>
Date: Tue, 18 Oct 2005 03:25:54 +1000

On 18/10/05 2:04 AM, "Antone Roundy" <[email-masked]> wrote:

> ...so do you follow forward through time or backward?  Is the  starting
> "current position" "now" or the "the beginning of time"?   Especially if we're
> talking about history, following backward makes  as much sense as following
> forward.

You can "start" wherever you want, but the @rel='first' archive is the
archive which contains the first entry that ever existed. Why would the
@rel='first' archive contain the last entry created, that makes no sense.

If you want to go backwards in time, then the "next" archive would be found
by following the @rel='prev' link .. because you are going backwards!

> I prefer "next" to go back in time (if temporally ordered--from the  most
> current chunk to the next most current chunk) or to less  significant pages
> (in things like search results).  But I'll probably  have to stop and think
> what "next" means in temporally ordered feeds  from time to time since it'd be
> the reverse of temporal order.

You're also likely to get confused when comparing Atom archives against
their HTML versions ... because in the HTML world the '@rel=first' page is
conventionally the oldest page, and the @rel='next' page traverses forward
in time.

> possibly travelling backward through time) in a temporally ordered

Ask yourself these questions: which is the "first" message in this thread,
and if you wanted to understand the thread would you start there, or at the
most recent entry in this thread and read backwards. Remember that by the
time you've read back to the initial posting there would likely now be even
more entries into this thread, so where would you then read them from ...
where you started and going forward in time, or would you jump to the most
recent and then read backwards until you hit a message you already read?

So, would you read the messages in this order:

    7,6,5,4,3,2,1,8,9,10,11,12,13,14

or...

    7,6,5,4,3,2,1,11,10,9,8,13,12,14

or...

    1,2,3,4,5,6,7,8,9,10,11,12,13,14

I know which way I'd prefer to read stuff.

e.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 18 Oct 2005 03:44:20 +1000

> authoritatively about the meaning of something from the core spec?

If it were so, and you were looking at an historical chunk, you would still
need some link to where you might subscribe to that feed.

So, if polymorphic, you'd have in the current living chunk a link of 'self'
to subscribe to, but in a historical chunk you'd need to ignore the 'self'
link and follow the 'subscribe' link instead.

If not polymorphic, in the current living chunk you'd have a 'subscribe'
link, and in a historical chunk you'd have a 'subscribe' link. They would
both mean the same thing, and have the same value. In the historical chunk
the 'self' link would be different from the 'subscribe' link (pointing at
the historical chunk, of course), but in the current living chunk they could
very well have the same value ... or not...

The "or not" case is best exemplified by the nature.com feed links. If you
want to subscribe to Nature Medicine, you'd use this URI ...

    http://www.nature.com/nm/current_issue/rss/

... but if you were to attempt to retrieve that URI today you would find
yourself redirected to ...

    http://www.nature.com/nm/journal/v11/n10/rss.rdf

... where, if were atom, you might find a 'self' link pointing to that
second URI, not the first.

The nature.com feeds are, btw, a rather good real-life example of
non-incremental feeds.

e.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 18 Oct 2005 03:45:44 +1000

> BTW, case 2 destroys the idea of a "fixed" end and a "live" end.

Case 2 would be a closed set, generally speaking.

<geeking> Technically, they wouldn't necessarily be closed sets. Tim Bray,
search god that he is, has explained in some blog post somewhere that the
smart thing to do is simply find the first hundred or so results, sort them,
and only when the user asks for more pages to bother going off and finding
more results to add to the collection. It's complicated, I think I
understood it for all of 10 seconds after I finished reading it, and it only
really applies to searching massive collections ... searches in more finite
collections would be, could be, completely closed sets. </geeking>

e.

---

From: Antone Roundy <[email-masked]>
Date: Mon, 17 Oct 2005 12:19:09 -0600

On Oct 17, 2005, at 11:25 AM, Eric Scheid wrote:
>> starting

Here's how "first" pointing to the last entry created could make  
sense--it's pointing not to the first entry, but to the first page in  
a chain of pages of entries.  In that case, "first" points to the  
starting point, whether that be the first entry created or the last.

> by following the @rel='prev' link .. because you are going backwards!

Consider this: <http://www.taipeitimes.com/News/editorials/archives/ 
2005/02/27/2003224800> -- my brother, who has spent time in Taiwan  
and China tells me that the Chinese are the same--they think of  
themselves as facing the past (which they can see--makes sense)--not  
the future.  The future is still unseen behind them.

But getting back to what I was saying above, "next in the chain" only  
correlate to one particular direction in time if the chain is defined  
in terms or a specific direction in time.  I face the past when I  
look at incremental feeds.

---

From: "James Holderness" <[email-masked]>
Date: Mon, 17 Oct 2005 19:39:01 +0100

> recent and then read backwards until you hit a message you already read?

This makes perfect sense if you're a human reading messages, but now try and 
understand it from the point of view of a computer program (an Atom 
processor). The computer doesn't care which messages came first. It's not 
going to try and read the messages and make sense of them. It just wants to 
retrieve all the documents in the most efficient way possible.

First off is has to start with the most recent document since that's what 
the user is going to subscribe to. From there, the most sensible thing to do 
would be to keep following links back in time to older and older archives 
until it has retrieved all of them or (if this is a feed that has been 
downloaded before) until it reaches an archive that it has previously 
retrieved.

While it's theoretically possible to obtain a link from the subscription 
document back to the oldest archive and then make your way forward in time 
that wouldn't be very efficient when you've most likely already retrieved 
all of those old archives.

From an aggregator's point of view, you really don't have that much choice - 
going backwards in time is the only sensible thing to do. Which is why 
aggregator developers tend to think of the most recent document as "first", 
and subsequent documents (back in time) as "next".

Technically these documents don't even have to be archives - they could just 
as easily be chunks of search results. The dates on the messages don't even 
come into play - an Atom processor wouldn't treat them any differently.

I don't dispute that you have valid reason for thinking that forwards in 
time is the way to go, but please don't assume those of us that think the 
opposite are necessarily insane.

Regards
James

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 17 Oct 2005 20:49:02 +0200

James Holderness wrote:
> This has been debated. There have been those who have expressed an 
> interest in having next and prev links traverse an archive of old 
> non-incremental feeds. Say you have a feed with the top 10 books for 
> this month. The next link (or prev link, depending on your preference) 
> would point to the archive document with the top 10 books from last month.
I think that Mark's concerns were that readers/aggregators generally 
keep a local history of the feeds they're subscribed to. 
fh:incremental=no would explicitly tell them not to do so.

-- 
Thomas Broyer

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Oct 2005 12:08:41 -0700

Exactly.

I don't want this draft to become the all-singing, all-dancing feed  
model review; although there's lots of interesting stuff there, it's  
way too ambitious for my tastes (and I think I detect the smell of a  
tarpit faintly wafting...). The feed history case gets us to a nice 80 
+% point; the rest can come in separate vehicles.

Any response to 'prev-archive'?

Cheers,

On 17/10/2005, at 11:49 AM, Thomas Broyer wrote:

>> non-incremental feeds. Say you have a feed with the top 10 books  
>> for this month. The next link (or prev link, depending on your  
>> preference) would point to the archive document with the top 10  
>> books from last month.
>>
> I think that Mark's concerns were that readers/aggregators  
> generally keep a local history of the feeds they're subscribed to.

---

From: James M Snell <[email-masked]>
Date: Mon, 17 Oct 2005 12:37:56 -0700

Mark, I honestly believe that feed history can be achieved using a very 
simple model:

a. incremental=true... which means that entries (posted at any time) may 
exist in other feed documents
b. start/next/prev... points to other feeds where entries may be found

if I point my newsreader to a feed document that has a incremental=true, 
I would look for a start link.  I would process the start feed then 
begin walking my way through the next links to build the history.  The 
start feed MAY have the most recent entries or MAY have the oldest 
entries, it doesn't matter.  My Atom processor would just Do The Right 
Thing with whatever entries it finds in the feeds as it walks through 
the linked list of feed documents.  How does the Atom processor know 
when it has the complete history?  Either a) the user tells it to stop 
or b) it reaches a feed without a "next" link.

There shouldn't be any requirement that the entries in a feed (or even 
the feed documents themselves) have to be in a specific order in order 
to reconstruct the history.  The minimum requirement is only that we're 
able to find the feed documents we need.  The Atom processor can figure 
the rest out from there.

- James

---

From: "James Holderness" <[email-masked]>
Date: Mon, 17 Oct 2005 20:35:01 +0100

Thomas Broyer wrote:
>> non-incremental feeds. Say you have a feed with the top 10 books for this 
>> month. The next link (or prev link, depending on your preference) would 
>> point to the archive document with the top 10 books from last month.
> I think that Mark's concerns were that readers/aggregators generally keep 
> a local history of the feeds they're subscribed to. fh:incremental=no 
> would explicitly tell them not to do so.

I get that, and I think it's important - I just don't think it should be 
part of this spec. It's a problem regardless of whether you have feed 
history or not. I don't think that people wanting to support non-incremental 
feeds (but aren't necessarily interested in feed history) should have to 
read the history spec to find out how to do it.

If we want to keep this spec as simple as possible, the fh:incremental tag 
is something that I think can be left out.

Regards
James

---

From: Eric Scheid <[email-masked]>
Date: Tue, 18 Oct 2005 05:43:42 +1000

On 18/10/05 4:39 AM, "James Holderness" <[email-masked]> wrote:

> processor). The computer doesn't care which messages came first.
> 

Yes, the _computer_ does *not* care. So why should it's preference trump the
human reader?

I imagine a future where a client application would offer up feed documents
rendered all pretty, and offer up any links to other feed documents as links
the client application will itslef render rather than passing them to a HTML
browser. Thus, a Feed Browser in the same sense as a HTML Browser. Do you
want to explain to future users why the "next" link gives them last weeks
news instead of next weeks news?

> It's not going to try and read the messages and make sense of them. It just
> wants to retrieve all the documents in the most efficient way possible.

Do things efficiently then. Remember though that the computer does *not*
care if the token is 'next' or 'prev' or even 'foobar'. Does *not* care.

> First off is has to start with the most recent document since that's what the
> user is going to subscribe to. From there, the most sensible thing to do would
> be to keep following links back in time to older and older archives until it
> has retrieved all of them or (if this is a feed that has been downloaded
> before) until it reaches an archive that it has previously retrieved.

Did you say "back" in time? Your explanation is riddled with references to
going backwards .. the aggregator/developer frame of reference is "going
backwards", so of course the "next" object would be the one marked as being
prior to the one your are currently on. That is, the next feed to process is
the one marked @rel='prev'.

Depending on what meta-data is available, and which axis you wish to
traverse, and in which direction, then the link to the object you wish to
retrieve after processing the current one could be "next", "prev", "hotter",
"colder", or "foobar". The usage of the word "next" in describing the
sequence of actions is entirely dependent on the purpose of those actions,
and quite possibly completely detached from the meaning of the content being
processed. 

The @rel='next' and @rel='prev' links however are part and parcel of the
content. They describe the content. They are provided by the content
publisher. They don't describe some third party's desired course of action.

> I don't dispute that you have valid reason for thinking that forwards in time
> is the way to go, but please don't assume those of us that think the opposite
> are necessarily insane.

But that would take all the fun out of things ;-)

e.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Oct 2005 12:42:28 -0700

I already get the same results with just one link relation -- 'prev- 
archive' -- instead of three.

The algorithm for combining results is an important issue, but an  
orthogonal one.

On 17/10/2005, at 12:37 PM, James M Snell wrote:

> Mark, I honestly believe that feed history can be achieved using a  
> very simple model:
>
> a. incremental=true... which means that entries (posted at any  
> time) may exist in other feed documents
> if I point my newsreader to a feed document that has a  
> incremental=true, I would look for a start link.  I would process  
> the start feed then begin walking my way through the next links to  
> build the history.  The start feed MAY have the most recent entries  
> or MAY have the oldest entries, it doesn't matter.  My Atom  
> processor would just Do The Right Thing with whatever entries it  
> finds in the feeds as it walks through the linked list of feed  
> documents.  How does the Atom processor know when it has the  
> complete history?  Either a) the user tells it to stop or b) it  
> reaches a feed without a "next" link.
>
> There shouldn't be any requirement that the entries in a feed (or  
> even the feed documents themselves) have to be in a specific order  
> in order to reconstruct the history.  The minimum requirement is  
> only that we're able to find the feed documents we need.  The Atom  
> processor can figure the rest out from there.
>
> - James
>
> Mark Nottingham wrote:
>
>
>>
>> Exactly.
>>
>> I don't want this draft to become the all-singing, all-dancing  
>> feed  model review; although there's lots of interesting stuff  
>> there, it's  way too ambitious for my tastes (and I think I detect  
>> the smell of a  tarpit faintly wafting...). The feed history case  
>> gets us to a nice 80 +% point; the rest can come in separate  
>> vehicles.
>>
>>>> This has been debated. There have been those who have expressed  
>>>> an  interest in having next and prev links traverse an archive  
>>>> of old  non-incremental feeds. Say you have a feed with the top  
>>>> 10 books  for this month. The next link (or prev link, depending  
>>>> on your  preference) would point to the archive document with  
>>>> the top 10  books from last month.
>>>>
>>>>
>>> generally keep a local history of the feeds they're subscribed  
>>> to.  fh:incremental=no would explicitly tell them not to do so.
>>>
>>> -- 
>>> Thomas Broyer
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --

---

From: Robert Sayre <[email-masked]>
Date: Mon, 17 Oct 2005 16:15:51 -0400

> archive' -- instead of three.

Why should one prefer your proposal to what's in this feed:
http://diveintomark.org/xml/2004/03/index.atom

'prev-archive' is more specific, and I think that's a bad thing. It
seems to introduce tower of babel problems.

Robert Sayre

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 17 Oct 2005 23:08:49 +0200

Mark Nottingham wrote:
> tarpit faintly wafting...). The feed history case gets us to a nice 
> 80+% point; the rest can come in separate vehicles.
>
Question: is what you want really a link to archives or isn't it just 
"simple" paging through a feed?

I suspect it is the latter, because reconstructing feed state is only 
needed if a complete set of entries is split into several documents.

Therefore, I'll rather suggest moving to:
 - a spec about paging, defining head/prev/next (do we really need 
tail?) [note: see with A9/OpenSearch people]
 - a spec defining fh:incremental, describing relation to paging (can a 
non-incremental feed be paged? does it mean something different than 
paging of an incremental feed?)
 - eventually a spec defining links to archives (which in turn may use 
paging: think about archives of search results, what did the same query 
return yesterday, last week, last month, etc.)

-- 
Thomas Broyer

---

From: "James Holderness" <[email-masked]>
Date: Mon, 17 Oct 2005 22:10:36 +0100

> Yes, the _computer_ does *not* care. So why should it's preference trump 

Personally I wouldn't care at all except for one reason. There exists a 
published "specification" that defines "next" as pointing to the next most 
recent archive, and at least one feed that follows that spec. Whatever is 
decided for the new protocol I would feel obliged to support that old 
protocol as well. If the two disagree that makes the process somewhat more 
complicated.

Everything else you say, while perfectly reasonable, does not inspire me to 
accept the extra effort involved without at least a mild protest.

> But that would take all the fun out of things ;-)

True. We wouldn't want that.

Regards
James

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 17 Oct 2005 23:13:52 +0200

James M Snell wrote:
> incremental=true, I would look for a start link.  I would process the 
> start feed then begin walking my way through the next links to build 
> the history.  The start feed MAY have the most recent entries or MAY 
> have the oldest entries, it doesn't matter.
It does matter if I don't want my newsreader to reconstruct the entire 
feed state and rather stop when it has read X entries or has reached 
Y-day old entries.
> to reconstruct the history.
It should (not SHOULD!) however be based on atom:updated or something 
similar (e.g. my-ext:last-modified)

-- 
Thomas Broyer

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Oct 2005 14:44:30 -0700

Robert,

It's a matter of personal preference as to whether one likes 'prev'  
or 'next'; if there had been wide implementation and a good  
specification of what MarkP did, I could see a strong argument for  
using it.

As it is, no one has even noticed it had similarity to this proposal  
until a few days ago, and it looks like there are a number of people  
who have strong feelings each way.

OTOH, how specific the relation is *is* a technical issue; could you  
expand on what you see as the 'tower of babel' problem?

My concern is that if there is more than one use of a link relation  
like 'next' or 'prev', those uses could conflict. For example, if I  
use 'prev' for Feed History, will that cause a problem with feeds  
using Amazon OpenSearch if they want to use it in a slightly  
different way? To put it in Thomas' terms, what if there are  
different concepts of paging using the same terms -- which there seem  
to be already?

This shows up perfectly with the whole "next or previous?"  
discussion. If we don't assign specific, functional semantics to the  
links, people will interpret -- and use -- them differently.

This is why I'm leaning towards "prev-archive".

---

From: James M Snell <[email-masked]>
Date: Mon, 17 Oct 2005 14:58:54 -0700

I know this was directed to Robert, but I'd like to throw my $.02 in.

Generally speaking, if the semantic difference between the use of 
next/prev in one feed relative to another can be expressed using a 
separate extension (e.g. the presence of an incremental=true or a 
profile attribute or whatever else may come up, then I would favor the 
use of the generic mechanism assuming that the basic function is the same.

- James

---

From: Eric Scheid <[email-masked]>
Date: Tue, 18 Oct 2005 07:59:50 +1000

> protocol as well. If the two disagree that makes the process somewhat more

That article was written for Atom 0.3. We are now Atom 1.0. That particular
feed which happens to follow that so-called spec is also Atom 0.3, which is
of course deprecated.

I've been amusing myself with a thought experiment this morning too. Say I
had a set of feed documents, all arranged from "hottest" to "coldest" using
@rel='hotter' and @rel='colder'. There are no other links in the feed
documents. Say for the sake of argument that the most efficient manner for
an aggregator to traverse that set is to start from the hottest, and proceed
towards the coldest.

Remember, there are only two @rel values in the feed: 'hotter' and 'colder'.

Which links should the aggregator follow:

    (a) @rel='hotter'
    (b) @rel='colder'
    (c) @rel='next'

> accept the extra effort involved without at least a mild protest.

All those 0.3 feeds should disappear in due course. That article was
specifically addressing Atom 0.3, and so too should not be relied on.

e.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Oct 2005 15:13:36 -0700

I would too, but getting to "the basic function is the same" requires  
a lot of foresight, if not luck.

This isn't directed at anyone in particular, but this discussion has  
taken shades of the absurd for a while now -- it seems like people  
are solving theoretical, not actual, problems. I have a concrete use  
case that I want to solve, and real users and implementers who want  
it solved. I get nervous when people try to fit it into some grand  
architectural sketch of how things *should* work that they have in  
mind; in my experience, such efforts rarely pay off, and often fail.

On 17/10/2005, at 2:58 PM, James M Snell wrote:

> profile attribute or whatever else may come up, then I would favor  
> the use of the generic mechanism assuming that the basic function  
> is the same.

---

From: Robert Sayre <[email-masked]>
Date: Mon, 17 Oct 2005 18:21:11 -0400

> specification of what MarkP did, I could see a strong argument for

I think the spec is perfectly clear. Is there something about it you
don't understand? I do think your addition of an indicator that the
feed is an archive is a good idea. I have to disagree with your
characterization of deployment. Most AtomAPI implementations work this
way--see for example typepad.com.

> links, people will interpret -- and use -- them differently.

Folks who have written Atom clients know which way 'next' points.

> This is why I'm leaning towards "prev-archive".

Mmm. I think 'prev-archive' means exactly the same thing that 'next'
does in the feeds you're describing, and people will certainly use it
in ways that don't reflect whatever you lay out in the spec. They will
look at a feed, and think "oh, I use prev-archive to get the next 10".
I know for a fact that other feeds So, now we have two ways to say the
same thing -- The Tower of Babel problem.

http://tantek.com/log/2005/07.html#towerofbabelproblem

Robert Sayre

---

From: "James Holderness" <[email-masked]>
Date: Mon, 17 Oct 2005 23:40:56 +0100

> Which links should the aggregator follow:

In the interests of past and future compatibility, my currently 
implementation looks like this:

1. In the subscription document, look for a link with a type of 
"application/atom+xml", a non-empty href, and with any of the following rel 
values: "next", "prev", "prev-archive", "hotter", "colder".
2. If any such link exists, consider it a pointer to the most recent 
archive.
3. To find the next most recent archive, search the current archive for a 
link with the same rel attribute as established in step 1.

Can't fail. ;)

In the interests of my sanity, I'm bowing out of this discussion now. 
Whatever is decided I will implement it.

Regards
James

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Oct 2005 16:17:05 -0700

They seem similar. But, what if you want to have more than one paging  
semantic applied to a single feed, and those uses of paging don't  
align? I.e., there's contention for prev/next?

If no one shares my concern, I'll drop it... as long as I get to say  
"I told you so" if/when this problem pops up :)

On 17/10/2005, at 3:21 PM, Thomas Broyer wrote:

> I don't think there are different concepts of paging.
>
> Paging is navigation through subsets (chunks) of a complete set of  
> entries.
>
> If the complete set represents all the entries ever published  
> through an ever-changing feed document (what a feed currently is,  
> you subscribe with an URI and the document you get when  
> dereferencing the URI changes as a sliding-window upon a set of  
> entries), then paging allows for feed state reconstruction.
> In other terms, feed state reconstruction is a facet of paging, an  
> application to non-incremental feeds.
>
>
> I think it's worth waiting consensus on previous/next or forwards/ 
> backwards, first/last or head/tail, etc. and having a "paging" spec  
> (or just IANA registration, I don't really matter), and  
> orthogonally define an fh:incremental extension (fh:incremental  
> will just change newsreaders behavior, not the paging concept).
> It seems James is having the same feeling…

---

From: James M Snell <[email-masked]>
Date: Mon, 17 Oct 2005 16:19:09 -0700

> "I told you so" if/when this problem pops up :)
Be sure to throw a "neener neener neener" into it and we're good to go ;-)

- James

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 18 Oct 2005 00:21:28 +0200

Mark Nottingham wrote:
> using Amazon OpenSearch if they want to use it in a slightly different 
> way? To put it in Thomas' terms, what if there are different concepts 
> of paging using the same terms -- which there seem to be already?

Paging is navigation through subsets (chunks) of a complete set of entries.

If the complete set represents all the entries ever published through an 
ever-changing feed document (what a feed currently is, you subscribe 
with an URI and the document you get when dereferencing the URI changes 
as a sliding-window upon a set of entries), then paging allows for feed 
state reconstruction.
In other terms, feed state reconstruction is a facet of paging, an 
application to non-incremental feeds.

I think it's worth waiting consensus on previous/next or 
forwards/backwards, first/last or head/tail, etc. and having a "paging" 
spec (or just IANA registration, I don't really matter), and 
orthogonally define an fh:incremental extension (fh:incremental will 
just change newsreaders behavior, not the paging concept).
It seems James is having the same feeling…

-- 
Thomas Broyer

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Oct 2005 16:13:16 -0700

Robert,

  As I said before, if the WG can reach consensus, I'm happy with any  
old term. I hadn't seen Mark's proposal till a few days ago, and a  
mention in an xml.com does not,  in my opinion, a spec-in-stone make.  
My only pushback on "next" is that to me, it seems counterintuititive  
-- same as your pushback on "prev." *shrug*

The SixApart people have publicly pointed to FH, so I don't think  
they're particularly fussed about any particular approach other (not  
to put words in their mouth). I wasn't able to find a TP feed that  
uses rel="next"; do you have a link to one?

If the WG registers a set of generic link relations (I still have  
that concern, but again, if there's consensus in the WG, I'm happy to  
abide by it), it effectively reduces FH to a users' guide for one use  
of those extensions, and would probably say something like "walk down  
and next or prev you see in the subscription feed." The only  
normative bit would probably be fh:incremental.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Oct 2005 16:36:17 -0700

Oh, no. I'd never sink to *those* depths!

On 17/10/2005, at 4:19 PM, James M Snell wrote:

> Mark Nottingham wrote:
>
>
>> They seem similar. But, what if you want to have more than one  
>> paging  semantic applied to a single feed, and those uses of  
>> paging don't  align? I.e., there's contention for prev/next?
>>
>> If no one shares my concern, I'll drop it... as long as I get to  
>> say  "I told you so" if/when this problem pops up :)
>>
>>

---

From: Robert Sayre <[email-masked]>
Date: Mon, 17 Oct 2005 19:38:13 -0400

On 10/17/05, Mark Nottingham <[email-masked]> wrote:
> The SixApart people have publicly pointed to FH,

Cool!

> so I don't think
> to put words in their mouth).

Did you miss Byrne's post?
<http://www.imc.org/atom-syntax/mail-archive/msg17249.html>

> I wasn't able to find a TP feed that

They use them in their AtomAPI implementation, not the public feeds.
<http://www.sixapart.com/pronet/docs/typepad_atom_api>

<http://www.typepad.com/t/atom/weblog/blog_id={blogid}> points to the
20 newest entries. There's a link rel="next" in there that points to
the next 20 entries.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Mon, 17 Oct 2005 20:53:12 -0600

On Oct 17, 2005, at 5:17 PM, Mark Nottingham wrote:
> paging semantic applied to a single feed, and those uses of paging  
> don't align? I.e., there's contention for prev/next?
>
I share your concern.

>> Paging is navigation through subsets (chunks) of a complete set of  
Yeah, but what if you need what amounts to a multi-dimensional  
array.  The method of addressing each dimension has to be  
distinguishable from the others.

>> application to non-incremental feeds.
Let's say you're doing a feed for the Billboard top 100 songs.  Each  
week, the entire contents of the feed are swapped out and replaced by  
a new top 100 (ie. it is a non-incremental feed).  And let's say you  
don't want to put all 100 in the same document, but you want to break  
it up into 4 documents with 25 entries each.  You now have two  
potential axes that people might want to traverse--from songs 1-25 to  
26-50 to 51-75 to 76-100, or from this weeks 1-25 to last weeks 1-25  
to two weeks ago's 1-25, etc.  You can't link in both directions with  
the same "next".

There are clearly two distinct concepts here--navigating through the  
chunks that make up the current state of the feed resource, and in a  
non-incremental feed, navigating though the historical states of the  
feed resource.

---

From: James M Snell <[email-masked]>
Date: Mon, 17 Oct 2005 21:34:56 -0700

> distinguishable from the others.
Ok, what if?  Do you have any specific use cases where this would be 
required with feed linking?  And how theoretical are those cases?  I 
just don't see this as being a practical problem that needs solved right 
now.

> to two weeks ago's 1-25, etc.  You can't link in both directions with  
Of course not.

Feed 1:                  next >> Feed 2
Feed 2: Feed 1 << prev   next >> Feed 3
Feed 3: Feed 2 << prev   next >> Feed 4
Feed 4: Feed 3 << prev

It's easy to do this kind of thing.. the challenge I'm having with this 
use case is that I don't actually see anyone trying to do this.  It's 
another "what if" scenario.  If this isn't something that someone is 
currently trying to do, this is a problem that can easily be solved 
later, when it does become an issue.  The best we can do now is attempt 
to make sure that we don't make it impossible to solve later.

- James

---

From: "Thomas Broyer" <[email-masked]>
Date: Tue, 18 Oct 2005 09:51:39 +0200 (CEST)

> align? I.e., there's contention for prev/next?

How can there be more than one paging semantic applied to a single feed?

If a feed (not feed document) is a set of entries (sorted by whatever
metadata: updated, priority, relevance, etc.) and you publish chunks as
many feed documents, paging is navigation from one to the other, following
the sort order.

If you want to provide the exact same entries sorted (thus paged)
differently, then that's another feed.

-- 
Thomas Broyer

---

From: "Thomas Broyer" <[email-masked]>
Date: Tue, 18 Oct 2005 10:14:48 +0200 (CEST)

> non-incremental feed, navigating though the historical states of the

Yes, and navigating through the historical states of the feed resource is
not paging, it's more like having access to archives.

I was thinking about proposing yet another link relation "archives": in
the general use case, it would reference another feed document where each
entry describes an archive:

Top 100 feed:
<feed xmlns...>
    <title>October 2005 Top 100</title>
    <fh:incremental xmlns...>no</fh:incremental>
    <!-- this links to the next chunk of the non-incremental feed -->
    <link rel="next" type="application/atom+xml"
          href="26-50.atom" title="26 to 50 entries" />
    <!-- this links to a list of archives -->
    <link rel="archives" type="application/atom+xml"
          href="../archives.atom" title="Top 100 archives" />
    ...

Archive feed:
<feed xmlns...>
    <fh:incremental xmlns...>yes</fh:incremental>
    <!-- this links to the next chunk of the archive feed -->
    <link rel="next" type="application/atom+xml"
          href="archives2.atom" />
    ...
    <entry>
        <title>September 2005 Top 100</title>
        <content type="application/atom+xml" src="2005/09/1-25.atom" />
        ...
    </entry>
    <entry>
        <title>August 2005 Top 100</title>
        <content type="application/atom+xml" src="2005/08/1-25.atom" />
        ...
    </entry>
    ...

September 2005 Top 100 feed:
<feed xmlns...>
    <title>September 2005 Top 100</title>
    <fh:incremental xmlns...>no</fh:incremental>
    <!-- this links to the next chunk of the non-incremental feed -->
    <link rel="next" type="application/atom+xml"
          href="26-50.atom" title="26 to 50 entries" />
    <!-- this links to a list of archives -->
    <link rel="archives" type="application/atom+xml"
          href="../archives.atom" title="Top 100 archives" />
    ...

-- 
Thomas Broyer

---

From: Eric Scheid <[email-masked]>
Date: Tue, 18 Oct 2005 19:06:19 +1000

> entry describes an archive:

The word 'archives' is too general though. May I suggest @rel="history"
instead?

Otherwise, +1

e.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 18 Oct 2005 18:11:13 +1000

> many feed documents, paging is navigation from one to the other, following

... and the subset of entries which are on page 1 sorted by one axis would
be very unlikely to be on page 1 when sorted by some other axis.

d'oh!

> differently, then that's another feed.

unless of course each feed document contains only one entry each ;-)

e.

---

From: James M Snell <[email-masked]>
Date: Tue, 18 Oct 2005 08:27:11 -0700

+1

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 18 Oct 2005 23:06:47 +0200

> The word 'archives' is too general though. May I suggest @rel="history"
I'm not a native English speaker so…

…but what's wrong with "archives"?

According to my understanding of "archives vs. history", when an 
Archived Feed (January 2005 Top 100 feed) links to the Archive Feed (the 
one listing each and every Archived Feed), isn't "history" a bit 
"disturbing"? as the Archive Feed will contain entries about archives of 
feeds published later (February 2005 Top 100 feed, March 2005 Top 100 
feed), that is, the Archive Feed doesn't contains the "history" of the 
January 2005 Top 100 feed but "archives" of each Top 100 feed ever 
published.

As said above, English is not my mother tong, so I don't really mind 
which word is chosen, I'll use it (also, someone other than me will 
certainly have to go through the IANA registration process, or at least 
help me to do it…)

-- 
Thomas Broyer

---

From: Eric Scheid <[email-masked]>
Date: Wed, 19 Oct 2005 11:00:51 +1000

On 19/10/05 7:06 AM, "Thomas Broyer" <[email-masked]> wrote:

> I'm not a native English speaker soŠ
> 
> Šbut what's wrong with "archives"?

IIRC, you wanted a new link relation specific to historical style archives.

Why choose "archives" over "history" to the exclusion of other types of
archives?

e.

---

From: Robert Sayre <[email-masked]>
Date: Wed, 19 Oct 2005 12:08:00 -0400

On 10/17/05, Mark Nottingham <[email-masked]> wrote:
> or 'next';
...
> like 'next' or 'prev', those uses could conflict.
...
> This is why I'm leaning towards "prev-archive".

OK. 'prev-archive' is fine. Let's throw it against the wall see if it
sticks. No amount of atom-syntax traffic is going to resolve this.
We'll see if it turns out to be useful.

Robert Sayre