Subject: Revisiting feed discovery

From: "Arve Bersvendsen" <[email-masked]>
Date: Wed, 19 Jan 2005 14:40:17 +0100

I have just reread the Atom autodiscovery protocol, at  
<URL:http://diveintomark.org/rfc/draft-pilgrim-atom-autodiscovery-02.html>.  
I have also read <URL:http://www.w3.org/Provider/Style/URI>, and I believe  
the autodiscovery protocol needs revisiting:

a) rel="alternate" is a misnomer. Not all feeds are alternate content.  
They may have some other relationship, such as rel="related".

b) Specifying a mime type for a feed is not always appropriate. If we are  
assuming that "Cool URIs don't change", requiring a type-attribute is a  
huge mistake:
   I) The MIME type of the feed may change over time. Feeds may migrate  
 from being application/rss+xml to being application/atom+xml
  II) The MIME type may differ, depending on the client requesting it.

I am currently running an experiment/survey with content-negotiated feeds,  
see <URL:http://virtuelvis.com/archives/2005/01/feed-survey> [1] where I  
serve alternatively Atom/RSS 1.0/RSS 2.0 feeds to User-Agents depending on  
the Accept: header they are sending, and the preliminary data seems to  
suggest that using content-negotiation is a working means of serving feeds  
in multiple formats from a single URI.

My suggestions:

a) Change rel="alternate" to rel="feed", rel="subscription" or similar.
b) Drop 'type' as a required attribute for link. Make it a 'MAY'.

___
[1] I also have a 'live' content-negotiated feed at  
<URL:http://virtuelvis.com/feeds/bookmarks> that sends either  
application/rss+xml or application/atom+xml if a live experimental feed is  
wanted.

-- 
Arve Bersvendsen

http://virtuelvis.com

---

From: Danny Ayers <[email-masked]>
Date: Wed, 19 Jan 2005 15:52:22 +0100

> They may have some other relationship, such as rel="related".

True.

>   II) The MIME type may differ, depending on the client requesting it.

Re. II) I'm not so sure about this, it depends somewhat on how you
interpret the element - I think an interpretation consistent with
webarch could be: there's data of this mime type available from this
URI (using a HTTP GET)
Re. I) So? The publisher can simply update the link, as they'd have to
for various other changes.

> in multiple formats from a single URI.

Nice work, this should be useful.

> b) Drop 'type' as a required attribute for link. Make it a 'MAY'.

On one (technical) level both make sense. However given that the
current version is pretty widely deployed, a) at least could be
counter-productive due to confusion. "alternate" might not be accurate
in a lot of cases, but as a simple convention is near enough. I don't
see much potential harm in b) but then again I don't see much benefit.
If the feed is available in multiple formats (at the same or different
URIs) then can't that be declared using multiple link elements?

Overall, I'd conclude that it's not perfect but good enough as it stands.

> application/rss+xml or application/atom+xml if a live experimental feed is

Any thoughts on "application/rdf+xml"?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Eric Scheid <[email-masked]>
Date: Thu, 20 Jan 2005 02:17:35 +1100

> They may have some other relationship, such as rel="related".

and not all 'alternate' content is a "feed", even if the
mime-type="application/atom+xml". It could be an Atom Entry Document
alternative to the HTML page for a given post.

I wrote something about this just recently... you might have to skim past
the initial rambling though...

    http://www.imc.org/atom-syntax/mail-archive/msg12058.html

... in that I suggested we might well need a new mime type for Atom Entry
Documents. Shall I write a Pace?

> a) Change rel="alternate" to rel="feed", rel="subscription" or similar.

+1 for "feed", for the link to the resource which is a "sliding window
representation" of the most recently updated content from which the current
resource was once published via. Don't use "feed" for links to Atom Feed
Documents which serve as a static archive (eg. "Posts for October 2004").

> b) Drop 'type' as a required attribute for link. Make it a 'MAY'.

@type isn't a required attribute.

    3.5.2 "type" Attribute

    Link constructs MAY have a type attribute, whose  value MUST
    conform to the syntax of a MIME media type [RFC2045].

    The type attribute's value is an advisory media  type; it MAY
    be used as a hint to determine the type  of the representation
    which is expected to be returned when the value of the href
    attribute is dereferenced. Note that the type attribute does
    not override the actual media type returned with the representation.

e.

---

From: Danny Ayers <[email-masked]>
Date: Wed, 19 Jan 2005 16:29:33 +0100

