Subject: Autodiscovery

From: Tim Bray <[email-masked]>
Date: Tue, 03 May 2005 09:52:59 -0700

Mark Pilgrim agreed to turn his Atom autodiscovery draft into a WG 
draft, and has done so, see:

http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt
http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.html
http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.xml

Although Mark's not subscribed, I've agreed to relay any changes that 
have WG consensus back to him for update; although if they're minor, I 
guess one of us could just rejigger the XML ourselves.

I scanned them and nothing objectionable leapt out at me, but please, 
could a few more people also have a look?

Assuming no errors, or rather that any errors we turn up are fixed, are 
there any objections to us submitting this I-D as a product of the 
Atompub WG?  -Tim

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 May 2005 19:09:09 +0200

> there any objections to us submitting this I-D as a product of the 

One thing that immediately comes to mind that the references need to be 
checked, for instance for URI (not RFC2396 anymore) and for XML 1.0 (now 
at 3rd edition).

Best regards, Julian

---

From: Robert Sayre <[email-masked]>
Date: Tue, 3 May 2005 13:15:18 -0400

> could a few more people also have a look?

I've never liked the rules in section 6. For example, when presenting
a single option from multiple link elements, UAs should be permitted
to present an alternate in the user's preferred language. I'm pretty
sure this issue was the subject of my first post to atom-syntax. What
a rathole that turned out to be...

Also, the references need updating in some cases, unless they are
supposed to match what's in the HTML drafts. RFC2045 might need to be
updated to the Freed/Klensin draft that the format references.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 03 May 2005 18:18:05 +0100

> there any objections to us submitting this I-D as a product of the 

How do we manage a WG product produced and edited by a non-WG member?

This isn't an objection, btw, I'm just curious about the pragmatics of 
editorship and decision making when the editor isn't here. I remember 
Mark P said something on this list once about showing up, it stuck with 
me because he'd nailed it.

cheers
Bill

---

From: Graham <[email-masked]>
Date: Tue, 3 May 2005 18:17:06 +0100

On 3 May 2005, at 5:52 pm, Tim Bray wrote:

> I scanned them and nothing objectionable leapt out at me, but  
> please, could a few more people also have a look?

The only thing I noticed was the href attribute definition:

"The value MAY be a relative URI, and if so, clients MUST resolve it  
to a full URI (section 5 of [RFC2396]) using the document's base URI  
(section 12.4 of HTML 4 [W3C.REC-html401-19991224])"

I'd be happier with "the document's base URI" being replaced with  
"the prevailing base URI", since the current wording could easily be  
misinterpreted as meaning only the URI it was loaded from.

(Yes, I'm aware an HTML or XHTML document only has a single base URI  
for the whole thing, and that the section 12.4 referenced is the  
<base> element definition, but it took me a while to look that up)

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Tue, 3 May 2005 13:33:22 -0400

> -----Original Message-----
> From: Bill de hÓra [mailto:[email-masked]] 
> Sent: Tuesday, May 03, 2005 1:18 PM
> To: atom-syntax Syntax'
> Subject: Re: Autodiscovery
> 
> 
> 
> Tim Bray wrote:
> 

I've privately asked Tim and Paul the same question.  Though section 6.3 of
RFC 2418 doesn't specifically say that a document editor MUST be a member of
the working group, the situation appears so obvious that it shouldn't need
to be stated.

-Scott-

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Tue, 03 May 2005 19:42:55 +0200

> guess one of us could just rejigger the XML ourselves.

First, I am not too fond of making an autodiscovery protocol "Atom-only" -  
we will have to live with other feed formats for a few years still, so I  
think we should embrace legacy feed formats. These are my suggestions

1) Change the attribute value for the rel from "alternate" to "feed", or  
some similar wording.  A feed is not always an alternate of the HTML  
document in which it occurs. Suggested replacement text:

# 4.1  rel attribute

# The rel attribute MUST be present in an Atom autodiscovery element. As  
defined
# in section 6.12 of HTML 4 [W3C.REC-html401-19991224], the value of the  
rel
# attribute is a space-separated list of keywords. The list of keywords  
MUST
# include the keyword "feed" in uppercase, lowercase, or mixed case.

2) I am not too fond of requiring a type attribute, since feeds may be  
served in multiple formats from a single URL. I have previously performed  
a survey about how aggregators handle content negotiation,  
<URL:http://virtuelvis.com/archives/2005/01/feed-survey>, and with  
sensible q-values set, aggregators currently in development may be served  
feeds in a format they're able to understand. In line with this, I  
suggeest that section 4.2 is removed, and that a new section 5.1 is added:

# 5.1  type attribute

# The type attribute MAY 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].

-- 
Arve Bersvendsen

---

From: Tim Bray <[email-masked]>
Date: Tue, 03 May 2005 14:10:46 -0700

> the working group, the situation appears so obvious that it shouldn't 

OK, that's an issue, plus it turns out that there are people who 
actually want to make changes.  So I guess we'll need a new co-editor 
and to do some actual WG process.  I'll talkk to Paul about it.  -Tim

---

From: David Nesting <[email-masked]>
Date: Tue, 3 May 2005 18:56:48 -0500

> document in which it occurs. Suggested replacement text:

I'm all for avoiding pigeonholing like that.  But what about the case
when a feed IS an alternate version?  HTML says to use "alternate",
this says to use "feed".  Which takes precedence?

Plus, "feed" is kind of application-specific.  What about "related"?

Consider also that HTML allows alternate stylesheets to be identified
with the relationships "alternate" and "stylesheet".  HTML overrides
the semantics of "alternate" in this case (since the stylesheet isn't
an alternate version of the page, it's just an alternate stylesheet).
Who's to say we can't overload it a little for this case?

So I might suggest, in order of preference:

1. "alternate" for feeds that can be considered alternate versions of
   the current document, and "related" for feeds that can be discovered
   via this page, but aren't actually an alternate form of the content
   on that page; or

2. "feed" for all feeds, and "alternate feeds" for feeds that can be
   considered alternate versions of the current document.  (This would
   use "alternate" with its stand-alone meaning, not the meaning given
   to it in the "alternate stylesheet" case.)

> served in multiple formats from a single URL. I have previously performed  

Omitting the type is only practical when you have a link relationship
dedicated to this specific application.  If we continue to use
generic relationships like "alternate" and/or "related", it becomes a
little inefficient since you have to hit the link targets pretty much
indiscriminately looking for one that responds with a media type you're
looking for.

I expect that many of my implementations will utilize content negotiation
(using the same URL as an HTML representation, where needed), so I expect
that I'll have some links like:

  <link rel="alternate" href="/" type="application/atom+xml">
  <link rel="alternate" href="/" type="application/rss+xml">

Or even

  <link rel="alternate" href="" type="application/atom+xml">
  <link rel="alternate" href="" type="application/rss+xml">

As crazy as that looks, is there a better way of saying "this URL is
also available in these media types"?

David

-- 
 == David Nesting WL7RO Fastolfe [email-masked] http://fastolfe.net/ ==
 fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882  C41F 3065 57D9 832F AB01

---

From: Eric Scheid <[email-masked]>
Date: Wed, 04 May 2005 10:20:46 +1000

> 1) Change the attribute value for the rel from "alternate" to "feed", or
...
> 2) I am not too fond of requiring a type attribute

I suspect the requirement for @type was because of the choice of 'alternate'
as the trigger, and thus if (1) passes then (2) can be relaxed.

e.

---

From: Phil Ringnalda <[email-masked]>
Date: Tue, 03 May 2005 20:50:46 -0700

Arve Bersvendsen wrote:
> First, I am not too fond of making an autodiscovery protocol "Atom-only"

