Subject: RE: Feed History -04

From: "Byrne Reese" <[email-masked]>
Date: Mon, 17 Oct 2005 13:06:30 -0400

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

+1 

"next" and "previous" are as James points out, orthogonal to ordering.
The debate as to whether the next set goes backwards or forwards in time
is not about the use of the terms "next" and "previous," it is about the
default sort order of a result set.

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

Case and point. The answer to this question depends entirely upon the
sort order. Another way to think about it: if I have a feed of my
"popular" entries does "first" point to the least popular or most
popular? You could argue both sides pretty effectively, but once you
decide on the order, and then I put you are the beginning of the list
and asked you, "please get me the next entry in the result set" I doubt
anyone would have a hard time fulfilling my request.

> 
> > 2. Are next and prev both needed in the spec if we only 
> require one of 
> > them 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.

-1

Yes, they are both needed. I would want 'next' and 'prev' to used to
create pagination controls, where the user is in control of traversing
the archive.

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

To be honest, I am less concerned about 'last' but I do like 'first' and
for the sake of symmetry, I think we should support both.

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

+1

> > 5. Is the issue of whether a feed is incremental or not (the 
> > fh:incremental
> > element) relevant to this proposal?
> 
> non-incremental feeds wouldn't be paged, by definition, would they?

Why not? Why wouldn't I have a "Top 100 DVDs of All Time" broken out
into 10 feeds of 10 entries each?

Although one could say that the presence of 'next' and 'prev' links
indicate that the feed is incremental, and the absence of those links
indicates the feed is complete.

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

+1

---

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

> indicates the feed is complete.

Ugh!  This suggests yet another feed model.  First, what we've  
already got:

1) Incremental feed document: a feed document that contains a subset  
of the entries that are currently in the feed (resource), where new  
entries are added to the feed without replacing old entries.

2) Non-incrememental feed document: a feed document which contains  
representations of every entry which is currently part of the feed,  
where new entries replace old entries.

and then...

3) ??? feed document: a feed document which contains representations  
of a subset of the entries that are currently in the feed (resource),  
where new entries replace old entries.

Linking up #3 documents to show a history of the feed will be even  
more complicated than what we've been discussing.  Do we need such a  
beast?  I wish I could unequivocally say "no", but I'm forced to  
equivocate: are not search result feeds #3?  It seems that indeed we  
need two separate mechanisms--a paging mechanism and a history  
mechanism.  Unless both are going to go into the same extension, the  
extensions should be explicit about the the fact that they describe  
one and not the other.  And we should choose link/@rel names  
carefully so that one doesn't end up using names better suited fore  
the other.

---

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

> default sort order of a result set.

Fully agree. Let's use what MarkP wrote down over a year ago, and stop
debating the nature of adjacency and ordering as it relates time and
archives. Are there any technical problems with the elements in this
feed:

http://diveintomark.org/xml/2004/03/index.atom

Works for me. Can anyone tell us about problems this causes for their software?

Robert Sayre

---

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

>http://diveintomark.org/xml/2004/03/index.atom
;-) Woo hoo! Robert and I agree on something ;-)

Debating how the entries are organized is fruitless.  The Atom spec 
already states that the order of elements in the feed has no 
significance; trying to get an extension to retrofit order-significance 
into the feed is going to fail... just as I discovered with my Feed 
Index extension proposal.

* Next/Prev/Start/Subscribe defines a linked list of feed documents 
and/or entry documents and says absolutely nothing about the ordering of 
the entries.
* Next/Prev/Start/Subscribe should be defined in their own specification 
that is not bound to Feed History
* Feed History (if MarkN wishes it so) should normatively reference the 
Next/Prev/Start/Subscribe extension spec

I do believe that a "last" link relation would be helpful for 
completeness and I do believe the use cases are there (e.g. search 
results, etc) but I am ok with dropping that for now as it can easily be 
defined later once the use cases do become more prominent. 

Over the next week I'll see if I can draft up the spec.  I'll use what 
MarkP put together as the basis for what I write up and submit.

- James

---

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