> Documents which serve as a static archive (eg. "Posts for October 2004").

Eww, that doesn't sound right at all - if I don't update my blog for
ten years, do I have to change the attribute and mime type? I'd have
opted for a single (Atom) mime type and the 'sliding window'/'static'
nature being self-descriptive in the doc.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Eric Scheid <[email-masked]>
Date: Thu, 20 Jan 2005 02:52:37 +1100

On 20/1/05 2:29 AM, "Danny Ayers" <[email-masked]> wrote:

> ten years, do I have to change the attribute and mime type?

I wouldn't think so. The distinction has to do with what the main purpose
for auto-discovery links are for: finding a link to a resource which will
act as a feed of future publishings. Which is different from finding a link
to a resource which is the collection of all entries made in a specific date
period. With the former, generally speaking, there is an expectation of
"more to come", which with some authors could well be quite some time in the
future (I have more than a few subscriptions in my feed-reader which haven't
been updated for a long time, but absent any official closure they are still
"feeds of more to come").

As to mime-type ... maybe I wasn't clear ... I meant one mime-type for Atom
Feed Documents (whether "sliding window feeds" or "period archive" or
whatever), and another mime-type for Atom Entry Documents.

Thus you might see the following in one entry:

    <link href="..." rel="alternate" type="application/atom+xml" />
    <link href="..." rel="alternate" type="application/atom-entry+xml" />

... the first link is to the "feed", while the second would be to a
stand-alone resource which is an Atom Entry Document (not a feed).

> I'd have

Ah, but then we hit a snag with the "auto" part of "auto-discovery". If a
single entry has links to the sliding window feed, the appropriate monthly
archive, and also the Atom Entry Document, and they all have
@rel="alternate" and @type="application/atom+xml", how would an agent know
which one to subscribe to automatically.

There's more to this than what I've briefly touched on above. I recommend
you read my earlier message for more detail... it starts from a different
starting point, but comes to the same conclusion

It also suggests popularising Atom Entry Documents as a meta-data resource
for html pages, which is a back-door method to popularising Atom as a Feed
format. (This is something Atom has over RSS - the Atom Entry Document
concept).

e.

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Wed, 19 Jan 2005 17:49:42 +0100

> @type isn't a required attribute.

In the Atom autodiscovery document I referred to, type is required:

  4.2  type attribute
    The type attribute MUST be present in an Atom autodiscovery element.
    As defined in section 12.3 of HTML 4 [W3C.REC-html401-19991224], the
    value of the type attribute of any link element MUST be a registered
    Internet media type [RFC2045]. The media type for Atom is
    "application/atom+xml" (Atom Syndication Format 0.3), so in an Atom
    autodiscovery element the value of the type attribute MUST contain the
    string "application/atom+xml" in uppercase, lowercase, or mixed case.

-- 
Arve
http://virtuelvis.com

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Wed, 19 Jan 2005 17:46:17 +0100

> webarch could be: there's data of this mime type available from this

That's in general not how hyperlinks/links are being treated on the web
today. Apart from plugin content in <object>/<embed>,RSS/Atom
autodiscovery and linking to data that requires a specific mime-type
(text/javascript and text/css), I don't think this is widely used.

The common practice is "There's data here", and it is the job of the web
server to negotiate data that is acceptable to the client.

> for various other changes.

If someone follows a subscription link from web.archive.org, how can I
change that? Or, if someone creates a blogroll, with links to feeds, how
can they know the mime-type beforehand? Their User Agent may get (and
prefer) application/rdf+xml, but that may not be  consistent with what
others' User Agents may understand or request.

> in a lot of cases, but as a simple convention is near enough.

I know that established convention dictates that we can never use anything
but "alternate", but this is overloading of the meaning of alternate - a
mistake I fear we'll have to pay for somewhere down the road.

> I don't

Which would bring the number of link elements on a page with four distinct
feeds in three different formats up to twelve, but still only pointing at
four documents? Isn't that overly redundant?

> Any thoughts on "application/rdf+xml"?

Once I have an up and running RSS1.0 (1.1?) feed, it will be
content-negotiated as well.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

---

From: Eric Scheid <[email-masked]>
Date: Thu, 20 Jan 2005 11:53:09 +1100

> In the Atom autodiscovery document I referred to, type is required:

mea culpa

>   string "application/atom+xml" in uppercase, lowercase, or mixed case.

