As I said before, if the WG can reach consensus, I'm happy
with any old term. I hadn't seen Mark's proposal till a few
days ago, and a mention in an xml.com does not, in my
opinion, a spec-in-stone make.
My only pushback on next is that to me, it seems counterintuititive
-- same as
On 10/17/05, Mark Nottingham [EMAIL PROTECTED] wrote:
Robert,
It's a matter of personal preference as to whether one likes 'prev'
or 'next';
...
My concern is that if there is more than one use of a link relation
like 'next' or 'prev', those uses could conflict.
...
This is why I'm leaning
On 18/10/05 3:32 PM, Mark Nottingham [EMAIL PROTECTED] wrote:
Such agents should also take care to detect circular
references between feeds when following them.
s/between feeds when/between feed documents/
otherwise +1
e.
Antone Roundy wrote:
If the complete set represents all the entries ever published
through an ever-changing feed document (what a feed currently is,
you subscribe with an URI and the document you get when
dereferencing the URI changes as a sliding-window upon a set of
entries), then paging
On 18/10/05 6:14 PM, Thomas Broyer [EMAIL PROTECTED] wrote:
Yes, and navigating through the historical states of the feed resource is
not paging, it's more like having access to archives.
I was thinking about proposing yet another link relation archives: in
the general use case, it would
On 18/10/05 5:51 PM, Thomas Broyer [EMAIL PROTECTED] wrote:
How can there be more than one paging semantic applied to a single feed?
If a feed (not feed document) is a set of entries (sorted by whatever
metadata: updated, priority, relevance, etc.) and you publish chunks as
many feed
On 10/18/05, Mark Nottingham [EMAIL PROTECTED] wrote:
Requiring a separate element to always be present is a non-starter;
what is the point of a reusable link relation if you have to use it
with another element to contextualise it? I'm really stretching to
see any benefit from this approach.
Thomas Broyer wrote:
Mark Nottingham wrote:
They seem similar. But, what if you want to have more than one paging
semantic applied to a single feed, and those uses of paging don't
align? I.e., there's contention for prev/next?
How can there be more than one paging semantic applied
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
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
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
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
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
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
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
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
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
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
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.
geeking
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
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
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
+%
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.
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
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
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
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,
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
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
Good point.
On 17/10/2005, at 2:54 PM, James M Snell wrote:
+1. An additional security concern would be the potential for
circular references
--
Mark Nottingham http://www.mnot.net/
On 10/17/05, Mark Nottingham [EMAIL PROTECTED] 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.
I think the spec is
Mark Nottingham wrote:
- Attribute Value: prev
- Description: A stable URI that, when dereferenced, returns a feed
document containing entries that sequentially precede those in the
current document. Note that the exact nature of the ordering between
the entries and documents containing them
Thomas Broyer wrote:
- Attribute Value: subscribe
- Description: A stable URI that, when dereferenced, returns a feed
document containing the most recent entries in the feed. This URI is
intended to be subscribed to to keep abreast of changes in the feed.
When different from the URI of the
They seem similar. But, what if you want to have more than one paging
semantic applied to a single feed, and those uses of paging don't
align? I.e., there's contention for prev/next?
If no one shares my concern, I'll drop it... as long as I get to say
I told you so if/when this problem
Mark Nottingham wrote:
They seem similar. But, what if you want to have more than one paging
semantic applied to a single feed, and those uses of paging don't
align? I.e., there's contention for prev/next?
If no one shares my concern, I'll drop it... as long as I get to say
I told you
Mark Nottingham wrote:
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
Robert,
As I said before, if the WG can reach consensus, I'm happy with any
old term. I hadn't seen Mark's proposal till a few days ago, and a
mention in an xml.com does not, in my opinion, a spec-in-stone make.
My only pushback on next is that to me, it seems counterintuititive
--
On 17/10/2005, at 4:07 PM, Thomas Broyer wrote:
- Attribute Value: first
- Description: A stable URI that, when dereferenced, returns a
feed document containing those entries furthest preceding those in
the current document at the time it was minted. Note that the
exact nature of the
Mark Nottingham wrote:
A stable URI was intended to capture that, but I see that wasn't
good enough. How about:
- Attribute Value: first
- Description: A stable URI that, when dereferenced, returns a feed
document containing the set of entries furthest preceding those in
the current
On 10/17/05, Mark Nottingham [EMAIL PROTECTED] wrote:
The SixApart people have publicly pointed to FH,
Cool!
so I don't think
they're particularly fussed about any particular approach other (not
to put words in their mouth).
Did you miss Byrne's post?
So what happens when you need the rel=self (as currently defined)
of an archive feed?
On 17/10/2005, at 4:28 PM, Eric Scheid wrote:
On 18/10/05 9:07 AM, Thomas Broyer [EMAIL PROTECTED] wrote:
Depends whether @rel=self was really meant for subscribing and the
spec wording is not
Mark Nottingham wrote:
The intent here was to say that the *set* of entries is generally
stable, not that they're set in stone. That's what you want, no? If
so, how about:
- Attribute Value: first
- Description: A stable URI that, when dereferenced, returns a feed
document containing
On Oct 17, 2005, at 5:17 PM, Mark Nottingham wrote:
They seem similar. But, what if you want to have more than one
paging semantic applied to a single feed, and those uses of paging
don't align? I.e., there's contention for prev/next?
If no one shares my concern, I'll drop it... as long as
On 18/10/05 9:53 AM, Mark Nottingham [EMAIL PROTECTED] wrote:
So what happens when you need the rel=self (as currently defined)
of an archive feed?
The current definition being ...
The value self signifies that the IRI in the value of the href
attribute identifies a resource
On Oct 17, 2005, at 3:44 PM, Mark Nottingham wrote:
On 17/10/2005, at 12:31 PM, James M Snell wrote:
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-
Antone Roundy wrote:
On Oct 17, 2005, at 3:44 PM, Mark Nottingham wrote:
On 17/10/2005, at 12:31 PM, James M Snell wrote:
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
On Oct 17, 2005, at 10:17 PM, James M Snell wrote:
When I think of next/prev I'm not thinking about any form of
temporal semantic. I'm thinking about nothing more than a linked
list of feed documents. If you want to add a temporal semantic
into the picture, use a mechanism such as the
Requiring a separate element to always be present is a non-starter;
what is the point of a reusable link relation if you have to use it
with another element to contextualise it? I'm really stretching to
see any benefit from this approach.
prev-archive (or maybe prev-entries?) is starting
+1
On 17/10/2005, at 7:57 PM, Eric Scheid wrote:
On 18/10/05 9:53 AM, Mark Nottingham [EMAIL PROTECTED]
wrote:
So what happens when you need the rel=self (as currently defined)
of an archive feed?
The current definition being ...
The value self signifies that the IRI in the
Scheid [EMAIL PROTECTED]
Cc: Atom Syntax atom-syntax@imc.org
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
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
: Mark Nottingham [EMAIL PROTECTED]
To: Eric Scheid [EMAIL PROTECTED]
Cc: Atom Syntax atom-syntax@imc.org
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
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
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
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,
* 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
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
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
Mark Nottingham wrote:
How about:
atom:link rel=subscription href=.../
?
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
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
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
On Oct 14, 2005, at 11:28 AM, Thomas Broyer wrote:
Mark Nottingham wrote:
How about:
atom:link rel=subscription href=.../
?
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
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
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
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
: 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
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
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
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
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
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
* 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 // http://plasmasturm.org/
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,
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)
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
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
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
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
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
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
: [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
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
+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
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
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
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
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
* 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,
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
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
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
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
Managing Feed State was a placeholder I put in the original Atom
spec draft http://www.mnot.net/drafts/draft-nottingham-atom-
format-00.html#rfc.section.4 for just this kind of discussion. The
WG couldn't come to a consensus on a mechanism (my proposal was
.
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
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 http://www.ietf.org/internet-drafts/draft-ietf-
atompub-protocol-04.txt doesn't include anything about that link
relation; it was removed.
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.
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
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
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
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
1 - 100 of 113 matches
Mail list logo