If we're going to separate the concepts of "history" and "paging",  
then the term "history" doesn't really apply to incremental feeds.   
In an incremental feed, all of the entries are part of the current  
state of the feed.  We don't go back through history to find the  
present--we go to different pages of the present.  In a non- 
incrememental feed also, we may have multiple pages of current  
entries (eg. the top 100 DVDs in chunks of 10), or we may have just  
one.  We also may preserve historical data (eg. the top 10 songs last  
week, the week before, etc.)

So what we end up with might looks like this:

Any feed, whether incremental or not, MAY contain something like this  
(names chosen somewhat arbitrarily, with an eye toward avoiding  
excess conceptual baggage):

page-a - the URI of one end of a chain of documents representing one  
state of a feed resource (eg. the current state of an incremental  
feed)--it doesn't really matter which end it is
page-b - the other end of the chain of documents
page++ - the next farther page from page-a
page-- - the next closer page to page-a

Neither "page-a" nor "page-b" is necessarily fixed--the entire  
contents of the chain may shuffle around, be added to, be deleted  
from, etc., in the case of something like search results.

A non-incremental feed MAY also contain something like this (history  
is temporal, so we can use temporally loaded terminology):

history-1 - a document containing a representation of one of the ends  
of or the entire temporally first historical state of the feed resource
history-n - a document containing a representation of one of the ends  
of or the entire temporally last (perhaps current and still changing)  
historical state of the feed resource
history++ - one of the ends or ... of the the next more recent  
historical state... (moves toward history-n)
history-- - one of the ends ... of the next less recent historical  
state... (moves toward history-1)

If you want to catch up on an incremental feed to which you're  
subscribed, or want to get the last month of an incremental feed to  
which you are newly subscribed, you look for "page++" or "page--" and  
follow whichever one the subscription document (which can only have  
one, since it's one of the ends) contains till you've got everything  
you want.

If you start in the middle, you don't know which direction you're  
going...but since the ordering of the chain isn't defined, it's like  
the Cheshire cat says--it doesn't matter which direction you go if  
you don't know where you want to end up...or something like that.   
Perhaps convention could dictate that "page-a" be where the publisher  
subjectively thinks that a newcomer to the feed would be most likely  
to want to start reading.  It wouldn't always be correct, but so what?

---

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

On 17/10/2005, at 12:31 PM, James M Snell wrote:
> significance; trying to get an extension to retrofit order- 
> significance into the feed is going to fail... just as I discovered  
> with my Feed Index extension proposal.

+1

> results, etc) but I am ok with dropping that for now as it can  
> easily be defined later once the use cases do become more prominent.
> Over the next week I'll see if I can draft up the spec.  I'll use  
> what MarkP put together as the basis for what I write up and submit.

We actually don't need a spec, according to -11; we just need to send  
an e-mail to IANA requesting the registrations, and get IESG  
approval. Assuming we can come to WG consensus, that should be easy.

I took a look at doing this over the weekend, and this is what I came  
up with;

  -  Attribute Value: prev
  -  Description: A stable URI that, when dereferenced, returns a  
feed document containing entries that sequentially precede those in  
the current document. Note that the exact nature of the ordering  
between the entries and documents containing them is not defined by  
this relation; i.e., this relation is only relative.
  -  Expected display characteristics: Undefined.
  -  Security considerations: Because automated agents may follow  
this link relation to construct a 'virtual' feed, care should be  
taken when it crosses administrative domains (e.g., the URI has a  
different authority than the current document).

  -  Attribute Value: next
  -  Description: A stable URI that, when dereferenced, returns a  
feed document containing entries that sequentially follow those in  
the current document. Note that the exact nature of the ordering  
between the entries and documents containing them is not defined by  
this relation; i.e., this relation is only relative.
  -  Expected display characteristics: Undefined.
  -  Security considerations: Because automated agents may follow  
this link relation to construct a 'virtual' feed, care should be  
taken when it crosses administrative domains (e.g., the URI has a  
different authority than the current document).

  -  Attribute Value: first
  -  Description: A stable URI that, when dereferenced, returns a  
feed document containing those entries furthest preceding those in  
the current document at the time it was minted. Note that the exact  
nature of the ordering between the entries and documents containing  
them is not defined by this relation; i.e., this relation is only  
relative.
  -  Expected display characteristics:
  -  Security considerations:

  -  Attribute Value: last
  -  Description: A stable URI that, when dereferenced, returns a  