It's only Atom-only in that it doesn't attempt to dictate things outside 
the WG's charter: as it's written now, it's just a well-specified exact 
equivalent of the existing RSS autodiscovery spec-blog-post. Anyone who 
has existing code for RSS autodiscovery can simply check for one of two 
values of @type, rather than just one, and be done with it (well, 
actually, anyone with existing code for RSS autodiscovery has already 
long since done so).

> 1) Change the attribute value for the rel from "alternate" to "feed", 

Don't forget, since you would be doing that primarily for people who 
think too much, that you'll also need to include a profile [1] URI and 
make a guess at what dereferencing that URI ought to return, and 
probably take a stab at explaining how to deal with multiple profiles, 
since the HTML spec punted on that.

Popularizing "feed" would have one benefit outside Atom's scope, though: 
there's currently no useful way for an RSS 1.0 feed to do autodiscovery 
with type="application/rdf+xml" since it could be any alternate RDF, not 
just RSS: if Atom breaks the ice with "feed" then RSS 1.0 wins.

> served in multiple formats from a single URL.

If you've changed to rel="feed" you've lost all backward compatibility, 
so you might as well just say type="application/atom+xml" and still do 
content negotiation for anything that actually prefers RSS: nothing that 
only knows RSS will recognize you (and what thing that knows Atom would 
prefer RSS?).

But if you do rel="feed" with no type, then since the namespacing aspect 
of @profile wasn't ever actually made workable, you are completely 
claiming the use of that @rel for Atom/RSS: no other past or future 
things could use it without being willing to take the pounding of a 
million aggregators.

Phil Ringnalda

[1] http://www.w3.org/TR/REC-html40/struct/global.html#profiles

---

From: fantasai <[email-masked]>
Date: Wed, 04 May 2005 01:29:35 -0400

Arve Bersvendsen wrote:
> or  some similar wording.  A feed is not always an alternate of the 
> HTML  document in which it occurs.

As I mentioned last November [1] I agree with not requiring the
'alternate' rel value for the reasons stated in
   http://fantasai.inkedblade.net/weblog/2004/linking-feeds/
Briefly, it is an abuse of its semantics because many feed links
are not links to alternate representations of the current page.

[1] http://www.imc.org/atom-syntax/mail-archive/msg11705.html

~fantasai

---

From: fantasai <[email-masked]>
Date: Wed, 04 May 2005 01:41:33 -0400

>   <link rel="alternate" href="" type="application/rss+xml">

That won't work, because content negotiation will continue to return
the same thing it returned just now. You must somehow tell the server
to return a specific other version of the current document, and you
do that typically by sending a GET request with a different URL --
one that specifies a particular version of the resource.

> also available in these media types"?

File extensions that encode file format in the URL are harmful when
the goal is to "return the content in an appropriate format", which
may change over time or with UA. If you're asking for a document in
a *specific* format, then that a specifier for that format should
be part of the URL.

~fantasai

---

From: fantasai <[email-masked]>
Date: Wed, 04 May 2005 01:52:01 -0400

> since the HTML spec punted on that.

This would not be necessary if 'feed' were added to the HTML standard
directly.

> just RSS: if Atom breaks the ice with "feed" then RSS 1.0 wins.

'feed' is not really defining a /relation/, it's defining a sort of
meta-content-type... But I would much prefer that to forcing 'alternate'
on non-'alternate' links.

~fantasai

