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

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

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


Reply via email to