Subject: Autodiscovery paces

From: Nikolas Coukouma <[email-masked]>
Date: Mon, 09 May 2005 22:38:09 -0400

I've written a couple of paces based on the autodiscovery discussion. 
I'd like the group to stay focused on the syndication format issues, but 
didn't want the proposals to be lost.

http://www.intertwingly.net/wiki/pie/PaceAnchorSupport
http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue

-Nikolas Coukouma

---

From: Mark Pilgrim <[email-masked]>
Date: Tue, 10 May 2005 11:18:07 -0400

> http://www.intertwingly.net/wiki/pie/PaceAnchorSupport

"Autodicovery elements MAY appear in either the <head> or the <body>
of the document."

I believe this is incorrect.  IIRC, <link> elements may only appear in
the <head>, and <a> elements may only appear in the <body>.

Other than that, +1 on PaceAnchorSupport.

> http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue

+0.  Part of my newfound personal definition of a life well-lived is
to never again argue about semantics, markup, or the "correct" way to
use them.  This Pace will break every aggregator on the planet, but
then again, so will Atom 1.0 feeds, so... +0.

-- 
Cheers,
-Mark

---

From: Anne van Kesteren <[email-masked]>
Date: Tue, 10 May 2005 17:32:15 +0200

> http://www.intertwingly.net/wiki/pie/PaceAnchorSupport

+1 with the same remark as Mark Pilgrim.

> http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue

+1 if it is extended to support "alternate" as well when the feed really 
is the alternate version of the page. That would be a requirement for 
page authors. Feed readers don't have to check that and can fetch every 
feed with either a "feed" or "alternate" REL attribute value.

-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

---

From: Robert Sayre <[email-masked]>
Date: Tue, 10 May 2005 11:41:38 -0400

> feed with either a "feed" or "alternate" REL attribute value.

I don't understand what the "feed" relation indicates. What benefit
does it have over

<a href="..." type="application/atom+xml">...</a>

?

Robert Sayre

---

From: Anne van Kesteren <[email-masked]>
Date: Tue, 10 May 2005 17:48:10 +0200

Robert Sayre wrote:
>> +1 if it is extended to support "alternate" as well when the feed 
>> really is the alternate version of the page. That would be a 
>> requirement for page authors. Feed readers don't have to check that
>> and can fetch every feed with either a "feed" or "alternate" REL 
>> attribute value.
> 

That it can be used for *any* feed regardless its MIME type.

Another advantage is that I can say: 'Look, an <a href="link" 
type="application/atom+xml">Atom feed</a> that is well-formed', without 
making feed readers discover it.

---

From: Graham <[email-masked]>
Date: Tue, 10 May 2005 17:24:58 +0100

> http://www.intertwingly.net/wiki/pie/PaceAnchorSupport

-1

I also don't want to implement it.

> http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue

-1

I mainly don't see the point of changing it. Also, while "alternate"  
expressly says the feed corresponds in some way to the content of the  
current page, "feed" simply says "here is a feed of some kind", and  
isn't a relationship at all.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Wed, 11 May 2005 03:07:43 +1000

> <a href="..." type="application/atom+xml">...</a>

It indicates that the @href resource is a feed in the sense that it is a
source of notifications of updated content (and is the place to watch for
updates the current page) to which one might wish to subscribe, and
furthermore it suggests that the resource of @type="application/atom+xml" is
an Atom Feed Document, and not an Atom Entry Document.

Links you might *not* want to use @rel="feed" on would be...

    <a href="...">example of a broken feed</a>
    <a href="...">archives for June 2002</a>
    <a href="...">Tom's feed, very interesting</a>

Without @rel="feed", a browser with autodiscovery support might well suggest
those links as being worthy of subscription. (The third case iffy -- I rule
it not @rel="feed" because Tom is quite unlikely to include an entry which
is an alternate for this particular page).

e.

---