(Copying to WHATWG mailing list: http://www.whatwg.org/ )

---

From: Henri Sivonen <[email-masked]>
Date: Wed, 4 May 2005 09:04:16 +0300

> Plus, "feed" is kind of application-specific.  What about "related"?

It's a spec for discovering *feeds*. It is proper to have an 
app-specific rel value to avoid feed-specific apps downloading non-feed 
related documents.

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: Henri Sivonen <[email-masked]>
Date: Wed, 4 May 2005 09:09:19 +0300

On May 4, 2005, at 06:50, Phil Ringnalda wrote:

> think too much, that you'll also need to include a profile [1] URI

No you don't. rel='license' and rel='nofollow' have been deployable 
without a profile. You just release running code that hard-codes 
rel='feed' and, boom, no profile needed.

> But if you do rel="feed" with no type, then since the namespacing 
> aspect of @profile wasn't ever actually made workable, you are 
> completely claiming the use of that @rel for Atom/RSS: no other past 
> or future things could use it without being willing to take the 
> pounding of a million aggregators.

I don't see that as a problem but as a practical deterrent that lowers 
the already low probability of (rather theoretical) name clashes.

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: Mark Pilgrim <[email-masked]>
Date: Wed, 4 May 2005 01:16:20 -0500

On 5/4/05, Henri Sivonen <[email-masked]> wrote
> rel='feed' and, boom, no profile needed.

Then I'm confused as to why you can't just release running code that
hard-codes rel="alternate".  You know, like people have already done.

-- 
Cheers,
-Mark

---

From: fantasai <[email-masked]>
Date: Wed, 04 May 2005 01:34:26 -0400

> this says to use "feed".  Which takes precedence?

Neither. You can put both.

> Plus, "feed" is kind of application-specific.  What about "related"?

A link, by its very existence, is indicating that the two documents
are related. rel="related" is redundant.

> an alternate version of the page, it's just an alternate stylesheet).

This is recognized as a mistake on the part of the HTML 4.01 spec authors.
The 'rel' attribute takes a space-separated *list* of rel values: this
exception aside, one value does not modify the other.

> Who's to say we can't overload it a little for this case?

You are not writing the HTML 4.01 spec, you're writing an autodiscovery
spec that takes advantage of the syntax *and semantics* given in HTML 4.
Your specification should be consistent with HTML 4, not contradictory
to it.

~fantasai

---

From: Eric Scheid <[email-masked]>
Date: Wed, 04 May 2005 17:43:38 +1000

> on non-'alternate' links.

instead of "feed", consider "updates", which gets closer to the gist of the
sense

e.

---

From: Anne van Kesteren <[email-masked]>
Date: Wed, 04 May 2005 10:01:31 +0200

> hard-codes rel="alternate".  You know, like people have already done.

rel="alternate" is already used for other purposes. (But obviously, you 
know that too.)

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

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Wed, 04 May 2005 10:04:57 +0200

On Wed, 04 May 2005 09:43:38 +0200, Eric Scheid  
<[email-masked]> wrote:

> instead of "feed", consider "updates", which gets closer to the gist of  
> the sense

No. To me 'Updates' signifies that something is 'updated'. Even posting  
new content falls outside of that definition.

-- 
Arve Bersvendsen

---

From: Dan Brickley <[email-masked]>
Date: Wed, 4 May 2005 06:38:31 -0400

* Henri Sivonen <[email-masked]> [2005-05-04 09:04+0300]
> app-specific rel value to avoid feed-specific apps downloading non-feed 

What's a feed? 1/2 ;)

FWIW in the FOAF spec we currently say:

<link rel="meta" type="application/rdf+xml" title="FOAF"
href="http://example.com/people/~you/foaf.rdf" /> 
(although we shouldn't really be taking over the title attribute...)

(we don't really say what a FOAF file is either; pointing to an RSS1 doc
that had some use of the FOAF namespace in it too could be reasonable...).

Dan

---

From: Henri Sivonen <[email-masked]>
Date: Wed, 4 May 2005 13:57:51 +0300

> hard-codes rel="alternate".  You know, like people have already done.

Sure you can. ("Can" in the sense that it is possible.)

However, when other things are equal, I think misusing an existing 
relation (feed usually is not a proper alternate representation) is 
worse than specifying a new one without all the profile fluff.

Still, I am well aware that the other things are not equal in this case 
(ie. there is deployed code), which is why I was not arguing in favor 
of rel='feed' per se, but pointing out that the particular reasoning 
against it  did not hold water, IMO.

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: Henri Sivonen <[email-masked]>
Date: Wed, 4 May 2005 14:01:12 +0300

> instead of "feed", consider "updates", which gets closer to the gist 

We all call them feeds and in the end it comes down to picking a string 
that software uses for comparison. Why all the over-generalization?

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: Antone Roundy <[email-masked]>
Date: Wed, 4 May 2005 07:12:24 -0600

> one that specifies a particular version of the resource.
See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14

GET /path-to-the-feed HTTP/1.1
Accept: application/atom+xml
...

You don't have to change the URL--just list only the format you want in 
the Accept header.  If the autodiscovery link was lying/mistaken and 
that format really isn't available at that URL, you should get a 406 
(not acceptable) response.

---

From: Robert Sayre <[email-masked]>
Date: Wed, 4 May 2005 09:11:24 -0400

> Your specification should be consistent with HTML 4, not contradictory

The autodiscovery spec is a reasonable interpretation of the *one
line* definition of the 'alternate' relation. It is not contradictory.

Robert Sayre

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 4 May 2005 12:16:11 -0400

> line* definition of the 'alternate' relation. It is not contradictory.

+1

-- 
Joe Gregorio        http://bitworking.org

---

From: fantasai <[email-masked]>
Date: Wed, 04 May 2005 13:04:11 -0400

Arve Bersvendsen wrote:
>> instead of "feed", consider "updates", which gets closer to the gist 
>> of  the sense
> 

That would signify "updates" to my document. If I'm linking to the
CNN news feed, or my-favorite-blog, that wouldn't be appropriate.
For this purpose, the syntax needs to signify that this is a feed,
that it needs to be handled as such.. and that there is no other
significant relationship between the document and the feed it links
to (unless otherwise specified).

~fantasai

---

From: fantasai <[email-masked]>
Date: Wed, 04 May 2005 13:07:55 -0400

> line* definition of the 'alternate' relation. It is not contradictory.

The definition of 'alternate' is not one line long on my screen, but
here's the first sentence of it:

  # Alternate
  #   Designates substitute versions for the document in which the link occurs.

  -- http://www.w3.org/TR/REC-html40/types.html#h-6.12

How is a link from the top of my homepage to my friend's weblog feed
designating a "substitute version for the document in which the link
occurs"?

Note that we are not arguing the semantics of the <link> element in
an Atom document, but the semantics of the <link> element in an HTML
document.

~fantasai

---

From: Robert Sayre <[email-masked]>
Date: Wed, 4 May 2005 13:23:21 -0400

> designating a "substitute version for the document in which the link

I don't know, but I'm not sure why you think that's what the
autodiscovery spec endorses. Is there some part of the spec that
endorses that? The autodiscovery spec is for use by UAs like Mozilla
and Safari that present little icons alerting the user to a feed
version of a page. Often, I never visit the page again, once I've
subscribed to the feed. The feed is a substitute.

> an Atom document, but the semantics of the <link> element in an HTML

Yes, I caught that.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Thu, 05 May 2005 02:35:30 +1000

On 4/5/05 11:11 PM, "Robert Sayre" <[email-masked]> wrote:

> line* definition of the 'alternate' relation.

how is a feed of recent entries a "substitute version for the document in
which the link occurs" when that document is some blog post long since
dropped out of the feed?

> Alternate
> Designates substitute versions for the document in which the link occurs. When
> used together with the lang attribute, it implies a translated version of the
> document. When used together with the media attribute, it implies a version
> designed for a different medium (or media).

---

From: Robert Sayre <[email-masked]>
Date: Wed, 4 May 2005 14:02:09 -0400

> which the link occurs" when that document is some blog post long since

I don't know. Time is a funny thing. 

I think it would be a mistake to see this as an opportunity to invent
a supremely capable and expressive autodiscovery spec. I've seen
mozilla, safari, NNW do autodiscovery. I'm sure bots from PubSub,
Technorati, Yahoo, etc do it as well. We should document what they do,
and settle on one arbitrary choice where they differ for no good
reason.

Mark's draft does an excellent job of documenting that reality. I
tried to rewrite it once, only to later realize what gross errors I'd
made as I tried to clarify or add features to it. I can assure you
that everything is there for a real-world reason. I suggested a few
changes to section 6, which seems like overspecification to me, but
that's the only thing I suggest we touch.

Robert Sayre

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 04 May 2005 20:02:46 +0200

> line* definition of the 'alternate' relation. It is not contradictory.

But a feed is not a "substitute version" of an "archive page" as most 
archived entries are not in the feed anymore.

That said, I'm totally in favor of using rel="alternate" to link to a 
feed from the _alternate_ HTML version.

 From an archive page, you should rather use rel="start".

Actually, here's my view of those things:
In the "latest news" page (generally the homepage for a weblog):
<link rel="alternate" type="application/atom+xml" href="feed.atom">

In a "category" page:
<link rel="start" type="text/html" href="../index.html">
<link rel="start" type="application/atom+xml" href="../feed.atom">
<link rel="alternate" type="application/atom+xml" href="category.atom">
<link rel="section" type="text/html" href="category/index.html">
<link rel="section" type="application/atom+xml" 
href="category/category.atom">

In a "single-entry archive" page:
<link rel="start" type="text/html" href="../../index.html">
<link rel="start" type="application/atom+xml" href="../../feed.atom">
<link rel="section" type="text/html" href="../index.html">
<link rel="section" type="application/atom+xml" href="../category.atom">
<!-- no alternate -->

However, is this enough for the autodiscovery purpose?

-- 
Thomas Broyer

---

From: "Roger B." <[email-masked]>
Date: Wed, 4 May 2005 13:06:44 -0500

> which the link occurs" when that document is some blog post long since

Eric: A devil's advocacy moment... if I change the published date for
the document to today's date, it will suddenly spring forward into my
feed of recent entries. And at some point in the past, it was already
in that feed.

--
Roger Benningfield

---

From: Dan Brickley <[email-masked]>
Date: Wed, 4 May 2005 14:17:26 -0400

* Eric Scheid <[email-masked]> [2005-05-05 02:35+1000]
> which the link occurs" when that document is some blog post long since

Because the HTML definition is close to meaningless. I can substitute
any document for another, and the 2nd is a substitution not through any 
intrinsic characteristics, but because it was substituted. Many of the 
HTML link type definitions don't bear up under detailed scrutiny...

Dan

---

From: fantasai <[email-masked]>
Date: Wed, 04 May 2005 14:59:38 -0400

> HTML link type definitions don't bear up under detailed scrutiny...

I think you're taking your anarchic interpretation a little too far there.
Especially there: if you read the *spec*, you might notice that the definition
of 'alternate' continues:

   # When used together with the media attribute, it implies a version
   # designed for a different medium (or media).

 From section 12.2.4, we also have

   #  The rel attribute specifies the relationship of the linked document
   # with the current document.

So, according to HTML 4.01 -- which is the definitive spec as far as HTML
is concerned -- the following link

designates a link to a version of the linking document that is
application/atom+xml.

Again, my friend's blog feed is not an Atom version of /my/ web page;
linking to it as "alternate" would be wrong.

~fantasai

---

From: Antone Roundy <[email-masked]>
Date: Wed, 4 May 2005 13:20:07 -0600

> linking to it as "alternate" would be wrong.

To me, this raises a red flag, suggesting that using an autodiscovery 
link from your web page to your friend's feed is not what autodiscovery 
is intended for.

---

From: Tim Bray <[email-masked]>
Date: Wed, 04 May 2005 12:21:22 -0700

On May 4, 2005, at 11:02 AM, Robert Sayre wrote:

> Mark's draft does an excellent job of documenting that reality.

+1.

It's Good Enough.  -Tim

---

From: fantasai <[email-masked]>
Date: Wed, 04 May 2005 15:14:55 -0400

> (not acceptable) response.

Where does it say that including a 'type' attribute on a link forces
the UA to send a restricted Accept header?

~fantasai

---

From: Julian Reschke <[email-masked]>
Date: Wed, 04 May 2005 21:33:19 +0200

+1

Julian

---

From: fantasai <[email-masked]>
Date: Wed, 04 May 2005 15:36:59 -0400

Henri Sivonen wrote:
> (ie. there is deployed code), which is why I was not arguing in favor of 
> rel='feed' per se, but pointing out that the particular reasoning 

It is the case that many, if not most, autodiscovery links *are* linking
to valid alternates of the current page. Taking into account the wide
use of the rel="alternate" type="application/atom+xml" combination, the
spec could be written to

   - specify that any link with rel="feed" and type="application/atom+xml"
     indicates an autodiscoverable Atom feed
   - specify that UAs MAY also recognize the rel="alternate" and
     type="application/atom+xml" combination as an autodiscoverable Atom
     feed even if 'feed' is not among the rel values,
   - but specify that authors SHOULD NOT  (or MUST NOT) leave out the
     'feed' value
   - recommend that links that do indicate a feed version of the current
     HTML page SHOULD link to that feed with both link types

Blogging software is a fast-moving industry. If the draft editor makes
this change and notifies the community, I suspect it will not be long
before most software supports both syntaxes.

~fantasai

---

From: fantasai <[email-masked]>
Date: Wed, 04 May 2005 15:39:56 -0400

> link from your web page to your friend's feed is not what autodiscovery 

Probably not. But the same argument applies if I have an autodiscovery
link from a single entry in my blog to the main blog feed (which is a
valid alternate version of my weblog's front page, but not of that single
entry).

~fantasai

---

From: Graham <[email-masked]>
Date: Wed, 4 May 2005 20:48:26 +0100

On 4 May 2005, at 7:02 pm, Robert Sayre wrote:

> settle on one arbitrary choice

+1

Graham

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 4 May 2005 15:51:11 -0400

+1

   -joe

---

From: "Nikolas 'Atrus' Coukouma" <[email-masked]>
Date: Wed, 04 May 2005 18:49:28 -0400

fantasai wrote:

>> Still, I am well aware that the other things are not equal in this
>> case (ie. there is deployed code), which is why I was not arguing in
>> favor of rel='feed' per se, but pointing out that the particular
>> reasoning against it did not hold water, IMO.
>
>

I think you've missed how things are working at the moment. Most
programs implemented what's in the spec before it's written. Mark is
trying to negotiate a common standard when implementations already
exist. A lot of experimentation has already occurred.

One of the key points seems to be that autodiscovery is not meant to
find all feeds linked to on a page, just the ones that serve as
alternates to the current one. If people wanted this functionality, they
would have done it by now.

I think you have three separate cases of autodiscovery:
* the feed for *this* page - handled by this autodiscovery proposal
* other feeds the author reads or recommends - usually done by linking
to a separate file. Some quick searching reveals one suggestion to use
rel="blogroll" for this
* any other feeds linked to for any reason at all - seems to be little
interest in

I don't think combining these three into one case will do any good. In
fact, I think it's confusing and unusable.

-Nikolas 'Atrus' Coukouma

---

From: "Nikolas 'Atrus' Coukouma" <[email-masked]>
Date: Wed, 04 May 2005 18:49:24 -0400

fantasai wrote:

>> No. To me 'Updates' signifies that something is 'updated'. Even
>> posting  new content falls outside of that definition.
>
>
These are both valid interpretations of "updates." From Princeton's WordNet:
update - n - news that updates your information
- v - 1: modernize or bring up to date; "We updated the kitchen in the
old house"
  2: bring up to date; supply with recent information
  3: bring to the latest state of technology

As this definition suggests, most people think of "updates" as
modifications of items that already exists first and completely new
items second. In the land of feeds, the frequency is reversed (most
"updates" in feeds are new items, not modifications to existing ones).

---

From: "Nikolas 'Atrus' Coukouma" <[email-masked]>
Date: Wed, 04 May 2005 18:49:50 -0400

---

From: "Nikolas 'Atrus' Coukouma" <[email-masked]>
Date: Wed, 04 May 2005 18:49:21 -0400

>which the link occurs" when that document is some blog post long since
I'd suggest placing the link element only on the front page of your blog
if this is a concern. The feed usually is a "substitute version for the
document in which the link occurs" for that, at least. There's nothing
in the spec that even suggests you to place the autodiscovery
information in archive pages. In practice, people probably will, but I'm
not sure it's worth worrying about.

Do you have some example that's more generally applicable?

---

From: Antone Roundy <[email-masked]>
Date: Wed, 4 May 2005 17:06:38 -0600

> not sure it's worth worrying about.

There is a good reason for putting the link in the individual entry 
pages: if people get to your blog via some location other than your 
blog homepage, you don't want them to have to go to your homepage to 
subscribe to your blog's feed.  In such a case, sure, "alternate" 
wouldn't be descriptive of the feed's relationship to the isolated 
page, but the way that such links will be processed by browsers will 
match the intent for publishing the link -> "if you find this entry 
interesting enough to want to subscribe to my feed, here's where to do 
it".

I personally don't care whether it's "alternative" or something like 
"feed".  "Alternative" is a more generally applicable term, but yeah, 
it doesn't sound quite right on individual entry pages.

---

From: Eric Scheid <[email-masked]>
Date: Thu, 05 May 2005 09:26:27 +1000

> From an archive page, you should rather use rel="start".

The problem is, an automaton wouldn't know which to use as it wouldn't know
if the page it is looking at is an entry archive page or a recent entries
page, which rather defeats the purpose of "auto-discovery".

Also, it would be entirely reasonable to use @rel='alternate' to point to an
@type='application/atom+xml' Atom Entry Document from an archive page.

Furthermore, from a recent entries page it would also be entirely reasonable
to use @rel='start' to point to the first archive entry page.

Thus, the meanings of 'alternate' and 'start' would be *reversed* depending
on what kind of page you were looking at. This is not conducive to
hands-free "auto" discovery.

Using @rel='feed' from both kinds of pages fixes that problem.

e.

---

From: Eric Scheid <[email-masked]>
Date: Thu, 05 May 2005 09:35:35 +1000

> HTML link type definitions don't bear up under detailed scrutiny...

Only if you take the most broadest sense of the word 'substitute'.

This is like saying that not only is olive oil a substitute for butter in
cooking, but so is engine oil, concrete, a 400 pound gorilla, and the square
root of the gross national product of madagascar.

No, I suspect they used the word 'substitute' in it's more narrow sense, and
they used the word 'substitute' because they didn't want to write
"alternate: Designates an alternate version for the document in which the
link occurs" which would be circular.

e.

---

From: Eric Scheid <[email-masked]>
Date: Thu, 05 May 2005 09:38:27 +1000

> link from your web page to your friend's feed is not what autodiscovery

I agree.

However, using a link from an archive page is common practice (very!), but
is one that would confound the use of Atom Entry Documents as
@rel='alternate'.

e.

---

From: Kevin Marks <[email-masked]>
Date: Wed, 4 May 2005 17:28:19 -0700

We have published profiles for both license and nofollow:
http://developers.technorati.com/wiki/RelLicense
http://developers.technorati.com/wiki/RelNoFollow

feel free to use them...

---

From: Kevin Marks <[email-masked]>
Date: Wed, 4 May 2005 17:36:48 -0700

How about "alternate" be recommended for only true substitutes; a feed 
for comments or pictures should not be labelled "alternate", as it is 
not a substitute. "feed" is appealing, but does fly in the face of 
practice.

There are existing rel values that could apply to qualify other kinds 
of feeds, or we could suggest new ones.

eg, if it is an titles-only feed, rel="contents" would apply

If you had both full-content and summary feeds available, this could be 
indicated in a machine readable way (I appreciate that Atom handles 
this properly within the format, unlike RSS, but offering both versions 
is something I see many sites doing).

I am amazed that there was no rel="summary" defined by the w3c; this 
would be a useful extension to consider.

http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-links

---

From: Eric Scheid <[email-masked]>
Date: Thu, 05 May 2005 09:40:51 +1000

>    feed even if 'feed' is not among the rel values,

     and that UA should check that the representation returned when
     requesting that resource is an Atom Feed Document, and not an
     Atom Entry Document.

e.

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 5 May 2005 10:06:59 +0300

> http://developers.technorati.com/wiki/RelNoFollow

What value do they add compared to profileless usage?

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: fantasai <[email-masked]>
Date: Thu, 05 May 2005 03:27:20 -0400

> exist. A lot of experimentation has already occurred.

I'm not suggesting that the spec invalidate such well-entrenched practice,
but that it allows an alternative (not requiring 'alternate') for situations
in which it is not appropriate.

 > would have done it by now.

Done what? Linked to non-alternate feeds with rel="alternate" just so
that it would trigger autodiscovery? People do that all the time. Give
them an alternative that doesn't require such a hack.

 > fact, I think it's confusing and unusable.

That makes sense.

I think that you're missing one key use case, though: autodiscovery of
a blog's main feed from sub-parts of it. A lot of websites link to the
main blog feed from individual entries, for example, and they're doing
it with rel="alternate", which is not appropriate. It frustrates me that
there is no way of changing these links to not use rel="alternate".

And for linking to other pages.. Here's a real-world example:
The mozilla.org main page <http://www.mozilla.org/> is an example
of where rel="alternate" is a problem. There were three feeds on
it: "Announcements", "mozillaZine News", and "Mozilla Weblogs"
(now only two). Each one is an alternate of a web page, but of
_other_ pages (http://www.mozilla.org/news.html, http://www.mozillazine.org/, 
and http://planet.mozilla.org/ respectively), not the mozilla.org
front page. The last few headlines for each feed are listed on
the front page, and the designer felt it was appropriate for
autodiscovery to work on this page -- but it is not appropriate
for rel="alternate" to be used for those autodiscovery links.
They are not alternate representations of the front page.

Here's another example:
LiveJournal creates a "Friends" page, where it aggregates the
blogs of all the users you've designated as "friends". It could
create an Atom feed representing this aggregation, and mark that
as rel="alternate". What could also be useful, however, would be
linking to each of these blogs' feeds individually as well so
that they're represented individually in my aggregator and it
can aggregate them itself. Unlike the pre-aggregated feed,
however, these are not alternate representations of the Friends
page, and shouldn't be marked as such.

Making it possible for pages to link to non-alternate autodiscoverable
feeds without using rel="alternate" -- and encouraging this practice --
would make it possible for UAs to actually /discriminate/ between
alternate and non-alternate feeds. Right now they can't, because
everything is indiscriminately marked as "alternate".

~fantasai

---

From: Antone Roundy <[email-masked]>
Date: Thu, 5 May 2005 07:36:46 -0600

On Thursday, May 5, 2005, at 01:27  AM, fantasai wrote:
> _other_ pages (http://www.mozilla.org/news.html, 
> http://www.mozillazine.org/, and http://planet.mozilla.org/ 
> respectively), not the mozilla.org
I'm beginning to sway in the direction of this argument, but I'm not 
sure whether I'll sway back or not.  Given that @type will clearly (for 
Atom and RSS 2 anyway, if not for RSS 1) identify the feed as a feed 
(...or maybe an Atom Entry Document...the feed reader can deal with 
that issue when the user tries to subscribe), I don't think there's a 
big need for @rel to say "feed".  But it wouldn't be illogical for use 
"alternate" for only the feed associated with a particular page 
(perhaps including the case of an individual entry archive page), and 
something else like "related" to point to other feeds.  A UA could 
check @rel and @type and present a UI saying something like "subscribe 
to the feed for this page" and "subscribe to a feed related to this 
page".

---

From: Robert Sayre <[email-masked]>
Date: Thu, 5 May 2005 10:11:36 -0400

> > They are not alternate representations of the front page.

I can see your point, but the autodiscovery spec isn't standardizing
all usages. Just the one we have a good grasp on. Secondly, there's
nothing stopping UAs from "discovering" other feeds. Safari 2.0
already does this.

Robert Sayre

---

From: Sjoerd Visscher <[email-masked]>
Date: Thu, 05 May 2005 22:21:50 +0200

Why not support hyperlinks too?

So besides:

<link rel="alternate" type="application/atom+xml" title="Main Atom feed" 
href="/xml/index.atom">

also:

<a rel="alternate" type="application/atom+xml" 
href="/xml/index.atom">Main Atom feed</a>

Most webpages already have a hyperlink to the feed, so they'd only need 
to add two attributes. It would be a waste to have to duplicate the 
information in the document head.

-- 
Sjoerd Visscher
http://w3future.com/weblog/

---

From: "Nikolas 'Atrus' Coukouma" <[email-masked]>
Date: Thu, 05 May 2005 16:39:45 -0400

Sjoerd Visscher wrote:

> <link rel="alternate" type="application/atom+xml" title="Main Atom
> feed" href="/xml/index.atom">
>
> also:
>
> Most webpages already have a hyperlink to the feed, so they'd only
> need to add two attributes. It would be a waste to have to duplicate
> the information in the document head.
>
The intent of the head element is to indicate a feed that serves as a
substitute for the page you're currently viewing.

This other case is locating all feeds linked to from a page. For that,
the type attribute should be sufficient to indicate that you're linking
to a feed.

---

From: "Bob Wyman" <[email-masked]>
Date: Thu, 5 May 2005 16:35:21 -0400

Fantasia wrote:
> Making it possible for pages to link to non-alternate 
> autodiscoverable feeds without using rel="alternate" -- and 
> encouraging this practice -- would make it possible for UAs to 
> actually /discriminate/ between alternate and non-alternate feeds.
> Right now they can't, because everything is indiscriminately marked 
> as "alternate".
	+1. Being able to distinguish between "alternates" for the current
page and "just other feeds" that are linked to from the page would be very
useful. Also, in the case where there are multiple real alternates to the
page, it would be useful to be able to mark which feed is "preferred." My
concern here is the transition between Atom V0.3 and Atom V1.0. A page might
link to feeds in both formats (as well as RSS, RDF, etc.) but it would be
good to know which of these feeds is considered the "preferred" feed by the
producer. In this way, people could migrate off the older feeds and one day
we'd actually be able to stop producing multiple feeds on each site.
	We should also consider providing such "preferred" links in Atom,
RSS, RDF, etc. feeds. I'd like to be able to publish something in my Atom
0.3 feeds that tell people "Don't keep reading this feed. Read the Atom 1.0
feed instead..."

		bob wyman

---

From: Sjoerd Visscher <[email-masked]>
Date: Thu, 05 May 2005 23:13:10 +0200

> the type attribute should be sufficient to indicate that you're linking

No, a hyperlink with a rel attribute means the same as a link element. 
The HTML spec describes the rel attribute on the a element thus:

This attribute describes the relationship from the current document to 
the anchor specified by the href attribute. The value of this attribute 
is a space-separated list of link types.

---

From: "Nikolas 'Atrus' Coukouma" <[email-masked]>
Date: Thu, 05 May 2005 17:22:48 -0400

> there is no way of changing these links to not use rel="alternate".

An excellent point. Perhaps these should use rel="home" :)

<link rel="home" type="application/atom+xml" href="/xml/feed.atom">

> They are not alternate representations of the front page.

These other feeds are suggestion/blogroll cases.

> as rel="alternate". 

Actually, a patch was just committed to do this ;)

