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 <atom-syntax@imc.org>
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
