I know this was directed to Robert, but I'd like to throw my $.02 in.
Generally speaking, if the semantic difference between the use of
next/prev in one feed relative to another can be expressed using a
separate extension (e.g. the presence of an incremental=true or a
profile attribute or whatever else may come up, then I would favor the
use of the generic mechanism assuming that the basic function is the same.
- James
Mark Nottingham wrote:
Robert,
It's a matter of personal preference as to whether one likes 'prev'
or 'next'; if there had been wide implementation and a good
specification of what MarkP did, I could see a strong argument for
using it.
As it is, no one has even noticed it had similarity to this proposal
until a few days ago, and it looks like there are a number of people
who have strong feelings each way.
OTOH, how specific the relation is *is* a technical issue; could you
expand on what you see as the 'tower of babel' problem?
My concern is that if there is more than one use of a link relation
like 'next' or 'prev', those uses could conflict. For example, if I
use 'prev' for Feed History, will that cause a problem with feeds
using Amazon OpenSearch if they want to use it in a slightly
different way? To put it in Thomas' terms, what if there are
different concepts of paging using the same terms -- which there seem
to be already?
This shows up perfectly with the whole "next or previous?"
discussion. If we don't assign specific, functional semantics to the
links, people will interpret -- and use -- them differently.
This is why I'm leaning towards "prev-archive".
On 17/10/2005, at 1:15 PM, Robert Sayre wrote:
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
--
Mark Nottingham http://www.mnot.net/