> What could also be useful, however, would be

I think this is a suggestion/blogroll case.

> ~fantasai

I've basically concluded that the keys to autodiscovery of feeds, in the
general sense, should not be three (rel, type, and href), but two (type
and href). Type is plenty of specification that it's a feed. Claiming
it's relationship as "feed" doesn't seem correct. There are a few
mime-types used, and the one for atom (application/atom+xml) will be an
official standard as soon as the draft is accepted by the IETF.

The value of rel, if present, will vary based on relation
* the feed for *this* page - rel="alternate"
* the feed for main feed for this blog, in general - rel="home"
* other feeds the author reads or recommends - rel="suggested"
* any other feeds linked to for any reason at all - no rel, just the
type and href

Is this acceptable? I'm not completely happy with "home" and "suggested"
because they're not specified as link types in the HTML specs [1].
Sadly, it seems the HTML authors didn't consider these cases. "home"
seems to be an informal standard. Close matches in the HTML list are
"index", "contents", and "start". All of these are inaccurate, but I
think "contents" is the best fit.

"suggested" is just my own idea. I mentioned the rel="blogroll" before,
but that seems overly specific. "bookmark" seems to be the closest match
in the HTML list. Not in the way it's defined in the list, but the way
people usually think of it. I'm not sure what the heck the HTML spec is
indicating with:
"Refers to a bookmark. A bookmark is a link to a key entry point within
an extended document. The title attribute may be used, for example, to
label the bookmark. Note that several bookmarks may be defined in each
document."
That definition makes it a close match to "home," I suppose. Really, the
definition there is so vague that it's useless.

