Re: Feed History -04

[Henry Story]

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 PROTECTED]>
To: Robert Sayre <[EMAIL PROTECTED]>
Cc: Byrne Reese <[EMAIL PROTECTED]>,
Eric Scheid <[EMAIL PROTECTED]>,
    Atom Syntax 
Subject: Re: Feed History -04


Robert Sayre wrote:


On 10/17/05, Byrne Reese <[EMAIL PROTECTED]> wrote:


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



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



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

Re: Feed History -04

[James Holderness]

Eric Scheid wrote:

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:


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

Re: Feed History -04

[Eric Scheid]

On 18/10/05 7:10 AM, "James Holderness" <[EMAIL PROTECTED]> wrote:

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

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'

> Everything else you say, while perfectly reasonable, does not inspire me to
> 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.

Re: Feed History -04

[Thomas Broyer]

James M Snell wrote:
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.
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.
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.
It should (not SHOULD!) however be based on atom:updated or something 
similar (e.g. my-ext:last-modified)


--
Thomas Broyer

Re: Feed History -04

[James Holderness]

Eric Scheid wrote:
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.


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

human reader?


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

Re: Feed History -04

[Thomas Broyer]

Mark Nottingham wrote:
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'?
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

Re: Feed History -04

[Robert Sayre]

On 10/17/05, Mark Nottingham <[EMAIL PROTECTED]> wrote:
>
> I already get the same results with just one link relation -- 'prev-
> 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

Re: Feed History -04 -- is it history or paging or both?

[Antone Roundy]

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?

Re: Feed History -04

[James M Snell]

Robert Sayre wrote:


On 10/17/05, Byrne Reese <[EMAIL PROTECTED]> wrote:
 


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



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

 


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

Re: Feed History -04

[Mark Nottingham]

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

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

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.


Any response to 'prev-archive'?

Cheers,


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




James Holderness wrote:


5. Is the issue of whether a feed is incremental or not (the   
fh:incremental

element) relevant to this proposal?




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





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








--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

_ 
___
BEAWorld 2005: coming to a city near you.  Everything you need for  
SOA and enterprise infrastructure success.



Register now at http://www.bea.com/4beaworld


London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26  
Oct| Beijing 7-8 Dec










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

Re: Feed History -04

[Eric Scheid]

On 18/10/05 4:39 AM, "James Holderness" <[EMAIL PROTECTED]> wrote:

> 
> Eric Scheid wrote:
> 
>> 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?
>> 
> 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.
> 

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.

Re: Feed History -04

[James Holderness]

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


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

Re: Feed History -04

[James M Snell]

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

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.


Any response to 'prev-archive'?

Cheers,


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



James Holderness wrote:

5. Is the issue of whether a feed is incremental or not (the  
fh:incremental

element) relevant to this proposal?



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



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







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

Re: Feed History -04

[Mark Nottingham]

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:



James Holderness wrote:

5. Is the issue of whether a feed is incremental or not (the  
fh:incremental

element) relevant to this proposal?



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



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







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

Re: Feed History -04

[Robert Sayre]

On 10/17/05, Byrne Reese <[EMAIL PROTECTED]> wrote:
> "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.

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

Re: Feed History -04

[Thomas Broyer]

James Holderness wrote:
5. Is the issue of whether a feed is incremental or not (the 
fh:incremental

element) relevant to this proposal?


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


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

Re: Feed History -04

[James Holderness]

Eric Scheid wrote:

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?


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

Re: Feed History -04

[Antone Roundy]

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

On 18/10/05 2:04 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:
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.

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


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.


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!


Consider this:  -- 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.

Re: Feed History -04

[Antone Roundy]

On Oct 17, 2005, at 11:06 AM, Byrne Reese wrote:

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



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



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

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


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


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


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


and then...

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


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

Re: Feed History -04

[Eric Scheid]

On 18/10/05 2:04 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:

> 2) Search results, where the order of everything all along the entire
> chain shifts around all the time.
> 
> BTW, case 2 destroys the idea of a "fixed" end and a "live" end.

Case 2 would be a closed set, generally speaking.

 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. 

e.

Re: Feed History -04

[Eric Scheid]

On 18/10/05 2:04 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:

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

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.

Re: Feed History -04

[Eric Scheid]

On 18/10/05 2:04 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:

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

> 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 travelling 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"!

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.

RE: Feed History -04

[Byrne Reese]

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

Re: Feed History -04

[Antone Roundy]

On Oct 17, 2005, at 10:04 AM, Antone Roundy wrote:

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

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


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

Re: Feed History -04

[Antone Roundy]

On Oct 17, 2005, at 2:20 AM, Eric Scheid wrote:

On 17/10/05 5:09 PM, "James Holderness" <[EMAIL PROTECTED]> wrote:
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.
...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.


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



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

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


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


6. What to name the link relation that points to the active feed  
document?

subscribe, subscription, self, something else?

'subscribe'
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 subscription  
URI, or the preferred place to retrieve this chunk  
of the feed history?  The format spec didn't define paging, so it  
didn't

Re: Feed History -04

[Eric Scheid]

On 18/10/05 12:43 AM, "James Holderness" <[EMAIL PROTECTED]> wrote:

> Eric Scheid wrote:
> 
>> 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.
>> 
> 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).

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

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

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

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

e.

Re: Feed History -04

[Mark Nottingham]

On 17/10/2005, at 1:20 AM, Eric Scheid wrote:

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.


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



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

Re: Feed History -04

[James Holderness]

Eric Scheid wrote:

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.


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?


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.


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


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?


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

Re: Feed History -04

[Eric Scheid]

On 17/10/05 9:30 PM, "Lindsley Brett-ABL001" <[EMAIL PROTECTED]>
wrote:

> I would like to toss out another thought - since the updated time of a
> feed is required, maybe it can be used to help determine the feed
> order/history. 
> For example, if following a "next" link (or pick your favorite term), if
> the updated time gets older, then the client can understand these
> entries are from an earlier time. If when following the "next" link the
> updated time stays the same, then the client can assume this is just
> more of the same collection from the previous point in time (unordered
> collection). Just a thought...

Won't work -- older date-paged archives may have an entry updated anytime in
the future, and thus not only does that entry get a more recent atom:updated
than any entries intervening then and now, but the feed itself will also get
a more recent atom:updated.

e.

RE: Feed History -04

[Lindsley Brett-ABL001]

I would like to toss out another thought - since the updated time of a
feed is required, maybe it can be used to help determine the feed
order/history. 
For example, if following a "next" link (or pick your favorite term), if
the updated time gets older, then the client can understand these
entries are from an earlier time. If when following the "next" link the
updated time stays the same, then the client can assume this is just
more of the same collection from the previous point in time (unordered
collection). Just a thought...