From: Robert Sayre <[email-masked]>
Date: Tue, 10 May 2005 13:17:59 -0400

On 5/10/05, Eric Scheid <[email-masked]> wrote:

> those links as being worthy of subscription. 

Hmm. I can see the merit in your rationale. Does it meet a need? Why
not deploy it and see what happens. There's nothing in the HTML spec
that says you can't make up a rel value, and you won't break anything
by trying it out.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Wed, 11 May 2005 03:41:02 +1000

On 11/5/05 3:17 AM, "Robert Sayre" <[email-masked]> wrote:

> Hmm. I can see the merit in your rationale. Does it meet a need?

The need is to not confuse users. Safari under tiger now does RSS
auto-discovery, which means there will be many totally-non-geek users who
might well get upset if the "Subscribe to RSS" function appears to be
borked. We're about to cross the chasm with RSS/Atom -- now would be a good
time to make sure the folks on the other side will have a pleasant
experience.

Safari is however having to make do using rough heuristics instead of
following a documented specification.

Right now, it suggests links to "application/atom+xml" resources as being
feeds, but sometime in the future that will be sub-optimal once/if folks
start publishing Atom Entry Documents.

I suspect it probably also suggests the following link as an RSS 1.0 feed:

    <link href='...' rel="alternate" type="application/rdf+xml">

even if it were on this page:

    http://dannyayers.com/misc/about/biog.htm

which (I'm guessing) would more likely to lead to a FOAF document than an
RSS 1.0 document.

e.

---

From: Phil Ringnalda <[email-masked]>
Date: Tue, 10 May 2005 12:41:55 -0700

On 5/10/05, Eric Scheid <[email-masked]> wrote:
> auto-discovery, which means

... that it will be totally borked if Atom feeds with rel="alternate"
autodiscovery turn out to be in a namespace other than the Atom 0.3
one. It occurred to me after I changed Mark's "Such notification could
also be built directly into future versions of desktop web browsers."
to "Such notification is also built directly into some desktop web
browsers." that it's not a very good thing for Atom 1.0 that it is: I
don't know about Safari and Opera, but thanks to ultra-liberal
autodiscovery Firefox will be discovering Atom 1.0 feeds without
knowing how to handle them no matter what, unless we beat the Firefox
1.1 clock by just the right amount.

At least changing the @rel value will give more cautious
autodiscoverers a fighting chance at not discovering Atom 1.0 until
they know how to read it. During the changeover, rel="alternate feed"
would still be risky, but a careful publisher could call their
alternate feed only rel="feed" until they felt enough clients
understood 1.0 to risk confusing legacy 0.3 clients.

Phil Ringnalda

---

From: Robert Sayre <[email-masked]>
Date: Tue, 10 May 2005 15:54:43 -0400

On 5/10/05, Phil Ringnalda <[email-masked]> wrote:
> one.

Safari's RSS/Atom parser is an XQuery script. When Atom is done, you
can bet they will roll out an updated script via Software Update.
They'll surely have other bugs to fix, anyway.I bet they will have it
done before we have an RFC number.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Tue, 10 May 2005 21:05:39 +0100

> autodiscovery turn out to be in a namespace other than the Atom 0.3

I just tried it, and it doesn't seem to care about the namespace.  
Anyone who gets lazy and uses "alternate" instead of "feed" for their  
Atom 1.0 feed would be borked anyway, so I don't really see this as a  
valid "pro" argument.

BTW Are we seriously considering using a different rel value to every  
other feed format in existence, including our own, for no discernible  
reason?

Graham

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 11 May 2005 00:26:32 +0200

> is an alternate for this particular page).

IMO, autodiscovery should occur only when a @rel (or @rev) is provided 
(and, ideally, understood). Don't forget HTML does not define a default 
value for @rel or @rev when they are not provided.

This is a link to an Atom document:
<a href="..." type="application/atom+xml">...</a>