I can think of a couple other cases:
- Comment feeds, which are only generated by a few pieces of software so
far. These are close to, but not quite, alternate. they're usually
missing the entry itself, from what I understand. I think more work
needs to be done with comment feeds in general before we worry too much
about linking to them.
-Changelogs. Wikis are one of the use cases for Atom, yes? Perhaps they
should have a rel="changelog" or something similar.

[1] http://www.w3.org/TR/xhtml-modularization/abstraction.html#dt_LinkTypes

---

From: "Nikolas 'Atrus' Coukouma" <[email-masked]>
Date: Thu, 05 May 2005 17:44:04 -0400

Sjoerd Visscher wrote:

> the anchor specified by the href attribute. The value of this
> attribute is a space-separated list of link types.

What I was getting at is that link elements in the head are usually a
kind of metadata intended for the user agent. Hyperlinks are usually
meant to be displayed. This proposal is aimed at providing metadata for
the user agent, so it makes since to put it in a link element in the head.

I'm on the fence about whether or not a link element should be the
*required*, even when a hyperlink is present in the body.

Supporting general hyperlinks starts making more sense if we have cases
other than alternate (I've written elsewhere about this) because the
amount of duplicated information is much greater. If you're only
supporting feeds that serve as an alternate form of the content, then it
makes sense to repeat one link once just to make the programmer stuck
writing the user agent. I'd hope that whatever library/toolkit they're
using supports XPath queries. Using them makes it easy to pluck out
anything with type="application/atom+xml" and an href property.

It's worth noting that in recent versions of XHTML, anything with an
href property is a hyperlink. There's no requirement to use an anchor or
an xlink:link element.

---

From: "Nikolas 'Atrus' Coukouma" <[email-masked]>
Date: Thu, 05 May 2005 17:47:09 -0400

Nikolas 'Atrus' Coukouma wrote:

>writing the user agent.
correction:
"just to make [things easier for] the programmer stuck writing the user
agent."

---

From: "James Tauber" <[email-masked]>
Date: Fri, 06 May 2005 06:26:53 +0800

On Thu, 5 May 2005 16:35:21 -0400, "Bob Wyman" <[email-masked]> said:
> Being able to distinguish between "alternates" for the current
> page and "just other feeds" that are linked to from the page would be
> very useful.

+1

> Also, in the case where there are multiple real alternates to the
> page, it would be useful to be able to mark which feed is "preferred."

+0.5

James

---

From: Sjoerd Visscher <[email-masked]>
Date: Fri, 06 May 2005 00:25:46 +0200

> anything with type="application/atom+xml" and an href property.

Maybe atom needs only one link with a rel attribute, but there are 
others. I have a lot of hyperlinks with rel attributes on my weblog 
homepage, and I refuse to repeat them all as link elements.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 06 May 2005 10:14:02 +1000

> official standard as soon as the draft is accepted by the IETF.

Using @type only is not sufficient, since both Atom Feed Documents *and*
Atom Entry Documents use the same mime-type. One is a feed, the other is
not.

Similarly, RSS 1.0 isn't clearly distinguished by mime-type - there are lots
of other resources which are 'application/rdf+xml' (eg. FOAF)

e.

---

From: fantasai <[email-masked]>
Date: Thu, 05 May 2005 21:22:38 -0400

...
> think "contents" is the best fit.

Actually, I think "start" is the best fit. The main feed is often not a
table of contents to the entire weblog, but something partial. It is,
however, the "starting point of the collection".

BTW, you might want to take a look at

   http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html
   http://fantasai.tripod.com/qref/Appendix/LinkTypes/alphindex.html

~fantasai

---

From: fantasai <[email-masked]>
Date: Thu, 05 May 2005 21:29:01 -0400

> information in the document head.

The difference between <link> and <a> is that
   - <link> applies to the document as a whole: it indicates a relationship
     between this document and the href destination.
   - <a> is a contextual link: it indicates a relationship between the
     linking context and the href destination.

They have different purposes. It is imho perfectly reasonable to limit
autodiscovery to <link>s only. It is also perfectly reasonable to link
to feeds with <a>, and expect that the UA will recognize it as a feed
rather than a generic XML document.

~fantasai

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 6 May 2005 03:40:19 +0200

* fantasai <[email-masked]> [2005-05-04 19:15]:
> How is a link from the top of my homepage to my friend's weblog
> feed designating a "substitute version for the document in
> which the link occurs"?

It’s not. And it’s offtopic. It’s called the “autodiscovery”
spec, not the “feed directory” spec. If you want to link your
friend’s blog’s feed, supply an OPML or FOAF blogroll. Covering
this ground is not within the scope of autodiscovery.

Regards,
-- 
Aristotle

---

From: "Nikolas 'Atrus' Coukouma" <[email-masked]>
Date: Thu, 05 May 2005 22:30:59 -0400

> however, the "starting point of the collection".

Actually, I disagree with start because of the first sentence in the
HTML spec:
"Refers to the first document in a collection of documents."
This indicates that start should point to the first post in a weblog.
end would be the most recent (not that end exists in the HTML spec)

"This link type tells search engines which document is considered by the
author to be the starting point of the collection."
This is a completely different meaning and I'm not sure why it's bundled
with the first. According to this, start pointing to the homepage is fine.

 The end or last would be the most recent (not that the HTML specs have
an end or last rel)

>   http://fantasai.tripod.com/qref/Appendix/LinkTypes/alphindex.html

No offense, but with all the tripod ads, I would have much preferred a
link to the "Hypertext links in HTML" draft [1]. Section four is what I
want. It's not indexed alphabetically and doesn't combine other
documents, but it's the covers everything pretty well.

[1] http://www.w3.org/MarkUp/draft-ietf-html-relrev-00.txt

-Nikolas 'Atrus'

---

From: "Bob Wyman" <[email-masked]>
Date: Thu, 5 May 2005 22:39:37 -0400

> href="/xml/index.atom">Main Atom feed</a>
	One very interesting side-effect of putting the autodiscovery data
in elements of the body is that it then becomes visible in many more
environments. For instance, if I were to cut some text from a web page and
paste it into blog post or another web page, then if that text had links
with rel="alternate" in it, those links would travel along with the quote.
If I built a page of quotes from many sites, I might end up with "alternate"
links to many different sites, feeds, etc. This might not be as "bad" as it
sounds...
	This might argue against using "alternate" in body elements that
might be cut out and pasted into or quoted in other pages since clearly, the
thing which is an alternate is an alternate of the page which originally
contained the quote -- not the page into which the quote has been pasted or
an alternate form of the quote itself.
	While there are some problems to be worked on, I very much like the
idea of a chunk of HTML carrying around some indication of its provenance,
original source and alternate sources. 

		bob wyman

---

From: "Nikolas 'Atrus' Coukouma" <[email-masked]>
Date: Thu, 05 May 2005 23:07:46 -0400

>of other resources which are 'application/rdf+xml' (eg. FOAF)
Hrm. This is an interesting point. I'm not too concerned about "find
every feed, regardless of relevance" because I think only search engines
will be interested in it, especially if all the other cases are marked.
They can bear to check the feed and see what the root element is.

This also makes rel="alternate" seem like an even worse choice for
*feed* autodiscovery because it would make sense to link to an atom
*entry* as rel="alternate" from the page for an individual entry.

I really don't think @rel is the place to address concerns about type.
That's really the job of @type (of course). If we need to declare more
mime-types, then so be it.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 06 May 2005 16:18:39 +1000

> will be interested in it, especially if all the other cases are marked.

finding every feed is not my concern either.

> They can bear to check the feed and see what the root element is.

this won't work ... see below.

> *entry* as rel="alternate" from the page for an individual entry.

absolutely!

> mime-types, then so be it.

Just to throw more fuel on the fire:

It is quite conceivable for an Atom Feed Document (AFD) to contain a set of
entries which won't grow or be updated, such as an AFD which contains all
postings for a calendar period, or an AFD which contains one entry for each
chapter of a book, and so on.

Thus, neither mime-types nor root-element-sniffing will be reliable enough
to discover the resource which is appropriate for "subscribing" to - ie.
discovering which Atom Feed Document is the one which will be updated as
time goes by in the usual sliding window manner, and not the monthly archive
that page happens to be contained within.

e.

---

From: Sjoerd Visscher <[email-masked]>
Date: Fri, 06 May 2005 09:47:59 +0200

> rather than a generic XML document.

Like I wrote before, this is not how HTML 4.01 (or XHTML 2.0 for that 
matter) defines the rel attribute on a hyperlink:

---

From: fantasai <[email-masked]>
Date: Fri, 06 May 2005 04:08:02 -0400

> end would be the most recent (not that end exists in the HTML spec)

I think "first" here should not be taken as chronological, but as

> link to the "Hypertext links in HTML" draft [1].

Sorry.

> Section four is what I want. It's not indexed alphabetically and
> doesn't combine other documents, but it's the covers everything
> pretty well.
> 

Not quite everything. Some of the values (like "start") are not
covered in that draft.

~fantasai

---

From: "Nikolas 'Atrus' Coukouma" <[email-masked]>
Date: Fri, 06 May 2005 04:02:40 -0400

>that page happens to be contained within.
This warrants groaning. I think it's safe to say that user agents
shouldn't subscribe to entry docments. Feeds may be worth bothering with.

Source: (HTML/XHTML)
Clearly the friendlier end to do autodiscovery on. Remember, the goal
here is to indicate that the URI from @href is worth subscribing to. I'm
running out of attributes to abuse.
From the XHTML Link Module: [1]
charset, href, hreflang, media, rel, rev, type
Link Module: [2]
target

All of these are listed in the 4.01 spec[3]. There's also the slim
chance of using XLink's link semantics [4]. They seem to be mostly
redundant with @target.

Speaking of @target, I'm currently favoring it because it's used for
indicating where a link whould be loaded. This makes a hair more sense
with today's browser-feed integration.

Destination: (Atom)
The only way I can see to indicate that a feed is "alive" and worth
subscribing to (assuming existing Atom spec) is to include cache control
(Expires or Cache-Control headers).

[1]
http://www.w3.org/TR/2004/WD-xhtml-modularization-20040218/abstract_modules.html#s_targetmodule
[2]
http://www.w3.org/TR/2004/WD-xhtml-modularization-20040218/abstract_modules.html#s_linkmodule
[3] http://www.w3.org/TR/html4/struct/links.html#h-12.3
[4] http://www.w3.org/TR/xlink/#link-semantics

---

From: "Nikolas 'Atrus' Coukouma" <[email-masked]>
Date: Fri, 06 May 2005 04:31:45 -0400

> attribute is a space-separated list of link types.

Using @rel with any linking element is perfectly valid and has been for
years.
@rel not being supported for anything other than the link element itself
has also been an outstanding bug for just as long. There's lot of debate
attached to at least one Mozilla bug (#57399 [1] - filed on 2000-10-20).

Can we agree that this should be supported, but currently isn't? Unless
there's a compelling reason not to, I think we might as well allow
autodiscovery via either element. Any implementation guide should
recommend duplicating the information in the interest of autodiscovery
actually working.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=57399

---

From: Nikolas Coukouma <[email-masked]>
Date: Fri, 06 May 2005 08:02:19 -0400

> attribute is a space-separated list of link types.
Completely separately, to the anchor versus link debate:
"space-separated list of link types."
is a find worthy of points (redeemable at your local ego shop).

This means we can have our pie and eat it too.

If we define rel="feed", there's no reason it can't be combined with 
other rel types :) For example, we could allow
<link rel="alternate feed" type="application/atom+xml" 
href="http://www.example.com/xml/index.atom">
<link rel="start feed" type="application/atom+xml" 
href="http://www.example.com/xml/index.atom">

Using @rel for type-ish hinting is an ugly hack, but this allows us to 
at least let @rel function the way it was intended to in addition to the 
hack.

It's that or choose another attribute to be our victim

---

From: Sjoerd Visscher <[email-masked]>
Date: Fri, 06 May 2005 20:08:56 +0200

> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=57399

Yes, absolutely, that was my point. As David Baron says in Bugzilla: 
"The spec was designed with the idea that any application that looked at 
rel/rev on LINK elements should do the same for A elements."

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 6 May 2005 15:21:19 -0400

Sjoerd Visscher wrote:
> [HTML 4.01 says:] This attribute describes the relationship from
> the current document to the anchor specified by the href attribute.
> The value of this attribute is a space-separated list of link types.
	But, if you copy HTML from one document to another, or you construct
an HTML document from parts, you risk carrying <a> tags with rel attributes
from one document to another. If I quote some HTML in a new HTML document
and the quoted HTML includes rel="alternate" in an <a> tag, are we really
saying that the presence of rel="alternate" in the quoted text establishes a
relation of the new HTML document as a whole?
	Personally, I think there is a serious scoping problem here. We've
got attributes of separable components of a page establishing metadata for
the page as a whole. Not good.

		bob wyman

---

From: "Nikolas 'Atrus' Coukouma" <[email-masked]>
Date: Fri, 06 May 2005 18:53:07 -0400

>the page as a whole. Not good.
Since the HTML spec is where this originates, I'm inclined to say that
this is something that should be handled by whatever is manging content
(user or program) is copying the link. Clearly, @rel should be copied
with caution or simply left behind entirely.

I think calling this "components of a page establishing metadata for the
page as a whole" is a bit misleading. The metadata (@rel) say nothing
about the document it's in. It's metadata about the link between the two
documents. This metadata is context-Dependant because it depends on an
implicit @from counterpart to the explicit @href (@to, in XLink).

<link> and <a> both suffer from this weakness. I can't pick up a link
element from one element and move it to another. I can have a pile of
them in the template I use to make my pages.

It's considered a usability problem in the case of <a> because <a>
appears in a place where it's a it more likely to be copied: the body.
The problem is fortunately mitigated because user agents usually only
offer copying @href ("copy link location"). I'm under the impression
that they do something similar with rich-text copying. If someone's
copying HTML "source" by hand, then they should know to be wary of @rel.
The best we can do is add a note.

It's also not likely to bother programs that put content into
syndication feeds because links to feeds generally appear in the
periphery of presentation and not the main content of a feed. If people
do include @rel in content that's included in syndicated content, then
it should be stripped.

Again, no one uses @rel in <a> because it's unsupported. Coincidentally,
most programs do the right thing. If we push for @rel support in <a> in
the autodiscovery spec, then I think there may be an increase in usage,
at which time users can authors can educate themselves and programs can
make changes. They should have done this years ago. We're not creating
@rel, just encouraging it's use.

All of that said, it seems sensible to include a warning or a note or
somesuch.

---

From: Phil Ringnalda <[email-masked]>
Date: Fri, 06 May 2005 19:50:40 -0700

> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=57399

-1 to saying in the spec that you can use either element, and in the 
guide saying to use both if you want it to work, not just look pretty.

As I remember it, when RSS autodiscovery started this cowpath, 
aggregator developers generally didn't have an SGML parser handy, and 
weren't especially happy about the idea of having to write their own 
HTML parser. Finding one (or a few) of relatively few <link>s in the 
first bit of the document feels a lot easier than having to look at 
every <a> in the whole document.

Now? I'd say most don't have an SGML parser handy, and won't be 
especially happy about writing their own HTML parser. It's fairly rare 
for someone to comment out bits of their <head>, and quite common for 
them to comment out huge swaths of their <body>, including things a 
template came with, like <a href="../xml/index.atom" rel="feed">Atom 
feed</a>, with no thought that something will be seeing and using that 
invisible link with an incorrect path. I added Atom autodiscovery to my 
current aggregator, Feed on Feeds, with a ten second copy/paste/change 
mime-type of the results of it using a regular expression on the HTML. 
If instead I had to correctly parse the entire HTML document, I'd... 
switch to something in Python, I guess.

Then, since I foolishly took the Firefox bug for better autodiscovery, 
I'll also need to do it where I do have an excellent HTML parser, but I 
have to do it on every single page that every single Firefox user loads, 
whether or not they have any interest in feeds, or subscribed to the 
feed ten thousand loads of that particular page ago. <link> is easy, 
we've got a DOMLinkAdded event and most pages have very few of them. 
<a>? Well, the performance hit probably won't be noticeable on most pages.

Phil Ringnalda

---

From: "Nikolas 'Atrus' Coukouma" <[email-masked]>
Date: Sat, 07 May 2005 00:31:58 -0400

> guide saying to use both if you want it to work, not just look pretty.

You're absolutely right. I was thing in more immediate terms before, but
if we're going to make this part of the Atom working group, land of
well-defined and reasonable specs, everything should work.

> invisible link with an incorrect path. I added Atom autodiscovery to
> my current aggregator, Feed on Feeds, with a ten second
> copy/paste/change mime-type of the results of it using a regular
> expression on the HTML. If instead I had to correctly parse the entire
> HTML document, I'd... switch to something in Python, I guess.

Is there something wrong with the HTML parsers?
Perl has HTML::Parser
Python has htmllib.py
Ruby has ymHTML and a port of of the Python library called html-parseer
PHP has PHP-HTML
Common Lisp has phtml
The W3C  provides a simple parser written in C

I'm sure I can find more, but I think the above is a sufficiently long
list to illustrate my point.

> I'll also need to do it where I do have an excellent HTML parser, but
> I have to do it on every single page that every single Firefox user
> loads, whether or not they have any interest in feeds, or subscribed
> to the feed ten thousand loads of that particular page ago. <link> is
> easy, we've got a DOMLinkAdded event and most pages have very few of
> them. <a>? Well, the performance hit probably won't be noticeable on
> most pages.

This is a single XPath query.  Gecko has native support for it. I'm not
sure about the others, but Sarissa is a fine library for DOM
manipulation (including XSLT and XPath) from Javascript and it works
with IE, KHTML, Opera ...

> Phil Ringnalda
Of course, if your XML library copes with all the errors present in
normal HTML, it's probably nicer to use than any HTML parser.

The point here is that most developers have access to an HTML parser. I
admit that they might need patching, but at least 90% of the work is done.

I'll try to find time to examine each of these libraries and make any
changes needed. Hopefully they're already in good shape or the author is
open to this sort thing. If all else fails, there's forking.

If the problem is ignorance, I'll happily maintain a list. I'm also
willing to write some sample implementations in all of the languages I
listed before and more.

I don't think this is terribly difficult. In fact, I just took a shot at
altering Feeds on Feeds to support this and found it incredibly easy.

patch: http://zaphod.student.umd.edu/~atrus/FoF_mod/a-support.patch
There's other stuff in the same directory there if you want to poke at
it. The changes just use PHP-HTML, which I mentioned earlier.

Cheers,

---

From: "Roger B." <[email-masked]>
Date: Sat, 7 May 2005 00:13:47 -0500

> Is there something wrong with the HTML parsers?

Nikolas: Are they installed by default on most servers? If not, can
those running in sandboxes install them?

From the perspective of my niche, I can tell you that Coldfusion can
use jTidy to make sense of random HTML, but it is (a) installed in
virtually zero CF hosting environments, and (b) cannot normally be
added by an individual developer working in a sandbox. (It's also
riddled with bugs, but I'm just grateful to have it at all... I steer
clear of gift horses' mouths whenever possible.)

--
Roger Benningfield

---

From: "Roger B." <[email-masked]>
Date: Sat, 7 May 2005 00:41:08 -0500

> The problem is fortunately mitigated because user agents usually 
> only offer copying @href ("copy link location").> I'm under the 
> impression that they do something similar with rich-text copying.

Nikolas: Your impression is mistaken. If I copy a chunk from Zeldman's
XFN-friendly links page and paste it into my WYSIWYG editor, I get all
of his @rel="whatevers" in my post. This is the same behavior I've
noted in every IE- and Mozilla-based WYSIWYG editor I've tried.

--
Roger Benningfield

---

From: "Nikolas 'Atrus' Coukouma" <[email-masked]>
Date: Sat, 07 May 2005 07:50:04 -0400

>those running in sandboxes install them?
Everything except perhaps the C libraries. All the other implementations
I listed are written  purely in their respective scripting language and
should work if you just copy the source. Well, there's the possiblity
that some require an obscure lib somewhere, but the source I skimmed
indicated that they were based on basic string functions and/or regular
expressions. I should also note that I'm not sure how well each of them
stands up to crazy real world input because I've never tried using them
on arbitrary pages.

Hrm, I find, or make up, some test inputs ...

>clear of gift horses' mouths whenever possible.)
My condolences.

---

From: "Nikolas 'Atrus' Coukouma" <[email-masked]>
Date: Sat, 07 May 2005 08:03:22 -0400

>noted in every IE- and Mozilla-based WYSIWYG editor I've tried.
Crud. To the bug databases I go.

---

From: Kevin Marks <[email-masked]>
Date: Fri, 13 May 2005 17:28:15 -0700

> the page as a whole. Not good.

Bob, you're the one making them seperable. The HTML spec is very 
document-focused; when you migrate HTML from one document to another, 
it is your responsibility to do it in a coherent way. Revising rel 
values is analogous to changing relative links in the href's.

After all, the 'next', 'previous' 'contents' etc rel values also need 
care when migrating, so it's not just 'alternate' or 'friend'.