Brett Lindsley, Motorola Labs.

Re: Feed History -04

[Eric Scheid]

On 17/10/05 5:09 PM, "James Holderness" <[EMAIL PROTECTED]> wrote:

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

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

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

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

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

'subscribe'

e.

Re: Feed History -04

[James Holderness]

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.


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

Re: Feed History -04

[James M Snell]

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.



 tag:example.com,2005:/1
 http://www.example.com/entries/2.entry";
   type="application/atom+xml" />
 http://www.example.com/entries/0.entry";
   type="application/atom+xml" />


The challenge comes when you want to link to entries that are contained 
within a feed, in which case, we could use xml:id



 ...

 tag:example.com,2005:/1
 


 tag:example.com,2005:/1
 



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 
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 PROTECTED]>
To: Eric Scheid <[EMAIL PROTECTED]>
Cc: Atom Syntax 
Subject: Re: Feed History -04


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?



On 15/10/2005, at 7:25 PM, Eric Scheid wrote:



On 16/10/05 6:54 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote:



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?



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.




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.






--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Re: Feed History -04

[James M Snell]

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 in alphabetical order, in inverse historical order? Perhaps in 
alphabetical order of author,...


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)



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?


Take a look at my feed rank proposal and let me know what you think.

- James

Re: Feed History -04

[Henry Story]

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



On 15/10/2005, at 7:25 PM, Eric Scheid wrote:



On 16/10/05 6:54 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote:



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?



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.



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.






--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Re: Feed History -04

[Henry Story]

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 PROTECTED]>
To: Eric Scheid <[EMAIL PROTECTED]>
Cc: Atom Syntax 
Subject: Re: Feed History -04


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?



On 15/10/2005, at 7:25 PM, Eric Scheid wrote:



On 16/10/05 6:54 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote:



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?



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.



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.






--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Re: Feed History -04

[Robert Sayre]

On 10/15/05, Mark Nottingham <[EMAIL PROTECTED]> wrote:
>
> 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?

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

Re: Feed History -04

[Mark Nottingham]

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?



On 15/10/2005, at 7:25 PM, Eric Scheid wrote:



On 16/10/05 6:54 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote:



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?



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.




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.






--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Re: Feed History -04

[Eric Scheid]

On 16/10/05 6:54 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote:

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

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.

Re: Feed History -04

[Mark Nottingham]

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.


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?


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.



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.


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?


Not sure. I suppose that it would be the same as it is with your  
existing fh:prev element.


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?



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

Re: Feed History -04

[James M Snell]

Mark Nottingham wrote:



On 14/10/2005, at 8:32 PM, James M Snell wrote:



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


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.



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


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. 



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.


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?


Not sure. I suppose that it would be the same as it is with your 
existing fh:prev element.


- James

Re: Feed History -04

[Mark Nottingham]

On 14/10/2005, at 8:32 PM, James M Snell wrote:


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



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.


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,

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

Re: Feed History -04

[Eric Scheid]

On 15/10/05 1:32 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:

> My answer would be: if "last" is used, it's a closed set; if "last" is
> 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.

Re: Feed History -04

[Eric Scheid]

On 15/10/05 8:28 AM, "Henry Story" <[EMAIL PROTECTED]> wrote:

> Is the 'first' the feed document that changes, whereas 'next' and 'last'
> 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.

Re: Feed History -04

[James M Snell]

Mark Nottingham wrote:


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?


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

Re: Feed History -04

[James M Snell]

Mark Nottingham wrote:


Right. A few questions that pop up:

1) Is it a closed or open set? If it's open (and I think 99% of feeds  
are), what does "last" mean?


My answer is that it's probably an open set, so "last" doesn't mean  
much that's useful (unless it's conflated with the subscription feed;  
see below).


My answer would be: if "last" is used, it's a closed set; if "last" is 
not used, it's an open set.


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.


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.




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.


 is the first feed in the linked list
 is the next feed in the linked list
 is the previous feed in the linked list
 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:


 ...
 
 
 
 ...



 ...
 
 
 
 
 
 ...



 ...
 
 
 
 ...


- James

Mark Nottingham wrote:




At first I really liked this proposal, but I think that the kind  
of  confusion you're concerned about is unavoidable; the terms you  
refer  to suffer "bottom-up" vs. "top-down."


I think that defining the terms well and in relation to the   
subscription feed will help; after all, the terms don't surface  in  
UIs, so it should be transparent.



On 14/10/2005, at 10:37 AM, Antone Roundy wrote:


Which brings me back to "top", "bottom", "up" and "down".  In  the  
OpenSearch case, it's clear which end the "top" results are  going  
to be found.  In the syndication feed case, the convention  is to  
put the most recent entries at the "top".  If you think of  a feed  
as a stack, new entries are stacked on "top".  The fact  that 
these  terms are less generic and flexible than "previous"  and 
"next" is  both an advantage and a disadvantage.  I think the  
question is  whether it's an advantage in a significant majority  
of cases or  not.  What orderings would those terms not work well  
for?






--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

_ 
___
BEAWorld 2005: coming to a city near you.  Everything you need for  
SOA and enterprise infrastructure success.



Register now at http://www.bea.com/4beaworld


London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26  Oct| 
Beijing 7-8 Dec











--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Re: Feed History -04

[Mark Nottingham]

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.


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

Re: Feed History -04

[James Holderness]

Subscription feed:
  - can contain link/@rel="prev", OR
  - 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?



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?


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

Re: Feed History -04

[Mark Nottingham]

This leads to:

Subscription feed:
  - can contain link/@rel="prev", OR
  - can contain fh:incremental = "false"

Archive feed:
  - can contain link/@rel="prev" and/or link/@rel="next"
  - can contain link/@rel="subscribe"  (effectively gives you "last")
  - link/@rel="subscribe" has a semantic of "if you want to  
subscribe to this feed, use the linked document, not this one."


The reconstruction algorithm is pretty much the same as in -04.

The only dangling point is "first." I'm not especially against it,  
but what's the use case?




On 14/10/2005, at 4:53 PM, Mark Nottingham wrote:



Right. A few questions that pop up:

1) Is it a closed or open set? If it's open (and I think 99% of  
feeds are), what does "last" mean?


My answer is that it's probably an open set, so "last" doesn't mean  
much that's useful (unless it's conflated with the subscription  
feed; see below).


2) What's the relationship between these feed documents and the  
feed document that people subscribe to?


I think the subscription feed needs to be pinned to one end of the  
set (which is what FH does now). Otherwise, it becomes difficult to  
figure out whether you have the complete set or not by polling.