These are links to Atom documents which indicate a relation between the 
containing document and the feed pointed to by the @href and should 
therefor trigger autodiscovery:
Linking to the news feed from the "news" page:
<a href="..." rel="alternate" type="application/atom+xml">...</a>
Linking to the news feed from another page (e.g. the Mozilla home):
<a href="..." rel="related" type="application/atom+xml">...</a>

-- 
Thomas Broyer

---

From: Robert Sayre <[email-masked]>
Date: Tue, 10 May 2005 19:16:17 -0400

There's no reason for any of the ideas in this thread to be in the
same draft as the concepts outlined in autodiscovery-01. Stamp Out
Creativity Now.

I'm strongly opposed to letting this draft turn into a vast metropolis
of bikesheds, where we have 60-message threads on the right way to use
HTML @rel values. The WG has limited resources and time. Those
resources are most needed by the protocol draft. Bolting fancy new
appendages on the autodiscovery draft is a waste of time. You don't
need a standards action to add a link relation. Just do it.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Wed, 11 May 2005 13:20:26 +1000

On 11/5/05 2:24 AM, "Graham" <[email-masked]> wrote:

> I mainly don't see the point of changing it.

The point is that just using 'alternate' is hideously ambiguous, and leads
to interoperability problems because you cannot rely on the value of @type
to accurately guess whether @href points to a feed or some other document.

In the history of feed autodiscovery, the exact syntax was corrected within
days of being first announced. Since then it's become popular, even without
official documentation in a specification. During that time people have come
to realise that there is a problem with 'alternate' ... consider that
pre-spec time as being a beta test period ... and now that we are on the
verge of releasing a fully documented specification it is our last real
opportunity to fix any mistakes.

Robert says anyone can mint new @rel types, but seriously, in the face of
popular usage of 'alternate' being backed up by a RFC specification, does
anyone think 'feed' would have a chance?

Put it in the spec and we are saying "use of 'alternate' is flawed, the
preferred option is 'feed'", and it will have more potency.

> Also, while "alternate"

Depends on how you read the word 'feed'. It can indicate a relationship,
that being "this is the feed in which an entry representing this page (or
portion thereof) was once found, and may again be found".

I, like some, feel uncomfortable with those usage of autodiscovery links to
point to just any feed, from any page. Links to feed resource documents are
not necessarily links to feeds.

e.

---

From: Eric Scheid <[email-masked]>
Date: Wed, 11 May 2005 13:58:22 +1000

> not necessarily links to feeds.

On reflection, I thought I'd better check what the spec says...
http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html

    The purpose of Atom autodiscovery is for clients who know the
    URI of a web page to find the location of that page's associated
    Atom feed. 

There is also this in section 6

  € The order of the autodiscovery elements is significant.
    The first element SHOULD point to the publisher's preferred
    feed for the document.

... thus [1] auto-discovery is *not* for the general case of linking to just
*any* feed resource, but specifically the one associated to the current
page/site. Which is a specific relationship, one we can name 'feed' (or
'fred', or 'barney' ... but 'feed' gets my vote).

e.

[1] I conclude ... and so might any reader of the spec who is ignorant of
the full backstory.

---

From: Eric Scheid <[email-masked]>
Date: Wed, 11 May 2005 13:57:58 +1000

> then again, so will Atom 1.0 feeds, so... +0.

:-)

My belief is that RSS/Atom is at the point of crossing the chasm [1] and
going mainstream, and as such if we want the momentum to continue we should
be mindful of two things:

  * adding features/functions/tweaks which appeal to geeks and
    other 'insiders' is counter-productive

  * not fixing any warts or bugs which non-geeks won't understand
    why they get broken behaviour is counter-productive.

There is thus a filter to be applied to any suggestions for "improvements".

Changing 'alternative' to 'feed' fits the second criteria, but adding <a/>
fits the first. So, +1 to PaceDifferentRelValue, -1 to PaceAnchorSupport.

e.

[1] http://en.wikipedia.org/wiki/Crossing_the_Chasm