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
I think the navigation elements of
draft-nottingham-atompub-feed-history-04.txt overlap with Atom
protocol navigation and deployed APP beta implementations. In fact, I
pointed this out way back in April 2005. I don't think anything has
changed.
In http://www.mnot.net/blog/2005/04/12/feed_state
Can you substantiate that with links to the appropriate portions of
the current protocol draft?
On 18/10/2005, at 9:40 AM, Robert Sayre wrote:
I think the navigation elements of
draft-nottingham-atompub-feed-history-04.txt overlap with Atom
protocol navigation and deployed APP beta
On 10/18/05, Mark Nottingham [EMAIL PROTECTED] wrote:
Can you substantiate that with links to the appropriate portions of
the current protocol draft?
Oh that's odd. They've gone and deleted them. I can tell you that my
general impression of the current atom-protocol list was that we would
OK, well, I'm not terribly fussed by who registers them, but they
need to be carefully defined, and it wasn't at all clear that the
OpenSearch document did that.
Considering that there's a need for them sooner rather than later,
would you have a problem with registering the link
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
On 10/18/05, Mark Nottingham [EMAIL PROTECTED] wrote:
OK, well, I'm not terribly fussed by who registers them, but they
need to be carefully defined, and it wasn't at all clear that the
OpenSearch document did that.
I think maybe we have a difference of opinion on what's needed here.
On 18/10/2005, at 11:38 AM, Robert Sayre wrote:
OK, well, I'm not terribly fussed by who registers them, but they
need to be carefully defined, and it wasn't at all clear that the
OpenSearch document did that.
I think maybe we have a difference of opinion on what's needed here.
Could you
On 10/18/05, Mark Nottingham [EMAIL PROTECTED] wrote:
On 18/10/2005, at 11:38 AM, Robert Sayre wrote:
OK, well, I'm not terribly fussed by who registers them, but they
need to be carefully defined, and it wasn't at all clear that the
OpenSearch document did that.
I think maybe we
I'm confused; the current proposal (below) doesn't have that text in
it; for example, the definition of previous is:
A stable URI that, when dereferenced, returns a feed document
containing a set of entries that sequentially precede those in the
current document. This can be thought of
On 10/18/05, Mark Nottingham [EMAIL PROTECTED] wrote:
I'm confused; the current proposal (below) doesn't have that text in
it; for example, the definition of previous is:
OK, then I am confused.
A stable URI that, when dereferenced, returns a feed document
containing a set of entries
Robert Sayre wrote:
[about the previous link relation]
A stable URI that, when dereferenced, returns a feed document
containing a set of entries that sequentially precede those in the
current document.
I already have code that uses next for this. Why do we want to change it?
Er,
On 18/10/2005, at 12:38 PM, Robert Sayre wrote:
A stable URI that, when dereferenced, returns a feed document
containing a set of entries that sequentially precede those in the
current document.
I already have code that uses next for this. Why do we want to
change it?
Why would your
Please disambiguate original.
On 18/10/2005, at 12:49 PM, James M Snell wrote:
+1 on all of Roberts comments. While I'm ok with the current
version, I was much happier with the original.
Robert Sayre wrote:
On 10/18/05, Mark Nottingham [EMAIL PROTECTED] wrote:
I'm confused; the
On 10/18/05, Mark Nottingham [EMAIL PROTECTED] wrote:
2.) I still don't see how this helps me write a client.
What are you looking for? People said they wanted to use atom:link,
so I'm trying to accommodate that. People said they wanted the
relations to be generic, so I'm trying to
Antone Roundy wrote:
On Oct 18, 2005, at 5:13 PM, Robert Sayre wrote:
On 10/18/05, Mark Nottingham [EMAIL PROTECTED] wrote:
rel: next
definition: A URI that points to the next feed in a series of feeds.
For example, in a reverse-choronological series of feeds, the 'next'
URI would point
On 19/10/05 5:38 AM, Robert Sayre [EMAIL PROTECTED] wrote:
I already have code that uses next for this. Why do we want to change it?
Why did you choose next?
e.
On 10/18/05, Eric Scheid [EMAIL PROTECTED] wrote:
On 19/10/05 5:38 AM, Robert Sayre [EMAIL PROTECTED] wrote:
I already have code that uses next for this. Why do we want to change it?
Why did you choose next?
Because that is what's already been deployed and what my software uses.
Robert
On 19/10/05 9:13 AM, Robert Sayre [EMAIL PROTECTED] wrote:
rel: next
definition: A URI that points to the next feed in a series of feeds.
For example, in a reverse-choronological series of feeds, the 'next'
URI would point deeper into the past.
How will your code cope with a
On Oct 18, 2005, at 6:10 PM, Robert Sayre wrote:
On 10/18/05, Antone Roundy [EMAIL PROTECTED] wrote:
-3 to being that generic.
That's a very large negative number. Can you explain how your version
will me write software I otherwise couldn't?
Anything larger than -2 is bogomips--the point I
Here's what this discussion makes me think of--RSS has a link
element. That link was very generic, and has been variously used to
link to what Atom calls link/@rel=alternate and link/
@rel=related, and perhaps even other things. Once we'd gained a
little experience and discovered that
26 matches
Mail list logo