feed document containing those entries furthest following those in  
the current document at the time it was minted. Note that the exact  
nature of the ordering between the entries and documents containing  
them is not defined by this relation; i.e., this relation is only  
relative.
  -  Expected display characteristics: Undefined.
  -  Security considerations:

  -  Attribute Value: subscribe
  -  Description: A stable URI that, when dereferenced, returns a  
feed document containing the most recent entries in the feed. This  
URI is intended to be subscribed to to keep abreast of changes in the  
feed. When different from the URI of the feed document it exists in,  
it indicates a URi that should be used for this purpose in place of  
the current document's URI.
  -  Expected display characteristics: Undefined.
  -  Security considerations: Users should always be informed of the  
actual URI they are subscribing to, and subscription should only take  
place when it is explicitly requested.

I have one concern about this approach, which I'll outline separately  
(in response to Robert).

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

---

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

> approval. Assuming we can come to WG consensus, that should be easy.
Yeah, I know we don't *need* a spec; having a spec is my personal bias 
towards having a clear description about how things are defined and how 
they are to be used.  In this case, it may not matter much.  So I'm 
perfectly fine with the email to IANA approach.

>  -  Description: A stable URI that, when dereferenced, returns a  feed 
> document containing entries that sequentially precede those in  the 
> current document. Note that the exact nature of the ordering  between 
> the entries and documents containing them is not defined by  this 
> relation; i.e., this relation is only relative.
>  -  Security considerations: Because automated agents may follow  this 
> link relation to construct a 'virtual' feed, care should be  taken 
> when it crosses administrative domains (e.g., the URI has a  different 
> authority than the current document).
>
+1. An additional security concern would be the potential for circular 
references

>  -  Attribute Value: next
>  -  Description: A stable URI that, when dereferenced, returns a  feed 
> document containing entries that sequentially follow those in  the 
> current document. Note that the exact nature of the ordering  between 
> the entries and documents containing them is not defined by  this 
> relation; i.e., this relation is only relative.
>  -  Security considerations: Because automated agents may follow  this 
> link relation to construct a 'virtual' feed, care should be  taken 
> when it crosses administrative domains (e.g., the URI has a  different 
> authority than the current document).
>
+1

>  -  Attribute Value: first
>  -  Description: A stable URI that, when dereferenced, returns a  feed 
> document containing those entries furthest preceding those in  the 
> current document at the time it was minted. Note that the exact  
+1

>  -  Attribute Value: last
>  -  Description: A stable URI that, when dereferenced, returns a  feed 
> document containing those entries furthest following those in  the 
> current document at the time it was minted. Note that the exact  
+1

>  -  Description: A stable URI that, when dereferenced, returns a  feed 
> document containing the most recent entries in the feed. This  URI is 
> intended to be subscribed to to keep abreast of changes in the  feed. 
> When different from the URI of the feed document it exists in,  it 
> indicates a URi that should be used for this purpose in place of  the 
> current document's URI.
+1

- James

---

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

Good point.

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

> +1. An additional security concern would be the potential for  
> circular references

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 18 Oct 2005 01:07:15 +0200

