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.
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.
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/
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
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
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 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
15 matches
Mail list logo