On 14/10/2005, at 3:16 PM, James M Snell wrote:




The way I look at this is in terms of a single linked list of  
feeds.  The ordering of the entries within those feeds is  
irrelevant.  The individual linked feeds MAY be incremental (e.g.  
blog entries,etc) or may be complete (e.g. lists,etc).  Simply  
because a feeds are linked, no assumption should be made as to  
whether or not the entries in those feeds share any form of  
ordered relationship.


 is the first feed in the linked list
 is the next feed in the linked list
 is the previous feed in the linked list
 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:


 ...
 
 
 
 ...



 ...
 
 
 
 
 
 ...



 ...
 
 
 
 ...


- James

Mark Nottingham wrote:





At first I really liked this proposal, but I think that the kind  
of  confusion you're concerned about is unavoidable; the terms  
you refer  to suffer "bottom-up" vs. "top-down."


I think that defining the terms well and in relation to the   
subscription feed will help; after all, the terms don't surface  
in  UIs, so it should be transparent.



On 14/10/2005, at 10:37 AM, Antone Roundy wrote:



Which brings me back to "top", "bottom", "up" and "down".  In  
the  OpenSearch case, it's clear which end the "top" results are  
going  to be found.  In the syndication feed case, the  
convention is to  put the most recent entries at the "top".  If  
you think of a feed  as a stack, new entries are stacked on  
"top".  The fact that these  terms are less generic and flexible  
than "previous" and "next" is  both an advantage and a  
disadvantage.  I think the question is  whether it's an  
advantage in a significant majority of cases or  not.  What  
orderings would those terms not work well for?







--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

 

BEAWorld 2005: coming to a city near you.  Everything you need  
for SOA and enterprise infrastructure success.



Register now at http://www.bea.com/4beaworld


London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26  
Oct| Beijing 7-8 Dec













--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems






--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Re: Feed History -04

[Mark Nottingham]

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.


 is the first feed in the linked list
 is the next feed in the linked list
 is the previous feed in the linked list
 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:


 ...
 
 
 
 ...



 ...
 
 
 
 
 
 ...



 ...
 
 
 
 ...


- James

Mark Nottingham wrote:




At first I really liked this proposal, but I think that the kind  
of  confusion you're concerned about is unavoidable; the terms you  
refer  to suffer "bottom-up" vs. "top-down."


I think that defining the terms well and in relation to the   
subscription feed will help; after all, the terms don't surface  
in  UIs, so it should be transparent.



On 14/10/2005, at 10:37 AM, Antone Roundy wrote:


Which brings me back to "top", "bottom", "up" and "down".  In  
the  OpenSearch case, it's clear which end the "top" results are  
going  to be found.  In the syndication feed case, the convention  
is to  put the most recent entries at the "top".  If you think of  
a feed  as a stack, new entries are stacked on "top".  The fact  
that these  terms are less generic and flexible than "previous"  
and "next" is  both an advantage and a disadvantage.  I think the  
question is  whether it's an advantage in a significant majority  
of cases or  not.  What orderings would those terms not work well  
for?






--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

_ 
___
BEAWorld 2005: coming to a city near you.  Everything you need for  
SOA and enterprise infrastructure success.



Register now at http://www.bea.com/4beaworld


London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26  
Oct| Beijing 7-8 Dec











--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Re: Feed History -04

[James M Snell]

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

A. Pagaltzis wrote:


* James M Snell <[EMAIL PROTECTED]> [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,
 

Re: Feed History -04

[A. Pagaltzis]

* James M Snell <[EMAIL PROTECTED]> [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 // 

Re: Feed History -04

[Robert Sayre]

On 10/14/05, James M Snell <[EMAIL PROTECTED]> wrote:
>
> 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

Re: Feed History -04

[Henry Story]

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


 is the first feed in the linked list
 is the next feed in the linked list
 is the previous feed in the linked list
 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:


...



...



...





...



...



...


- James

Mark Nottingham wrote:



At first I really liked this proposal, but I think that the kind of 
confusion you're concerned about is unavoidable; the terms you refer  to 
suffer "bottom-up" vs. "top-down."


I think that defining the terms well and in relation to the  subscription 
feed will help; after all, the terms don't surface in  UIs, so it should be 
transparent.



On 14/10/2005, at 10:37 AM, Antone Roundy wrote:

Which brings me back to "top", "bottom", "up" and "down".  In the 
OpenSearch case, it's clear which end the "top" results are going  to be 
found.  In the syndication feed case, the convention is to  put the most 
recent entries at the "top".  If you think of a feed  as a stack, new 
entries are stacked on "top".  The fact that these  terms are less generic 
and flexible than "previous" and "next" is  both an advantage and a 
disadvantage.  I think the question is  whether it's an advantage in a 
significant majority of cases or  not.  What orderings would those terms 
not work well for?




--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

 
BEAWorld 2005: coming to a city near you.  Everything you need for SOA and 
enterprise infrastructure success.



Register now at http://www.bea.com/4beaworld


London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 
7-8 Dec

Re: Feed History -04

[James M Snell]

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.


 is the first feed in the linked list
 is the next feed in the linked list
 is the previous feed in the linked list
 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:


 ...
 
 
 
 ...



 ...
 
 
 
 
 
 ...



 ...
 
 
 
 ...


- James

Mark Nottingham wrote:



At first I really liked this proposal, but I think that the kind of  
confusion you're concerned about is unavoidable; the terms you refer  
to suffer "bottom-up" vs. "top-down."


I think that defining the terms well and in relation to the  
subscription feed will help; after all, the terms don't surface in  
UIs, so it should be transparent.



On 14/10/2005, at 10:37 AM, Antone Roundy wrote:

Which brings me back to "top", "bottom", "up" and "down".  In the  
OpenSearch case, it's clear which end the "top" results are going  to 
be found.  In the syndication feed case, the convention is to  put 
the most recent entries at the "top".  If you think of a feed  as a 
stack, new entries are stacked on "top".  The fact that these  terms 
are less generic and flexible than "previous" and "next" is  both an 
advantage and a disadvantage.  I think the question is  whether it's 
an advantage in a significant majority of cases or  not.  What 
orderings would those terms not work well for?




--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

 

BEAWorld 2005: coming to a city near you.  Everything you need for SOA 
and enterprise infrastructure success.



Register now at http://www.bea.com/4beaworld


London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| 
Beijing 7-8 Dec

Re: Feed History -04

[Joe Gregorio]

On 10/14/05, Antone Roundy <[EMAIL PROTECTED]> wrote:
>
> On Oct 14, 2005, at 11:13 AM, Mark Nottingham wrote:
> > 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.
> >
> 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.

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 Gregoriohttp://bitworking.org

RE: Feed History -04

[Byrne Reese]

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

+1

Maybe this goes without saying, but I think the spec needs to either:

a) define these terms clearly and how they should be used and
interpreted (in which case it doesn't matter what words we use), or 
b) provide a mechanism for the feed to define their meaning relative to
the feed (perhaps James' FeedRank extension is relevant here?) - i.e.
"this feed sorts items chronologically in ascending order." With that
information, "next" and "previous" become more meaningful.

Without either (a) or (b) then the meaning of whatever terms we choose
will depend too much on the developer's mental model for feeds. For
example, if you visualize a feed like this (e.g. a web page's
chronologically sorted list):

--- "top"
 |
 |- entry
 |
 |- entry
 |
 |- entry
 |
--- "bottom"

Then the terms "up" and "down" are quite meaningful, and "next" and
"prev" a little ambiguous (am I top-down kinda guy, or a bottom-up?). Of
course you then have to be clear to what "top" and "bottom" means.

Then if you visualize feeds like this (like a linear timeline for
example):

|||||
   entry  |  entry
entry

Then "up" and "down" are the terms that become less meaningful. Yadda
yadda yadda.

My feeling is that erring on the side of more broadly applicable, and
semantically well know terms like "next" and "previous" will be more
useful to extensions wishing to extend the metaphor or model for their
own purposes (the FeedRank extension comes to mind specifically).

I can even see value for a feed to specify more information about its
"result set":




  10
  21
  30
  55
  /feed/entry/published
  ascending


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Nottingham
Sent: Friday, October 14, 2005 11:28 AM
To: Antone Roundy
Cc: atom-syntax@imc.org
Subject: Re: Feed History -04


At first I really liked this proposal, but I think that the kind of  
confusion you're concerned about is unavoidable; the terms you refer  
to suffer "bottom-up" vs. "top-down."

I think that defining the terms well and in relation to the  
subscription feed will help; after all, the terms don't surface in  
UIs, so it should be transparent.


On 14/10/2005, at 10:37 AM, Antone Roundy wrote:

> Which brings me back to "top", "bottom", "up" and "down".  In the  
> OpenSearch case, it's clear which end the "top" results are going  
> to be found.  In the syndication feed case, the convention is to  
> put the most recent entries at the "top".  If you think of a feed  
> as a stack, new entries are stacked on "top".  The fact that these  
> terms are less generic and flexible than "previous" and "next" is  
> both an advantage and a disadvantage.  I think the question is  
> whether it's an advantage in a significant majority of cases or  
> not.  What orderings would those terms not work well for?


--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems



BEAWorld 2005: coming to a city near you.  Everything you need for SOA
and enterprise infrastructure success.

 
Register now at http://www.bea.com/4beaworld

 
London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct|
Beijing 7-8 Dec

RE: Feed History -04

[Byrne Reese]

+1

The meaning of these terms depends so much upon the feed it is being
used within. That and your own mental model.

If you visualize a feed like this:

---
 |
 | 
 |
|
|
|
|



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Nottingham
Sent: Friday, October 14, 2005 11:28 AM
To: Antone Roundy
Cc: atom-syntax@imc.org
Subject: Re: Feed History -04


At first I really liked this proposal, but I think that the kind of  
confusion you're concerned about is unavoidable; the terms you refer  
to suffer "bottom-up" vs. "top-down."

I think that defining the terms well and in relation to the  
subscription feed will help; after all, the terms don't surface in  
UIs, so it should be transparent.


On 14/10/2005, at 10:37 AM, Antone Roundy wrote:

> Which brings me back to "top", "bottom", "up" and "down".  In the  
> OpenSearch case, it's clear which end the "top" results are going  
> to be found.  In the syndication feed case, the convention is to  
> put the most recent entries at the "top".  If you think of a feed  
> as a stack, new entries are stacked on "top".  The fact that these  
> terms are less generic and flexible than "previous" and "next" is  
> both an advantage and a disadvantage.  I think the question is  
> whether it's an advantage in a significant majority of cases or  
> not.  What orderings would those terms not work well for?


--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems



BEAWorld 2005: coming to a city near you.  Everything you need for SOA
and enterprise infrastructure success.

 
Register now at http://www.bea.com/4beaworld

 
London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct|
Beijing 7-8 Dec

Re: Feed History -04

[Stefan Eissing]

Am 14.10.2005 um 20:00 schrieb James Holderness:

Mark Nottingham wrote:
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:




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

Re: Feed History -04

[Mark Nottingham]

At first I really liked this proposal, but I think that the kind of  
confusion you're concerned about is unavoidable; the terms you refer  
to suffer "bottom-up" vs. "top-down."


I think that defining the terms well and in relation to the  
subscription feed will help; after all, the terms don't surface in  
UIs, so it should be transparent.



On 14/10/2005, at 10:37 AM, Antone Roundy wrote:

Which brings me back to "top", "bottom", "up" and "down".  In the  
OpenSearch case, it's clear which end the "top" results are going  
to be found.  In the syndication feed case, the convention is to  
put the most recent entries at the "top".  If you think of a feed  
as a stack, new entries are stacked on "top".  The fact that these  
terms are less generic and flexible than "previous" and "next" is  
both an advantage and a disadvantage.  I think the question is  
whether it's an advantage in a significant majority of cases or  
not.  What orderings would those terms not work well for?



--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems


BEAWorld 2005: coming to a city near you.  Everything you need for SOA and 
enterprise infrastructure success.


Register now at http://www.bea.com/4beaworld


London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 
Dec

Re: Feed History -04

[James Holderness]

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


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:




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

Re: Feed History -04

[Antone Roundy]

On Oct 14, 2005, at 11:28 AM, Thomas Broyer wrote:

Mark Nottingham wrote:

How about:



?

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


1. Isn't "a resource equivalent to the containing element" the same  
as "an alternate version of the resource described by the  
containing element"?
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).


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

Re: Feed History -04

[Antone Roundy]

On Oct 14, 2005, at 11:13 AM, Mark Nottingham wrote:

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.


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

Re: Feed History -04

[Mark Nottingham]

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:


Mark Nottingham wrote:


How about:



?

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



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

Re: Feed History -04

[Thomas Broyer]

Mark Nottingham wrote:

How about:



?
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

Re: Feed History -04

[Mark Nottingham]

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.


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



?


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

Re: Feed History -04

[Thomas Broyer]

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

RE: Feed History -04

[Lindsley Brett-ABL001]

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 PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of James Holderness
Sent: Friday, October 14, 2005 11:09 AM
To: Mark Nottingham; Antone Roundy
Cc: atom-syntax@imc.org
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

Re: Feed History -04

[James Holderness]

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

Re: Feed History -04

[A. Pagaltzis]

* Eric Scheid <[EMAIL PROTECTED]> [2005-10-14 17:35]:
> Why would anyone want to know the 'last' link? One use case is
> that one could take note of the 'last' URI, and then later find
> out what the 'last' URI now is ... and if they are different
> then obviously more has been added and it's time to go fetch.

If you really want this, don’t forget to to legislate this
expectation. Otherwise some people may devise clever (or
“clever”) stuff which breaks this expectation. Your example of
breaking

atom:[EMAIL PROTECTED]'self']/@href = atom:[EMAIL PROTECTED]'last']/@href

