James M Snell wrote:
I'm perfectly happy with leaving previous and next free of any semantics
right now and letting the market sort things out. If more specific link
relations prove to be necessary, then so be it, define the more specific
link relations. If the market can get by with
James Holderness wrote:
Thomas Broyer wrote:
As I already explained, paging is orthogonal to the incremental nature
of a feed. An incremental feed will be chunked as explained in Mark's
current Feed History draft (just use an atom:[EMAIL PROTECTED]previous]
instead of the fh:prev
On 24/10/05 5:31 PM, Thomas Broyer [EMAIL PROTECTED] wrote:
This has not yet proven to be really needed (e.g. the Top 50 web site I
saw didn't provide archives of previous rankings).
When there'll be such a need, then we'll define a new link relation (I
already proposed archives/history to
Thomas Broyer wrote:
I beg to differ. I think the incremental state of a feed is very relevant
to paging. If the aggregator does not know that a feed is non-incremental
it will not be able to process the feed document in a meaningful manner.
Yes, but that's orthogonal to paging.
I think I
On Oct 24, 2005, at 8:13 AM, James Holderness wrote:
With what we have so far we can do incremental feed archives; we
can do at
least some form of searching; we can do non-incremental feeds (of
the Top
10 variety) with history. I think that's a good start.
But we also want paged
Perhaps they can, but that wouldn't always be desirable. Consider this
scenario: Somebody writes a program that searches Google, scrapes the
HTML results, and publishes them as an Atom feed. My purpose in
subscribing to the feed is not to be alerted when a new webpage is added
to page
On Oct 24, 2005, at 11:16 AM, James Holderness wrote:
A more sensible approach would be a single feed document containing
the top N results (where N is manageable in size). You could
subscribe to that as a non-incremental feed and you would know at
any point in time which were the top 10
Having not spoken up so far, I'd like add my 2c. My atom feeds are all
dynamic OpenSearch-style search results. By default they also happen to
be traditional 'incremental' blog-style feeds. Instead of static
archives, I have dynamic page=N sliding windows.
I'd like to be able to include
On 10/23/05, Peter Robinson [EMAIL PROTECTED] wrote:
I'd like to be able to include machine-interpretable 'prev'/'next' links
so that a user agent that wants to can reconstruct a complete (logical)
feed whether that means a 'history' or just the current snapshot of
results (and at a single
+1 to all.
Wh!
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Nottingham
Sent: Thursday, October 20, 2005 4:53 PM
To: Atom Syntax
Subject: New Link Relations -- Ready to go?
At this point, I believe the following represent as
On Oct 21, 2005, at 5:03 PM, Mark Nottingham wrote:
How about:
- Description: A URI that refers to a feed document containing a
set of the most recent entries in the feed. This URI is intended to
be subscribed to to keep abreast of recent changes in the feed;
when different from the
Tim Bray wrote:
On consideration, I am -1 to rel=subscribe. The reason is this: one of
the big potential value-adds Atom brings is a standards- compliant way to
do one-click auto-subscribe, via link rel=self /
. You are proposing to introduce a link rel=subscribe / which
is there to
Antone Roundy write:
If creation time is relevant to the data being searched, then this makes
sense. But what if I want to subscribe to the top 10 Google results for
some keywords I'm trying to optimize my site for (ignoring the fact that
Google doesn't return search results in any feed
Eric Scheid wrote:
Finally, markup design that claims to enforce a specific action is
always questionable. The great virtue of descriptive markup in
general is that the tags tell you not what to do with things but what
they are. So on that basis, rel=current-version or something is
better
First and Last are (or at least can be) static; i.e. one can read
the relations, as currently written, as saying that they point to the
specific set of entries (archive) that are first and list,
respectively, at the time that the feed is minted. Subscribing to one
of those would be...
On Oct 22, 2005, at 3:28 AM, Eric Scheid wrote:
I think you've got the special case turned around. That is, if you are
looking at a representation of the active feed then the 'self' link
would
happen to match the 'subscribe' link, which is the exception. The
defining
text in the spec says
On Oct 22, 2005, at 8:40 AM, Mark Nottingham wrote:
You seem to be saying that because link/@rel=self was designed
for a specific purpose, and even though its definition is quite
descriptive (its definition *only* says it should be used to link
to the current document; -11 says nothing
Great! I'll summarise where they are and do a last call.
On 22/10/2005, at 9:52 AM, Tim Bray wrote:
On Oct 22, 2005, at 8:40 AM, Mark Nottingham wrote:
You seem to be saying that because link/@rel=self was designed
for a specific purpose, and even though its definition is quite
+1 to all too.
On Fri, 21 Oct 2005, Eric Scheid wrote:
Date: Fri, 21 Oct 2005 10:47:57 +1000
From: Eric Scheid [EMAIL PROTECTED]
To: Atom Syntax atom-syntax@imc.org
Subject: Re: New Link Relations -- Ready to go?
+1 to all
Tim Bray wrote:
On Oct 20, 2005, at 4:52 PM, Mark Nottingham wrote:
- Attribute Value: subscribe
I'm puzzled by this one. I thought that if you wanted to subscribe to a
feed then, well, you would subscribe to a feed. I must have missed the
discussion. Could someone provide a
On Oct 21, 2005, at 7:38 AM, James Holderness wrote:
The idea being that if you were to come across an archived Atom
document (however that might happen), the presence of this link
would, (a) let you know that it was an archive document and thus
shouldn't be subscribed to, and (b) provide
* Eric Scheid [EMAIL PROTECTED] [2005-10-21 17:05]:
It was thought that the 'self' link in an archive would point
to the archive document itself, which meant a different
relationship was needed for the purpose of locating the URI
which is the one that contains the most recent updates/entries.
A. Pagaltzis wrote:
* Eric Scheid [EMAIL PROTECTED] [2005-10-21 17:05]:
It was thought that the 'self' link in an archive would point
to the archive document itself, which meant a different
relationship was needed for the purpose of locating the URI
which is the one that contains the most
Thomas Broyer wrote:
Mark Nottingham wrote:
- Attribute Value: previous
- Description: A URI that refers to the immediately preceding
document in a series of documents.
This definition doesn't prevent someone from using this link relation for
linking within a series of
On 22/10/05 1:33 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
First, rel=self is going to be implemented by most everything
that groks Atom 1.0 in order to support one-click subscription,
if applicable, right? Whereas this new relationship might not
find such wide-spread support.
I believe
James M Snell a écrit :
Thomas Broyer wrote:
Mark Nottingham wrote:
- Attribute Value: previous
- Description: A URI that refers to the immediately preceding
document in a series of documents.
This definition doesn't prevent someone from using this link relation
for
linking within a
Thomas Broyer wrote:
How would you use these link relations for feed state reconstruction
(that is, automatic handling by the Atom processor, without user
action –except probably the please reconstruct this feed's state
action) if you can't know what's pointed at?
How would you navigate
James M Snell wrote :
Thomas Broyer wrote:
How would you use these link relations for feed state reconstruction
(that is, automatic handling by the Atom processor, without user
action –except probably the please reconstruct this feed's state
action) if you can't know what's pointed at?
Thomas Broyer wrote:
James M Snell wrote :
Thomas Broyer wrote:
So you are OK with these feeds:
Yes, they all look good to me.
You didn't answer my last question:
How do you expect a newsreader to *automatically* download this
week's 50 entries without downloading last week's
James Holderness wrote:
Thomas Broyer wrote:
You didn't answer my last question:
How do you expect a newsreader to *automatically* download this
week's 50 entries without downloading last week's entries instead?
(and show you links/buttons for you to ask download and display of
Thomas Broyer wrote:
However, an incremental feed could take advantage of differentiating
between paging and archive linking: if linking to archives uses an
atom:[EMAIL PROTECTED]archives] (or call it history if you prefer) to
point at an incremental feed where each entry describes an
That's what I was trying to do here:
- Description: A URI that refers to a feed document containing a
set of the most recent entries in the feed. This URI is intended to
be subscribed to to keep abreast of recent changes in the feed.
When different from the URI of the document where it
On Oct 21, 2005, at 3:13 PM, Mark Nottingham wrote:
- Description: A URI that refers to a feed document containing a
set of the most recent entries in the feed. This URI is intended
to be subscribed to to keep abreast of recent changes in the feed.
When different from the URI of the
So, an aggregator comes across a feed in the woods. It sees it has
previous and maybe next link relations.
The point that (I think) Thomas is making is that the people who
leave that feed document in the woods had better be comfortable with
the aggregator following the links and
How about:
- Description: A URI that refers to a feed document containing a
set of the most recent entries in the feed. This URI is intended to
be subscribed to to keep abreast of recent changes in the feed; when
different from the URI of the document where it occurs, it indicates
Thomas Broyer wrote:
As I already explained, paging is orthogonal to the incremental nature of
a feed. An incremental feed will be chunked as explained in Mark's current
Feed History draft (just use an atom:[EMAIL PROTECTED]previous] instead of the
fh:prev extension element) and a
On Oct 21, 2005, at 7:19 PM, James Holderness wrote:
What's the difference between a search feed and a non-incremental
feed? Aren't search feeds one facet of non-incremental feeds?
Not necessarily, no. A search feed could quite easily be
implemented as an incremental feed. This is the most
+1 to one and all. This is perfect.
Mark Nottingham wrote:
At this point, I believe the following represent as close to
consensus as we're able to get (although I'm happy to be proven
wrong, as long as there are counterproposals that can gain consensus).
To move forward, please either
+1 to all
+1 to all
Just a minor grammatical quibble regarding the text for subscribe: the
phrases ending with a preposition seem somewhat awkward to me - in
particular the double to. If you think I'm being overly dogmatic, though,
feel free too ignore.
Possible replacement text:
- Attribute
40 matches
Mail list logo