Mark Nottingham wrote:
> link relation to construct a 'virtual' feed, care should be taken when 
> it crosses administrative domains (e.g., the URI has a different 
> link relation to construct a 'virtual' feed, care should be taken when 
> it crosses administrative domains (e.g., the URI has a different 
> current document at the time it was minted. Note that the exact nature 
> of the ordering between the entries and documents containing them is 
> not defined by this relation; i.e., this relation is only relative.
> current document at the time it was minted. Note that the exact nature 
> of the ordering between the entries and documents containing them is 
> not defined by this relation; i.e., this relation is only relative.
+0.5 (adding the circular references issue raised by James), because 
some people will use "first" to link to the "live" feed (the one you 
subscribe to) and "next" to link to the first archive document and so 
on, and some will use "last" and "prev" for the exact same roles…
The given definition is not precise enough.

And wrt "prev", why not "previous"? both could also be registered as 
aliases…
> place when it is explicitly requested.
Depends whether @rel="self" was really meant for subscribing and the 
spec wording is not precise enough about it; this could then be fixed 
with an errata rather than create a new link relation…
Otherwise, +0.5, because it seems to overlap @rel="first" (or "last"?) – 
or I missed something…

-- 
Thomas Broyer

---

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

Thomas Broyer wrote:

> Otherwise, +0.5, because it seems to overlap @rel="first" (or "last"?) 
> – or I missed something…
>
"self" should always point to the feed document containing the self 
link.  It makes no sense to have a "self" link in a feed that does not 
point to itself.

- James

---

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

On 17/10/2005, at 4:07 PM, Thomas Broyer wrote:
>> the current document at the time it was minted. Note that the  
>> exact nature of the ordering between the entries and documents  
>> containing them is not defined by this relation; i.e., this  
>> relation is only relative.
>> the current document at the time it was minted. Note that the  
>> exact nature of the ordering between the entries and documents  
>> containing them is not defined by this relation; i.e., this  
>> relation is only relative.
> +0.5 (adding the circular references issue raised by James),  
> because some people will use "first" to link to the "live" feed  
> (the one you subscribe to) and "next" to link to the first archive  
> document and so on, and some will use "last" and "prev" for the  
> exact same roles…

"A stable URI" was intended to capture that, but I see that wasn't  
good enough. How about:

- Attribute Value: first
- Description: A stable URI that, when dereferenced, returns a feed  
document containing the set of entries furthest preceding those in  
the current document at the time it was minted. The set of entries in  
this document should not change over time; i.e., this link points to  
a stable snapshot of entries, or an archive of feed entries. Note  
that the exact nature of the ordering between the entries and  
documents containing them is not defined by this relation; i.e., this  
relation is only relative.
- Expected display characteristics: ...
- Security considerations: ...

Another thought would be "first-archive", "last-archive", "prev- 
archive" and "next-archive" (just expanding a previous thought).

> And wrt "prev", why not "previous"? both could also be registered  
> as aliases…

I'd prefer one or the other; don't care much which it is, but two  
seems wasteful. HTTP-WG didn't alias Referer even tho it's spelled  
incorrectly, for example. That worked out OK.

>> URI is intended to be subscribed to to keep abreast of changes in  
>> the feed. When different from the URI of the feed document it  
>> exists in, it indicates a URi that should be used for this purpose  
>> in place of the current document's URI.
>> actual URI they are subscribing to, and subscription should only  
>> take place when it is explicitly requested.
>>
> Depends whether @rel="self" was really meant for subscribing and  
> the spec wording is not precise enough about it; this could then be  
> fixed with an errata rather than create a new link relation…

I think there's value in the current reading of "self"; it's  
sometimes useful for a document to know what URI it's available at.  
Also, when it occurs in another feed, "self" is a very non-obvious  
name for what's happening.

> Otherwise, +0.5, because it seems to overlap @rel="first" (or  
> "last"?) – or I missed something…

I think we're kind of short on use cases for first and last, but  
people seem to want them. 'subscribe' is more explicit; as they're  
written, 'first' and 'last' should definately NOT be subscribed to  
(because the set of entries in them won't change).

Cheers,

---

From: Eric Scheid <[email-masked]>
Date: Tue, 18 Oct 2005 09:28:49 +1000

On 18/10/05 9:07 AM, "Thomas Broyer" <[email-masked]> wrote:

> with an errata rather than create a new link relationŠ

IIRC, it came into existence to solve the feed subscription problem.
However, I don't recall that the issue of feed archives featured much in
that discussion, and that thus the now understood problem of 'self' vs
'subscribe' wasn't envisaged.

Fortunately, the link relation 'self' was defined in such a woolly way we
could get away with re-purposing it. A few articles here or there, a bit of
blog chatter, and the arrival of the fabled Developers Guide and we'd be
set.

I'd think this would be favourable to having to come up with a different
pair of relations, like

    'self'       = what you subscribe to,
                   may not look anything like the chunk in front of you

    'this-chunk' = link to what you are looking at,
                   not to be confused with 'self'

(Maybe the Developers Guide will have a chapter called "Up Is Down - The New
Reality", which would explain that a link to 'self' doesn't, we use 'next'
to go backwards, and 'alternate' for feed discovery may not point to actual
alternates of the content in front of you ;-)

> or I missed somethingŠ

There's nothing wrong with having an overlap like this, because they don't
always overlap. Consider the 'subscribe' link to nature.com/nm/ which I
described earlier - two different URIs, but the same eventual document.

e.

---

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

> archive" and "next-archive" (just expanding a previous thought).
-1.  The first/next/prev/last link rels should not specify any 
restrictions on how the contents of the feeds should or should not be 
updated.  If a specific use of these link rels wishes to impose such a 
restriction (e.g. for feed history), then great, so-be-it, but the link 
rels themselves should not.

> incorrectly, for example. That worked out OK.
+1, it doesn't matter... but I do prefer "previous" because I don't like 
abbreviations in things like this

+1

- James

---

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

So what happens when you need the rel="self" (as currently defined)  
of an archive feed?

--
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: Mark Nottingham <[email-masked]>
Date: Mon, 17 Oct 2005 16:55:11 -0700

The intent here was to say that the *set* of entries is generally  
stable, not that they're set in stone. That's what you want, no? If  
so, how about:

- Attribute Value: first
- Description: A stable URI that, when dereferenced, returns a feed  
document containing the set of entries furthest preceding those in  
the current document at the time it was minted. This can be thought  
of as specific to those entries; in other words, it represents a  
fixed section of the feed, rather than a sliding window over it. Note  
that the exact nature of the ordering between the entries and  
documents containing them is not defined by this relation; i.e., this  
relation is only relative.
- Expected display characteristics: ...
- Security considerations: ...

It's a hard line to walk.

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

>> "A stable URI" was intended to capture that, but I see that  
>> wasn't  good enough. How about:
>>
>> - Attribute Value: first
>> feed  document containing the set of entries furthest preceding  
>> those in  the current document at the time it was minted. The set  
>> of entries in  this document should not change over time; i.e.,  
>> this link points to  a stable snapshot of entries, or an archive  
>> of feed entries. Note  that the exact nature of the ordering  
>> between the entries and  documents containing them is not defined  
>> by this relation; i.e., this  relation is only relative.
> restrictions on how the contents of the feeds should or should not  
> be updated.  If a specific use of these link rels wishes to impose  
> such a restriction (e.g. for feed history), then great, so-be-it,  
> but the link rels themselves should not.

---

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

> It's a hard line to walk.
Hmm.. better than before.  It would be better if you left it at the "at 
the time it was minted" part and left out the sentence that follows.  
But I can live with it.

- James

---

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

> So what happens when you need the rel="self" (as currently defined)

The current definition being ...

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

thus a link with @rel='self' in the <feed> element would link to that
archive feed document. Similarly, a link with @rel='self' in the <entry>
element would link to a resource document of that particular entry.

Thus (in context of <feed>)

    'self'      = identifies a resource equivalent to this <feed>
    'subscribe' = identifies the resource to subscribe to

The same holds true for archive feeds and the current sliding window chunk,
which makes life easier.

e.

---

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

On Oct 17, 2005, at 3:44 PM, Mark Nottingham wrote:
>> Debating how the entries are organized is fruitless.  The Atom  
>> spec already states that the order of elements in the feed has no  
>> significance into the feed is going to fail... just as I  
>> discovered with my Feed Index extension proposal.
Here's what the spec says: "This specification assigns no  
significance to the order of atom:entry elements within the  
feed."  ...but there may be some.  ...but there's no action you can  
take based on it unless something else tells you what the  
significance is.  ...which, yes, is very difficult to specify.

For the purposes of this discussion, it doesn't matter what the order  
of atom:entry elements within a feed document is.  But the order of  
chunks of atom:entry elements within a linked series of feed  
documents may have significance, and in fact, unless you just want to  
reconstruct the complete feed state, working with a series of feed  
documents with no specific order would be fairly unwieldy.  Imagine  
paging though a feed of search results with no idea of whether you'd  
just jumped from the most to the least significant results, or to the  
second most significant results.  Imagine trying to catch up on a  
fast-moving incremental feed without having any idea whether a link  
would take you to the first entries ever added to a feed or the one's  
you just missed.

>> completeness
...and "last" certainly seems to imply SOME sort of ordering of  
chunks, even if we know nothing about the order of the entries in  
each chunk.

To each of the following, perhaps we could add something to indicate  
that these link relations are all used to page through the current  
state of a feed, and not to navigate among various states of a feed.   
The fact that most people wouldn't have a clue what that means  
without some discussion of incremental and non-incremental feeds may  
be an argument for having a spec document to provide more explanation  
(rather than embedding an identical explanation in each  
Description).  Example:

"At any point in time, a feed may be represented by a series of Feed  
documents, each containing some of the entries that exist in the feed  
at that point in time.  In other words, a feed may contain more  
entries than exist in the Feed document that one retrieves when  
dereferencing the subscription URI, and there may be other documents  
containing representations of those additional entries.  The link  
relations defined in this specification are used to navigate between  
Feed documents containing pages or chunks of those entries which  
exist simultaneously within a feed.

"Note that this specification does not address navigation between the  
current and previous states of a type of feed which does not  
simultaneously contain it's current and past entries.  For example, a  
"Top 100 Songs" feed might at any point in time only contain entries  
for the top 100 songs for a single week, which entries may or may not  
be divided among a number of Feed documents.  The entries for the top  
100 songs from the previous week are not only no longer part of the  
Feed document or Feed documents representing the current state of the  
feed--they are no longer part of the feed at all.  Another  
specification may describe a method of navigating between the current  
and previous states of such a feed.  The link relations defined in  
this specification are only used to navigate between the various Feed  
documents representing any single state of such a feed."

---

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

Antone Roundy wrote:

> significance to the order of atom:entry elements within the  feed."  
> ...but there may be some.  ...but there's no action you can  take 
> based on it unless something else tells you what the  significance 
> is.  ...which, yes, is very difficult to specify.
>
Not only difficult to specify, impossible to enforce.  There's no way we 
can expect implementations to preserve the order of entries

> would take you to the first entries ever added to a feed or the one's  
That's what incremental=true is for, or the feed rank mechanism, etc.  
Basically, the next/prev mechanism should be used in conjunction with 
something else that specifies the ordering of the entries, etc.  The 
next/prev link relations should imply nothing more than a linked list of 
feeds.

> chunks, even if we know nothing about the order of the entries in  
Nope.  It implies nothing more than a closed-set linked list of feeds.  
No ordering is implied.  We could achieve the same result with 
rel="start" and rel="end"

> (rather than embedding an identical explanation in each  
When I think of next/prev I'm not thinking about any form of temporal 
semantic.  I'm thinking about nothing more than a linked list of feed 
documents.  If you want to add a temporal semantic into the picture, use 
a mechanism such as the Feed History incremental=true element. 

In other words,

this does not imply a feed history thing...
  <feed>
    ...
    <link rel="next" href="..." />
  </feed>

this does...
  <feed>
    ...
    <fh:incremental>true</fh:incremental>
    <link rel="next" href="..." />
  </feed>

> exist simultaneously within a feed.
Again, you're thinking in terms of Feed History.  I'm separating the 
link rel's out from Feed History and making them more generic.  I would 
fully expect that the Feed History spec would define some ordering and 
processing semantic for the linked documents.

- James

---

From: Antone Roundy <[email-masked]>
Date: Mon, 17 Oct 2005 22:58:18 -0600

On Oct 17, 2005, at 10:17 PM, James M Snell wrote:
> When I think of next/prev I'm not thinking about any form of  
> temporal semantic.  I'm thinking about nothing more than a linked  
> list of feed documents.  If you want to add a temporal semantic  
> into the picture, use a mechanism such as the Feed History  
> incremental=true element.
I don't think I expressed the point I wanted to make quite clearly  
enough, so let me try again.

Chains of Feed documents are going to be ordered in some way, whether  
it's specified or not, whether they explicitly indicate it or not.   
For example, the chain of Feed documents representing an incremental  
feed is going to naturally be in temporal order.  You're not going to  
be tacking on new entries willy nilly to whichever of the documents  
in the chain fits your fancy at the moment.  You're going to create a  
new document when the one you were most recently adding entries to  
gets "full", and then your going to add entries there till that one  
is "full", and so on.  There may be exceptions, but by and large,  
whether the temporal order is explicit or not, that's what's going to  
happen.

Chains of pages of search results feeds are going to naturally be  
ordered with the best matches "on top".

The point I was trying to make was that you're not going to create  
all the documents without links between then and then randomly assign  
links between them in no specific order.  You're going to link  
between then in an order that makes sense within the context of how  
the feed was created.

I don't know how client applications are going to adapt to deal with  
the difference between incremental feeds and, for example, search  
results feeds, but I can't imagine that client software isn't going  
to rely on there being some sort of sense to the order of the Feed  
documents.

What I was trying to say further down with the example spec text I  
wrote was, let's state explicitly that this link relation does not  
have a temporal semantic, and if somebody want's a link relation with  
a temporal semantic, they should create another link/@rel value for it.

In other words...
> this does not imply a feed history thing...
...let's have this be a link for navigating among the pages of the  
current state of the feed (whether it be incremental or not--noting  
that some non-incremental feeds will only have one page, and won't  
need it).  The entries in the current state of the feed are not in  
any specific order (though we know that naturally they will be in  
>    <link rel="next" href="..." />

How does the following have anything to do with history?  In an  
incremental feed, all of the entries, whether part of the Feed  
document at the subscription end or not, are part of the present  
state of the feed--they don't just exist back in history.  History is  
for non-incremental feeds.  I'm saying let's not work on navigation  
through history right now, but let's recognize that unless we say not  
to, people might try to use the mechanism designed for paging through  
the current state of a feed to navigate through the history of a feed  
too, so let's say not to.  I understand (or at least suppose) that  
you don't think we need to say not to, because you don't see the harm  
in making the link relation more generic.  I disagree.  I think we're  
going to end up with a mess if we don't make it specifically for  
navigating the current state.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Oct 2005 22:25:11 -0700

Requiring a separate element to always be present is a non-starter;  
what is the point of a "reusable" link relation if you have to use it  
with another element to contextualise it? I'm really stretching to  
see any benefit from this approach.

prev-archive (or maybe prev-entries?) is starting to look better, as  
is <fh:prev/>.

---

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

+1

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Oct 2005 22:32:48 -0700

On 17/10/2005, at 5:14 PM, James M Snell wrote:
> Hmm.. better than before.  It would be better if you left it at the  
> "at the time it was minted" part and left out the sentence that  
> follows.  But I can live with it.

That phrase is probably redundant. Which leaves:

  -  Attribute Value: previous
  -  Description: A stable URI that, when dereferenced, returns a  
feed document containing a set of entries that sequentially precede  
those in the current document. This can be thought of as specific to  
those entries; in other words, it represents a fixed section of the  
feed, rather than a sliding window over it. Note that the exact  
nature of the ordering between the entries and documents containing  
them is not defined by this relation; i.e., this relation is only  
relative.
  -  Expected display characteristics: Undefined.
  -  Security considerations: Because automated agents may follow  
this link relation to construct a 'virtual' feed, care should be  
taken when it crosses administrative domains (e.g., the URI has a  
different authority than the current document). Such agents should  
also take care to detect circular references between feeds when  
following them.

  -  Attribute Value: next
  -  Description: A stable URI that, when dereferenced, returns a  
feed document containing a set of entries that sequentially follow  
those in the current document. This can be thought of as specific to  
those entries; in other words, it represents a fixed section of the  
feed, rather than a sliding window over it. Note that the exact  
nature of the ordering between the entries and documents containing  
them is not defined by this relation; i.e., this relation is only  
relative.
  -  Expected display characteristics: Undefined.
  -  Security considerations: Because automated agents may follow  
this link relation to construct a 'virtual' feed, care should be  
taken when it crosses administrative domains (e.g., the URI has a  
different authority than the current document). Such agents should  
also take care to detect circular references between feeds when  
following them.

  -  Attribute Value: first
  -  Description: A stable URI that, when dereferenced, returns a  
feed document containing those entries furthest preceding those in  
the current document. This can be thought of as specific to those  
entries; in other words, it represents a fixed section of the feed,  
rather than a sliding window over it. Note that the exact nature of  
the ordering between the entries and documents containing them is not  
defined by this relation; i.e., this relation is only relative.
  -  Expected display characteristics: Undefined.
  -  Security considerations:

  -  Attribute Value: last
  -  Description: A stable URI that, when dereferenced, returns a  
feed document containing those entries furthest following those in  
the current document. This can be thought of as specific to those  
entries; in other words, it represents a fixed section of the feed,  
rather than a sliding window over it. Note that the exact nature of  
the ordering between the entries and documents containing them is not  
defined by this relation; i.e., this relation is only relative.
  -  Expected display characteristics: Undefined.
  -  Security considerations:

  -  Attribute Value: subscribe
  -  Description: A stable URI that, when dereferenced, returns a  
feed document containing a set of the most recent entries in the  
feed. This URI is intended to be subscribed to to keep abreast of  
changes in the feed. When different from the URI of the feed document  
it exists in, it indicates a URi that should be used for this purpose  
in place of the current document's URI.
  -  Expected display characteristics: Undefined.
  -  Security considerations: Users should always be informed of the  
actual URI they are subscribing to, and subscription should only take  
place when it is explicitly requested.

One other thought; what about "first-entries", "next-entries",  
"previous-entries", "last-entries"?

---

From: James M Snell <[email-masked]>
Date: Mon, 17 Oct 2005 23:01:02 -0700

> "previous-entries", "last-entries"?
Blech... -1

Everything else, +1

- James

---

From: Eric Scheid <[email-masked]>
Date: Tue, 18 Oct 2005 16:12:34 +1000

On 18/10/05 3:32 PM, "Mark Nottingham" <[email-masked]> wrote:

> Such agents should also take care to detect circular
> references between feeds when following them.

s/between feeds when/between feed documents/

otherwise +1

e.

---

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

> link.  It makes no sense to have a "self" link in a feed that does not

Right, off course… My apologies…

So +0.5 to "subscribe" because it seems to overlap "first" (or "last"?) –
or I missed something… ;o)

-- 
Thomas Broyer

---

From: Robert Sayre <[email-masked]>
Date: Tue, 18 Oct 2005 08:02:45 -0400

> prev-archive (or maybe prev-entries?) is starting to look better, as

Hogwash. Do not reinvent the AtomAPI. Posting on atom-syntax and then
claiming your way is the right way after all because people are
arguing and some folks are saying silly things... why did you bother?

Robert Sayre

---

From: Henry Story <[email-masked]>
Date: Tue, 18 Oct 2005 11:27:09 -0700 (PDT)

My laptop broke down so I am having touble following all of this thread, 
but I agree that next, prev, ...  should just suggest a linked list.
There should then be special links for hist-prev, hist-next, ... that
are in rdf terms sub-properties of prev, next, etc... On the atom-owl 
mailing list we are working on a very faithful onotology to the 
atom-syntax, that would allow this sub-property relation to be clearly 
stated. This keeps everything very nicely open, allowing many specialised
semantics of the next, prev, style to be created.

Henry

    On Mon, 17 Oct 2005, James M Snell wrote:

> Date: Mon, 17 Oct 2005 12:31:38 -0700
> From: James M Snell <[email-masked]>
> To: Robert Sayre <[email-masked]>
> Cc: Byrne Reese <[email-masked]>,
>     Eric Scheid <[email-masked]>,
>     Atom Syntax <[email-masked]>
> Subject: Re: Feed History -04
> 
>
> Robert Sayre wrote:
>
> Debating how the entries are organized is fruitless.  The Atom spec already 
> states that the order of elements in the feed has no significance; trying to 
> get an extension to retrofit order-significance into the feed is going to 
> fail... just as I discovered with my Feed Index extension proposal.
>
>
> * Next/Prev/Start/Subscribe defines a linked list of feed documents and/or 
> entry documents and says absolutely nothing about the ordering of the 
> entries.
> * Next/Prev/Start/Subscribe should be defined in their own specification that 
> is not bound to Feed History
> I do believe that a "last" link relation would be helpful for completeness 
> and I do believe the use cases are there (e.g. search results, etc) but I am 
> ok with dropping that for now as it can easily be defined later once the use 
> cases do become more prominent. 
> Over the next week I'll see if I can draft up the spec.  I'll use what MarkP 
> put together as the basis for what I write up and submit.
>
> - James
>