Subject: RE: Feed History -04

From: "Byrne Reese" <[email-masked]>
Date: Thu, 13 Oct 2005 13:28:45 -0400

I was wondering if someone might be able to summarize the issues
associated with a <link rel="next"> and <link rel="previous">? 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-masked]
[mailto:[email-masked]] 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.
:)

---

From: "Byrne Reese" <[email-masked]>
Date: Thu, 13 Oct 2005 15:50:03 -0400

+1

-----Original Message-----

- James

---

From: "Byrne Reese" <[email-masked]>
Date: Fri, 14 Oct 2005 16:04:14 -0400

+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-masked]
[mailto:[email-masked]] On Behalf Of Mark Nottingham
Sent: Friday, October 14, 2005 11:28 AM
To: Antone Roundy
Cc: [email-masked]
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

---

From: "Byrne Reese" <[email-masked]>
Date: Fri, 14 Oct 2005 16:20:15 -0400

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

<link rel="next" href="foo?31-40" />
<link rel="previous" href="foo?1-10" />
<result-set>
  <size>10</limit>
  <start>21</start>
  <end>30</end>
  <total>55</total>
  <sort>/feed/entry/published</sort>
  <order>ascending</order>
</result-set>