hmmm ... doesn't say it's an "advisory" value only though. Assuming for the
moment that it is, does this mean that I could use content negotiation on
such a link, contrary to the "advisory" mime-type?

e.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 21 Jan 2005 03:07:12 +0100

> They may have some other relationship, such as rel="related".

I agree.

> b) Specifying a mime type for a feed is not always appropriate. If we  
> are assuming that "Cool URIs don't change", requiring a type-attribute  
> is a huge mistake:

I agree with both points.

> a) Change rel="alternate" to rel="feed", rel="subscription" or similar.

What I have a problem with is «what is the feed for if it isn't an  
alternative to the resource you're looking at?». 'rel' should say what  
relation the current resource has to the referenced one. «Feed» isn't a  
relation, «alternate» is.

Not sure if the semantics are very important here, but I'm having trouble  
with putting a non-relative word like «feed» into an attribute which is  
supposed to describe relationship.

> b) Drop 'type' as a required attribute for link. Make it a 'MAY'.

+1.

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: Eric Scheid <[email-masked]>
Date: Fri, 21 Jan 2005 17:35:05 +1100

On 21/1/05 1:07 PM, "Asbjørn Ulsberg" <[email-masked]> wrote:

> alternative to the resource you're looking at?».

How is a resource which shows the last 15 entries as of today an
"alternative" representation of an entry which was published six months ago
and has long slipped out of the sliding window?

> 'rel' should say what

my interpretation of "feed" as a relationship is "here is the feed in which
this entry was originally published". I prefer "feed", it's shorter.

> supposed to describe relationship.

Its not the best word, but others which are better are already taken for
other purposes (eg "source", "origin", etc), or are clumsy word-pairs which
are still not properly indicative of the ongoing publishing nature (eg. DC's
"part-of").

e.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 25 Jan 2005 12:36:38 +1100

> mistake I fear we'll have to pay for somewhere down the road.

+1 to your concerns ... but then the Auto-Discovery spec is not yet an I-D
so maybe there is still time?

If we're stuck with 'alternate', then we're also harming the usefulness of
Atom Entry Documents by not being able to intelligently link to them from
their respective HTML pages. Similarly, if I had a feed which was "top new
blog feeds I found", I can't sensibly put a link to the feed into the
entries where I talk about them... in the following example, [1] is the link
to the html page which is the alternate to this entry in this feed, but
which is the link to the stand-alone Atom Entry Document for this entry, and
which is the link to the URL to subscribe to "Foo's Feed"?

<entry>
    <title>foo's feed</title>
    <summary>a wild and wacky feed about foo</summary>
    <date>...</date>
    <id>...</id>
    <link rel="alternate" type="text/html" href="[1]" />
    <link rel="alternate" type="application/atom+xml" href="[2]" />
    <link rel="alternate" type="application/atom+xml" href="[3]" />
</entry>

e.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 26 Jan 2005 07:02:44 +0100

On Fri, 21 Jan 2005 17:35:05 +1100, Eric Scheid  
<[email-masked]> wrote:

> "alternative" representation of an entry which was published six months  
> ago and has long slipped out of the sliding window?

It isn't, and that's not what I meant. I think 'alternate' links are being  
overloaded with these kinds of meanings all the time; e.g. individual HTML  
pages pointing to the feed in which they occur as RSS items as  
'alternate'. That's wrong and I agree that we should have another type of  
link relation for those links. But I'm not sure 'feed' is the correct one.

> other purposes (eg "source", "origin", etc), or are clumsy word-pairs  
> which are still not properly indicative of the ongoing publishing nature
> (eg. DC's "part-of").

I think 'part-of' is better. It's a relation and describes accurately what  
the link is pointing to. In the feed one could even have 'rev' links to go  
the other way, although that isn't necessary.

---

From: Eric Scheid <[email-masked]>
Date: Wed, 26 Jan 2005 17:35:56 +1100

> link relation for those links. But I'm not sure 'feed' is the correct one.

There is a special case of html pages for which rss/atom feeds are an
"alternate" -- those html pages which contain the most recently published
entries, sliding window style. Sadly, while 'alternate' is appropriate for
those resources it was then conflated with the semantic of "here is the xml
resource you can subscribe to".

> the other way, although that isn't necessary.

Ah, but an Atom entry would also have a "part-of" relationship to an Atom
Feed Document which is the collected entries for the month of June 2004, and
that Atom Feed Document is not the one you would subscribe to for future
publications of entries. This is making the same mistake as above with
"alternate".

e.