+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
All,
Just wanted to clue y'all in on this conversation. The Atom extension
drafts listed below entered an Unofficial last call state about three
weeks ago. As of today I'm declaring these stable and will not be
making any further changes on them unless a) significant bugs/problems
are
As of today I am issuing an unofficial last call on the Feed Rank extension
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-index-03.txt
This extension introduces a numeric ranking mechanism for Atom entries
that can be used to order entries according to relative significance.
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
All,
At some point over the next couple of days, a slightly modified version
of the comments extension draft [1] will be published. The moment it
publishes will kick off a two week Unofficial Last Call period for the
spec. The spec has been stable of the past two months with no major
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
The following is an application for a link relation value, as specified
in the Atom Syndication Format.
https://datatracker.ietf.org/public/idindex.cgi?command=id_detailfilename=draft-ietf-atompub-format
Ok, now that a number of the other extensions I've been working on are
moving along, it's time to turn my attention to a couple of other ideas
I've been stewing on. One of which is link[rel=sponsored] to indicate
sponsored links / advertisements within feeds.
link rel=sponsored
Antone Roundy wrote:
The following two bits seem incompatible with each other:
o atom:entry, atom:feed and atom:source elements MUST NOT contain
more than one 'license' link relation with the same
combination of
type and hreflang attribute values.
Note the caveat, with
Another subject that has come up in recent discussions is an extension
that can be used to specify the purpose of a feed. For example, is the
feed an archive, is it a podcast, is it used for discovering web
services or publishing blog content, etc.
The approach that I have in mind is to
James M Snell wrote:
Ok, so thus far: we can indicate resources that are related to the given
entry; we can indicate that an entry is a reply to another entry; we can
specify categories to which the entry belongs; but there is currently no
way of indicating the *subject* of the entry.
The
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
Bill de hÓra wrote:
The link approach doesn't seem to be less ambiguous than dc:subject. For
lessened ambiguity you might want to use published subject indicators a
la topic maps.
It is less ambiguous in that a URI is less ambiguous that some
arbitrary text string. Further, the link
James M Snell wrote:
Bill de hÓra wrote:
The link approach doesn't seem to be less ambiguous than dc:subject. For
lessened ambiguity you might want to use published subject indicators a
la topic maps.
It is less ambiguous in that a URI is less ambiguous that some
arbitrary text
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
James M Snell wrote:
Another subject that has come up in recent discussions is an extension
that can be used to specify the purpose of a feed. For example, is the
feed an archive, is it a podcast, is it used for discovering web
services or publishing blog content, etc.
The approach that
On 22/10/05 4:48 AM, James M Snell [EMAIL PROTECTED] wrote:
Note the caveat, with the same combination of type and hreflang
attribute values. The idea is to prevent a single license from being
appearing more than once.
Multiple license link relations MAY be used to indicate that the
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
Bill de hÓra wrote:
I think you're proposing to enable a kind of Atom microformat - if you
see profile ?x check for ?a ?b and ?c. Sorting it out on consumer
sounds flaky ('sounds', not 'is'), but this also might be very cool. I
wonder why you need a link to do this instead of foo:profile tag.
* James M Snell [EMAIL PROTECTED] [2005-10-21 21:25]:
Ok, so thus far: we can indicate resources that are related to
the given entry; we can indicate that an entry is a reply to
another entry; we can specify categories to which the entry
belongs; but there is currently no way of indicating
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
On Oct 21, 2005, at 5:47 PM, James M Snell wrote:
Err, are you forgetting atom:category? Doesn’t that satisfy all
your wants *and* more? It has a URI, a term and a human-readable
label.
Regards,
I dunno, that's why I was asking ;-)
atom:category works well for categorizing entries, but does
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
I'm not sure if I've understood you correctly, but if this could be used as
a hint to the aggregator on how best to process/display the feed then I
think it's a great idea.
For example, knowing that a feed was a collection of images (e.g. a Flickr
feed) would enable the aggregator to
James Holderness wrote:
I'm not sure if I've understood you correctly, but if this could be
used as a hint to the aggregator on how best to process/display the
feed then I think it's a great idea.
Yes, that's exactly what it's for.
For example, knowing that a feed was a collection of
James M Snell wrote:
Ok, now that a number of the other extensions I've been working on are
moving along, it's time to turn my attention to a couple of other ideas
I've been stewing on. One of which is link[rel=sponsored] to indicate
sponsored links / advertisements within feeds.
Not sure
James Holderness wrote:
James M Snell wrote:
Ok, now that a number of the other extensions I've been working on
are moving along, it's time to turn my attention to a couple of other
ideas I've been stewing on. One of which is link[rel=sponsored] to
indicate sponsored links /
38 matches
Mail list logo