is a perfect demonstration of how someone may do something legal
that may break (naïve?) expectations.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Feed History -04

[Eric Scheid]

On 15/10/05 12:48 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote:

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

What if a magazine publishes articles only once per month, each month's
entries are all in one feed document, each feed document with unique URIs,
and the public 'self' URI simply redirects to the last feed document.


That is:

http://example.com/monthly/current.atom

redirects to 

http://example.com/monthly/2005-10.atom

Of course you can find the 'last' archive via the 'self' URI, but that
doesn't make them the same thing. If you were paging through using 'next',
how would you know you've reached the 'last' ... apart from running out of
'next' links, and apart from separately retrieving the 'self' URI and noting
the eventual URI handed back so you can compare against the one in 'last'.

Why would anyone want to know the 'last' link? One use case is that one
could take note of the 'last' URI, and then later find out what the 'last'
URI now is ... and if they are different then obviously more has been added
and it's time to go fetch.

e.

Re: Feed History -04

[Mark Nottingham]

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.


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.



On 13/10/2005, at 8:01 PM, Antone Roundy wrote:



On Oct 13, 2005, at 7:58 PM, Eric Scheid wrote:


On 14/10/05 9:18 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:




Excellent.  If this works out, there is an opportunity to merge the
paging behavior of Feed History, OpenSearch and APP collections  
into a

single set of paging link relations (next/previous/first/last).




'first' or 'start'?

Do we need to define what 'first' means though?  I recall a  
dissenting
opinion on the wiki that the 'first' entry could be at either end  
of the

list, which could surprise some.



Yeah, that's a good question.  Maybe calling them "top" and  
"bottom" would work better.  Considering that the convention is to  
put the newest entry at the top of a feed document, "top" might be  
more intuitively understandable as being the new end.  You might  
also rename "next" and "previous" (or is it "previous" and "next"?)  
to "down" and "up".  There's SOME chance of that getting confused  
with hierarchical levels, but I could live with that.







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

Re: Feed History -04

[Eric Scheid]

On 14/10/05 2:01 PM, "Joe Gregorio" <[EMAIL PROTECTED]> wrote:

> Eric,
>  It's like deja-vu all over again.
> 
> http://bitworking.org/news/Atom_Auto_Sub_How_To
> 
>  :)

I'd forgotten about that, I was only remembering the wiki.

I still think it odd that one could traverse both "prev" and "next" from the
"start". In the context of paging link relations (first/next/prev/last) I
would've thought that 'first' and 'last' are boundaries, and only the 'last'
boundary would shift over time as more is added.

e.

Re: Feed History -04

[Joe Gregorio]

On 10/13/05, Eric Scheid <[EMAIL PROTECTED]> wrote:
>
> On 14/10/05 9:18 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
>
> > Excellent.  If this works out, there is an opportunity to merge the
> > paging behavior of Feed History, OpenSearch and APP collections into a
> > single set of paging link relations (next/previous/first/last).
>
> 'first' or 'start'?
>
> Do we need to define what 'first' means though?  I recall a dissenting
> opinion on the wiki that the 'first' entry could be at either end of the
> list, which could surprise some.

Eric,
   It's like deja-vu all over again.

 http://bitworking.org/news/Atom_Auto_Sub_How_To

   :)

   -joe

--
Joe Gregoriohttp://bitworking.org

Re: Feed History -04

[A. Pagaltzis]

* Antone Roundy <[EMAIL PROTECTED]> [2005-10-14 05:10]:
> On Oct 13, 2005, at 7:58 PM, Eric Scheid wrote:
> >Do we need to define what 'first' means though?  I recall a
> >dissenting opinion on the wiki that the 'first' entry could be
> >at either end of the list, which could surprise some.
> 
> Yeah, that's a good question. Maybe calling them "top" and
> "bottom" would work better. Considering that the convention
> is to put the newest entry at the top of a feed document,
> "top" might be more intuitively understandable as being the
> new end. You might also rename "next" and "previous" (or is
> it "previous" and "next"?) to "down" and "up". There's SOME
> chance of that getting confused with hierarchical levels, but
> I could live with that.

'inaugural' and 'latest'? :-)

Regards,
-- 
Aristotle Pagaltzis // 

Re: Feed History -04

[Antone Roundy]

On Oct 13, 2005, at 7:58 PM, Eric Scheid wrote:

On 14/10/05 9:18 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:



Excellent.  If this works out, there is an opportunity to merge the
paging behavior of Feed History, OpenSearch and APP collections  
into a

single set of paging link relations (next/previous/first/last).



'first' or 'start'?

Do we need to define what 'first' means though?  I recall a dissenting
opinion on the wiki that the 'first' entry could be at either end  
of the

list, which could surprise some.


Yeah, that's a good question.  Maybe calling them "top" and "bottom"  
would work better.  Considering that the convention is to put the  
newest entry at the top of a feed document, "top" might be more  
intuitively understandable as being the new end.  You might also  
rename "next" and "previous" (or is it "previous" and "next"?) to  
"down" and "up".  There's SOME chance of that getting confused with  
hierarchical levels, but I could live with that.

Re: Feed History -04

[Eric Scheid]

On 14/10/05 9:18 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:

> Excellent.  If this works out, there is an opportunity to merge the
> paging behavior of Feed History, OpenSearch and APP collections into a
> single set of paging link relations (next/previous/first/last).

'first' or 'start'?

Do we need to define what 'first' means though?  I recall a dissenting
opinion on the wiki that the 'first' entry could be at either end of the
list, which could surprise some.

e.

Re: Feed History -04

[James M Snell]

Excellent.  If this works out, there is an opportunity to merge the 
paging behavior of Feed History, OpenSearch and APP collections into a 
single set of paging link relations (next/previous/first/last).


Mark Nottingham wrote:

I've been considering moving feed history over to atom:link, but  
wanted to check with people who are currently using / referring to  
it, as well as with the RSS communities. Please give me a little time.



On 09/10/2005, at 9:06 PM, James M Snell wrote:




I've been considering asking the Opensearch folks if they would be  
willing to separate their next/previous/first/last link relations  
out to a separate spec that could be made a working group draft.   
The paging functionality they offer provides a solution to paging  in 
the protocol and are generally useful across a broad variety of  feed 
application cases.  Regardless, it would be very good to see  these 
registered.


- James

James Holderness wrote:





In case anyone is interested, the OpenSearch Response draft can be  
found here:


http://opensearch.a9.com/spec/opensearchresponse/1.1/

The rel values they support include next, previous (not prev),  
start and end. They have a note next to each saying "This value is  
pending IETF registration". Does that mean they've actually  started 
some kind of registration process or they're just hoping  to do so 
at some point in the future?


Another issue worth noting is that their example RSS feed is also  
using atom:link to provide this functionality.


Robert Sayre wrote:



No, but Amazon OpenSearch has been threatening to register it,  
FWIW. :)

















--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems



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

Re: Feed History -04

[Mark Nottingham]

I've been considering moving feed history over to atom:link, but  
wanted to check with people who are currently using / referring to  
it, as well as with the RSS communities. Please give me a little time.



On 09/10/2005, at 9:06 PM, James M Snell wrote:




I've been considering asking the Opensearch folks if they would be  
willing to separate their next/previous/first/last link relations  
out to a separate spec that could be made a working group draft.   
The paging functionality they offer provides a solution to paging  
in the protocol and are generally useful across a broad variety of  
feed application cases.  Regardless, it would be very good to see  
these registered.


- James

James Holderness wrote:





In case anyone is interested, the OpenSearch Response draft can be  
found here:


http://opensearch.a9.com/spec/opensearchresponse/1.1/

The rel values they support include next, previous (not prev),  
start and end. They have a note next to each saying "This value is  
pending IETF registration". Does that mean they've actually  
started some kind of registration process or they're just hoping  
to do so at some point in the future?


Another issue worth noting is that their example RSS feed is also  
using atom:link to provide this functionality.


Robert Sayre wrote:



No, but Amazon OpenSearch has been threatening to register it,  
FWIW. :)

















--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems



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

RE: Feed History -04

[Byrne Reese]

+1

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of James M Snell
Sent: Sunday, October 09, 2005 9:06 PM
To: James Holderness
Cc: Syntax Atom
Subject: Re: Feed History -04


I've been considering asking the Opensearch folks if they would be 
willing to separate their next/previous/first/last link relations out to

a separate spec that could be made a working group draft.  The paging 
functionality they offer provides a solution to paging in the protocol 
and are generally useful across a broad variety of feed application 
cases.  Regardless, it would be very good to see these registered.

- James

Re: Feed History -04

[Joe Gregorio]

On 10/10/05, James M Snell <[EMAIL PROTECTED]> wrote:
>
> I've been considering asking the Opensearch folks if they would be
> willing to separate their next/previous/first/last link relations out to
> a separate spec that could be made a working group draft.  The paging
> functionality they offer provides a solution to paging in the protocol
> and are generally useful across a broad variety of feed application
> cases.  Regardless, it would be very good to see these registered.

+1

-joe

--
Joe Gregoriohttp://bitworking.org

RE: Feed History -04

[Byrne Reese]

I was wondering if someone might be able to summarize the issues
associated with a  and ? What were
the primary objections?

I ask because it seems like a very logical core component for the spec,
especially as a link relation.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of James M Snell
Sent: Sunday, October 09, 2005 9:06 PM
To: James Holderness
Cc: Syntax Atom
Subject: Re: Feed History -04


I've been considering asking the Opensearch folks if they would be 
willing to separate their next/previous/first/last link relations out to

a separate spec that could be made a working group draft.  The paging 
functionality they offer provides a solution to paging in the protocol 
and are generally useful across a broad variety of feed application 
cases.  Regardless, it would be very good to see these registered.

- James

James Holderness wrote:

>
> In case anyone is interested, the OpenSearch Response draft can be 
> found here:
>
> http://opensearch.a9.com/spec/opensearchresponse/1.1/
>
> The rel values they support include next, previous (not prev), start 
> and end. They have a note next to each saying "This value is pending 
> IETF registration". Does that mean they've actually started some kind 
> of registration process or they're just hoping to do so at some point 
> in the future?
>
> Another issue worth noting is that their example RSS feed is also 
> using atom:link to provide this functionality.
>
> Robert Sayre wrote:
>
>> No, but Amazon OpenSearch has been threatening to register it, FWIW.
:)
>
>
>

Re: Feed History -04

[James M Snell]

I've been considering asking the Opensearch folks if they would be 
willing to separate their next/previous/first/last link relations out to 
a separate spec that could be made a working group draft.  The paging 
functionality they offer provides a solution to paging in the protocol 
and are generally useful across a broad variety of feed application 
cases.  Regardless, it would be very good to see these registered.


- James

James Holderness wrote:



In case anyone is interested, the OpenSearch Response draft can be 
found here:


http://opensearch.a9.com/spec/opensearchresponse/1.1/

The rel values they support include next, previous (not prev), start 
and end. They have a note next to each saying "This value is pending 
IETF registration". Does that mean they've actually started some kind 
of registration process or they're just hoping to do so at some point 
in the future?


Another issue worth noting is that their example RSS feed is also 
using atom:link to provide this functionality.


Robert Sayre wrote:


No, but Amazon OpenSearch has been threatening to register it, FWIW. :)

Re: Feed History -04

[James M Snell]

I don't think not using the URI is a problem so long as the intent is to 
register the value and you make an attempt at standardization.  The 
problems arise when folks use names when they have no intention of 
standardizing or registering.


- James

Mark Nottingham wrote:



Looks like the whole "use URIs for non-registered values" approach  
has already gone by the wayside. Oh, well.


Next time, it should just be URIs, period -- no shortcuts.


On 09/10/2005, at 3:41 PM, James Holderness wrote:


They have a note next to each saying "This value is pending IETF  
registration". Does that mean they've actually started some kind of  
registration process or they're just hoping to do so at some point  
in the future?




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

Re: Feed History -04

[Mark Nottingham]

Looks like the whole "use URIs for non-registered values" approach  
has already gone by the wayside. Oh, well.


Next time, it should just be URIs, period -- no shortcuts.


On 09/10/2005, at 3:41 PM, James Holderness wrote:


They have a note next to each saying "This value is pending IETF  
registration". Does that mean they've actually started some kind of  
registration process or they're just hoping to do so at some point  
in the future?



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

Re: Feed History -04

[James Holderness]

In case anyone is interested, the OpenSearch Response draft can be found 
here:


http://opensearch.a9.com/spec/opensearchresponse/1.1/

The rel values they support include next, previous (not prev), start and 
end. They have a note next to each saying "This value is pending IETF 
registration". Does that mean they've actually started some kind of 
registration process or they're just hoping to do so at some point in the 
future?


Another issue worth noting is that their example RSS feed is also using 
atom:link to provide this functionality.


Robert Sayre wrote:

No, but Amazon OpenSearch has been threatening to register it, FWIW. :)

Re: Feed History -04

[Robert Sayre]

On 10/9/05, Mark Nottingham <[EMAIL PROTECTED]> wrote:
>
> The format doesn't reference the API document any more,

That's good.

> and the
> current API document  atompub-protocol-04.txt> doesn't include anything about that link
> relation; it was removed.

No, but Amazon OpenSearch has been threatening to register it, FWIW. :)

Robert Sayre

Re: Feed History -04

[Mark Nottingham]

The format doesn't reference the API document any more, and the  
current API document  doesn't include anything about that link  
relation; it was removed.



On 09/10/2005, at 12:02 PM, Joe Gregorio wrote:



On 10/9/05, Henry Story <[EMAIL PROTECTED]> wrote:



It occurred to me that I should think a little more before speaking.

There seems to be a history of the atom spec here:

http://bitworking.org/projects/atom/

I could not find the prev link in any of the specs. So I guess I was
mistaken.



It's in there:

  http://bitworking.org/projects/atom/draft- 
gregorio-09.html#rfc.section.5.4.1


So -1 to draft-nottingham-atompub-feed-history-04.txt for not using
a link tag of rel="prev".

   -joe

--
Joe Gregoriohttp://bitworking.org






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

Re: Feed History -04

[Joe Gregorio]

On 10/9/05, Henry Story <[EMAIL PROTECTED]> wrote:
>
> It occurred to me that I should think a little more before speaking.
>
> There seems to be a history of the atom spec here:
>
> http://bitworking.org/projects/atom/
>
> I could not find the prev link in any of the specs. So I guess I was
> mistaken.

It's in there:

  http://bitworking.org/projects/atom/draft-gregorio-09.html#rfc.section.5.4.1

So -1 to draft-nottingham-atompub-feed-history-04.txt for not using
a link tag of rel="prev".

   -joe

--
Joe Gregoriohttp://bitworking.org

Re: Feed History -04

[Mark Nottingham]

"Managing Feed State" was a placeholder I put in the original Atom  
spec draft  for just this kind of discussion. The  
WG couldn't come to a consensus on a mechanism (my proposal was  
), so we removed  
that section (earlier this year, IIRC).


On 09/10/2005, at 1:39 AM, James Holderness wrote:




Following up on the idea of using atom:link instead of fh:prev, I  
recently came across an old article by Mark Pilgrim on XML.com  
(http://www.xml.com/pub/a/2004/06/16/dive.html) in which he  
discusses the atom:link element and the various rel attributes it  
supports. He specifically brings up the issue of feed history and  
using next and prev to link archives together.


It sounded to me as if he was talking about an existing feature in  
the spec - it wasn't like he was proposing it as a new idea. So was  
this something that used to be part of an old version of the spec  
that was later removed? Or was this an early proposal that was  
never accepted into the spec?


Also of interest: there's a link from that article to his archives  
on diveintomark.org which actually include next and prev links in  
the feed. I'm almost inclined to add support for that just so I can  
access those old posts. There used to be some excellent articles on  
his site.








--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems



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

Re: Feed History -04

[James Holderness]

Funny you should say that. When you told me it was part of Atom 0.3 I also 
thought to myself that I should have checked that before posting. 
Technically you were correct. Version 0.3 of the syndication format doesn't 
mention next and prev explicitly, but it does say (in section 3.4.1) that 
the rel attribute "must be one of the values enumerated in the API 
specification". And at the time the API specification included (amongst 
others) start, next and prev. They were only recently removed (in 
draft-ietf-atompub-protocol-03). If you look at the draft prior to that 
you'll find them in section 3.5.1.


Regards
James

Henry Story wrote:

It occurred to me that I should think a little more before speaking.

There seems to be a history of the atom spec here:

http://bitworking.org/projects/atom/

I could not find the prev link in any of the specs. So I guess I was 
mistaken. 

Re: Feed History -04

[Henry Story]

It occurred to me that I should think a little more before speaking.

There seems to be a history of the atom spec here:

http://bitworking.org/projects/atom/

I could not find the prev link in any of the specs. So I guess I was  
mistaken.
But I also always thought of prev and next as being very good  
candidates for
the link element.  I never raised my voice against the move at the  
time because

I assumed most decisions on this list were good ones.

There is one reference to prev and next here:
http://www.intertwingly.net/wiki/pie/LinkTagMeaning


Henry

On 9 Oct 2005, at 10:47, Henry Story wrote:


I believe it was part of atom 0.3, and for some complex reason I never
bothered trying to understand someone decided it should be moved  
over to
the protocol side of things. Probably just because the debate was  
taking up

too much time...

So yes. 'prev' and 'next' have always been intended to be there in  
the link element...


Henry

On 9 Oct 2005, at 10:39, James Holderness wrote:



Following up on the idea of using atom:link instead of fh:prev, I  
recently came across an old article by Mark Pilgrim on XML.com  
(http://www.xml.com/pub/a/2004/06/16/dive.html) in which he  
discusses the atom:link element and the various rel attributes it  
supports. He specifically brings up the issue of feed history and  
using next and prev to link archives together.


It sounded to me as if he was talking about an existing feature in  
the spec - it wasn't like he was proposing it as a new idea. So  
was this something that used to be part of an old version of the  
spec that was later removed? Or was this an early proposal that  
was never accepted into the spec?


Also of interest: there's a link from that article to his archives  
on diveintomark.org which actually include next and prev links in  
the feed. I'm almost inclined to add support for that just so I  
can access those old posts. There used to be some excellent  
articles on his site.

Re: Feed History -04

[Henry Story]

I believe it was part of atom 0.3, and for some complex reason I never
bothered trying to understand someone decided it should be moved over to
the protocol side of things. Probably just because the debate was  
taking up

too much time...

So yes. 'prev' and 'next' have always been intended to be there in  
the link element...


Henry

On 9 Oct 2005, at 10:39, James Holderness wrote:


Following up on the idea of using atom:link instead of fh:prev, I  
recently came across an old article by Mark Pilgrim on XML.com  
(http://www.xml.com/pub/a/2004/06/16/dive.html) in which he  
discusses the atom:link element and the various rel attributes it  
supports. He specifically brings up the issue of feed history and  
using next and prev to link archives together.


It sounded to me as if he was talking about an existing feature in  
the spec - it wasn't like he was proposing it as a new idea. So was  
this something that used to be part of an old version of the spec  
that was later removed? Or was this an early proposal that was  
never accepted into the spec?


Also of interest: there's a link from that article to his archives  
on diveintomark.org which actually include next and prev links in  
the feed. I'm almost inclined to add support for that just so I can  
access those old posts. There used to be some excellent articles on  
his site.

Re: Feed History -04

[James Holderness]

Following up on the idea of using atom:link instead of fh:prev, I recently 
came across an old article by Mark Pilgrim on XML.com 
(http://www.xml.com/pub/a/2004/06/16/dive.html) in which he discusses the 
atom:link element and the various rel attributes it supports. He 
specifically brings up the issue of feed history and using next and prev to 
link archives together.


It sounded to me as if he was talking about an existing feature in the 
spec - it wasn't like he was proposing it as a new idea. So was this 
something that used to be part of an old version of the spec that was later 
removed? Or was this an early proposal that was never accepted into the 
spec?


Also of interest: there's a link from that article to his archives on 
diveintomark.org which actually include next and prev links in the feed. I'm 
almost inclined to add support for that just so I can access those old 
posts. There used to be some excellent articles on his site.

Re: Feed History -04

[Ian Davis]

On 01/10/2005 01:05, James Holderness wrote:


Mark Nottingham wrote:
Thanks for the feedback. As I've explained before, I have a pretty  
strong preference for the current design, to make it usable in other  
formats; i.e., the scope of this is not just Atom (which is why I'm  
probably going to do it as an Individual submission).


At first I thought this was a good idea, but I'm starting to have second 
thoughts. The spec as it stands is fine for RSS 2, but I can see a lot 
of Atom people thinking that you should be using atom:link (as Henry 
suggested) and not wanting to "corrupt" their nice new format. No doubt 
the RSS 1 folks have their own preference for where this should be going 
and will probably be even more adamant that you do things the correct 
way (not sure what that might be - something using dc:relation maybe?) I 
would worry that if they don't like it, they won't use it.


I think the RSS 1.0 folks would be happiest with a self-contained 
extension in its own namespace with each term having clear unambiguous 
semantics. I think Mark's design achieves this.


Ian
--
http://internetalchemy.org | http://purl.org/NET/iand
Working on... Silkworm 

Re: Feed History -04

[James Holderness]

Luke Arno wrote:

No, it is not wrong to use atom:link in RSS2.  There is existing
precedence for this and it really does make a whole lot of sense.



yup.

http://opensearch.a9.com/spec/opensearchresponse/1.1/

for instance.


Also used in the Universal Subscription Mechanism:

http://www.kbcafe.com/rss/usm.html

Re: Feed History -04

[Luke Arno]

On 10/2/05, James M Snell <[EMAIL PROTECTED]> wrote:
>
> Peter Robinson wrote:
>
> >As far as the question at hand, I would be able to implent it in my
> >Atom/RSS2 feed generator easily enough either way.  Obviously it will be
> >a small amount of extra work if there is a format-dependent difference.
> >Playing devil's advocate for a minute, is it very wrong to use atom:link
> >for feed history in *RSS2*?
> >
> >
> >
> No, it is not wrong to use atom:link in RSS2.  There is existing
> precedence for this and it really does make a whole lot of sense.
>

yup.

http://opensearch.a9.com/spec/opensearchresponse/1.1/

for instance.

- Luke

Re: Feed History -04

[James M Snell]

Peter Robinson wrote:


As far as the question at hand, I would be able to implent it in my
Atom/RSS2 feed generator easily enough either way.  Obviously it will be
a small amount of extra work if there is a format-dependent difference.
Playing devil's advocate for a minute, is it very wrong to use atom:link
for feed history in *RSS2*?

 

No, it is not wrong to use atom:link in RSS2.  There is existing 
precedence for this and it really does make a whole lot of sense.


- James

Re: Feed History -04

[Peter Robinson]

James Holderness <[EMAIL PROTECTED]> wrote:

[About feed history and atom:link vs. fh:prev]

> I'm surprised nobody else has commented though. To me this seems like one of
> the most important extensions to Atom/RSS, and yet there aren't exactly
> hordes of people rushing to implement it or at least committing to do
> something once it's officially released. Or have I just missed previous
> discussions on the subject?

As a feed producer, I would love for feed consumers to be able to pull
back the history of my feeds if they choose.  But unfortunately seeing
the way this discussion is going, and the (for me) closely related
ordering extension, I'm not convinced I will be able to use them.

Of couse if you don't turn up, you don't get to complain about decisions
that get made, and unfortunately I don't have as much time as I'd like
to participate in these discusions.  But it's not that I don't care.

As far as the question at hand, I would be able to implent it in my
Atom/RSS2 feed generator easily enough either way.  Obviously it will be
a small amount of extra work if there is a format-dependent difference.
Playing devil's advocate for a minute, is it very wrong to use atom:link
for feed history in *RSS2*?

Regards,

Peter
-- 
Peter Robinson

Re: Feed History -04

[James Holderness]

Mark Nottingham wrote:
Thanks for the feedback. As I've explained before, I have a pretty  strong 
preference for the current design, to make it usable in other  formats; 
i.e., the scope of this is not just Atom (which is why I'm  probably going 
to do it as an Individual submission).


At first I thought this was a good idea, but I'm starting to have second 
thoughts. The spec as it stands is fine for RSS 2, but I can see a lot of 
Atom people thinking that you should be using atom:link (as Henry suggested) 
and not wanting to "corrupt" their nice new format. No doubt the RSS 1 folks 
have their own preference for where this should be going and will probably 
be even more adamant that you do things the correct way (not sure what that 
might be - something using dc:relation maybe?) I would worry that if they 
don't like it, they won't use it.


implementors to special-case their code; i.e., they'd have to look  for 
one element if it's an RSS feed, and a different element if it's  an Atom 
feed. I know this is already done widely, but I see no reason  to 
artificially require the practice here. However, if a number of 
implementors stand up and say that they wouldn't mind such a special 
case, and no one is against it, I'd make the change.


I'm not exactly a high profile implementor, so my opinion may not matter 
much, but I personally wouldn't have a problem with it. I already keep the 
Atom code separate from RSS with the hope that one day the RSS can be thrown 
away, so this really wouldn't affect me at all.


I'm surprised nobody else has commented though. To me this seems like one of 
the most important extensions to Atom/RSS, and yet there aren't exactly 
hordes of people rushing to implement it or at least committing to do 
something once it's officially released. Or have I just missed previous 
discussions on the subject?


Regards
James