Subject: PaceResurrectAutodiscovery

From: James M Snell <[email-masked]>
Date: Tue, 21 Nov 2006 15:15:39 -0800

Pace to put autodiscovery back in play [1]

Resubmit the Autodiscovery Draft[2] with no changes and submit for
consideration as a Proposed Standard.

[1] http://www.intertwingly.net/wiki/pie/PaceResurrectAutodiscovery
[2] http://ietfreport.isoc.org/idref/draft-ietf-atompub-autodiscovery/

- James

---

From: Henry Story <[email-masked]>
Date: Tue, 21 Nov 2006 15:33:30 -0800

On cursory glance, it seems like a good idea.

Henry

---

From: Eric Scheid <[email-masked]>
Date: Wed, 22 Nov 2006 11:05:31 +1100

> consideration as a Proposed Standard.

I'd rather it be updated to take into consideration that Atom has introduced
the concept of entry documents alongside feed documents, and thus a link to
a "application/xml+atom" document with a relationship attribute value of
"alternate" is now ambiguous.

I suggest a relationship value of "feed", to use when pointing to a feed.
Note that multiple values for @rel are still possible with html's link (e.g.
@rel="feed alternate").

This also covers the case of a html page containing articles {A,B,C} linking
to a feed which, by now, contains {X,Y,Z}, which is hardly an "alternate
representation" of the same content.

e.

---

From: James M Snell <[email-masked]>
Date: Tue, 21 Nov 2006 16:22:03 -0800

My preference would be to maintain the de facto standard that is already
in use by countless sites.  I'm just as annoyed as you are about the
ambiguity in the mime type but in this case I think what's currently
deployed trumps what's technically correct.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 22 Nov 2006 02:23:56 +0100

* Eric Scheid <[email-masked]> [2006-11-22 01:20]:
> I suggest a relationship value of "feed", to use when pointing
> to a feed. Note that multiple values for @rel are still
> possible with html's link (e.g. @rel="feed alternate").

-1 to any changes that would be incompatible to existing dead
draft, at any time.

-1 also to changing the draft at all prior to resurrection. We
can see whether we want any new language in there once we have it
back in the process.

+0 to including *additional* provisions in the draft before
submitting it for approval, because I do agree it’s incomplete.

I’d like to see the current status quo documented. There are
millions of pages out there already implementing autodiscovery
according to the dead draft, and lots of code to process them,
but there is no official documentation for any of this. There
should be a spec for it.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Eric Scheid <[email-masked]>
Date: Wed, 22 Nov 2006 15:32:58 +1100

> -1 to any changes that would be incompatible to existing dead

agree, I too prefer no incompatibilities, and I don't see what I proposed as
being incompatible (slap me if I'm wrong).

> can see whether we want any new language in there once we have it

agree, although this is just a matter of process. So, +1 to resurrect, -1 to
"and submit for consideration as a Proposed Standard."

> submitting it for approval, because I do agree it¹s incomplete.

agree.

e.

---

From: Eric Scheid <[email-masked]>
Date: Wed, 22 Nov 2006 15:46:13 +1100

> deployed trumps what's technically correct.

That's like saying candles and oil lamps trump Mr. Edison's delightful
invention. Sure, when he came up with the idea there were not many adopters,
but just look around today.

Maybe a robust de facto standard will arise. Or maybe a hodge-podge of
incompatible almost-solutions get deployed. How many varieties of (e.g.) RSS
are there again?

We're in a good position, in this WG, to suggest a future standard. We've
delved deeply into the intricacies, we've examined a wide range of use
cases.

Speaking of which ... there's another use case to consider. Since Atom has
promoted interest in using feed documents in an archival manner, it is
entirely reasonable to use @rel="alternate" to point to an archive feed
document which contains the *same* content as the referring page, as opposed
to referring to a feed document which has the "most recent" additions from
the same source as where the contents of the current page came from. (what a
mouthful!)

The archival feed document is truly the "alternate" for the html page
"entries of october 2006", while the subscription feed document for the same
source (and containing entries mostly from November 2006) would be the
"feed" document.

Sure, when it comes to turning back the tide to *deprecate* the use of
@rel=alternate for subscription feeds in lieu of archival feed documents,
I'm fully in agreement that current practice trumps that idea.

The other idea though of using "feed" to indicate the resource one would
subscribe to so as to be _fed_ more of the same content ... that doesn't
conflict with current practice and we can lay the ground work for future
adoption.

e.

---

From: Henry Story <[email-masked]>
Date: Wed, 22 Nov 2006 16:32:10 -0800

I agree. It would be useful to work on placing a little bit more  
weight on the rel relation rather than putting everything on the mime  
type. After all if every link is going to be an "alternate" relation,  
then what was the point of the rel="..." attribute? We might as well  
have stuck with simple <a href=""> anchors.

I think there is still time to put forward a number of simple  
relations such as "feed", "entry" or even "service" or "collection".  
This could be really useful distinctions.

Henry

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 23 Nov 2006 22:05:32 +0200

The latest WA 1.0 draft covers this as follows:

"If the alternate keyword is used with the type attribute set to the  
value application/rss+xml or the value application/atom+xml, then the  
user agent must treat the link as it would if it had the feed keyword  
specified as well."
http://whatwg.org/specs/web-apps/current-work/#alternate0

"The feed keyword indicates that the referenced document is a  
syndication feed. If the alternate link type is also specified, then  
the feed is specifically the feed for the current document;  
otherwise, the feed is just a syndication feed, not necessarily  
associated with a particular Web page."
http://whatwg.org/specs/web-apps/current-work/#feed0

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

---

From: Henry Story <[email-masked]>
Date: Thu, 23 Nov 2006 12:42:26 -0800

Very nice.

One thing I like about the current atom spec, is that the link  
relations are in fact urls. The link relations are equivalent to the  
urls generated by appending "http://www.iana.org/assignments/ 
relation/" to the "alternate", "self", ... rel="..." strings.

This is very nice, in that it opens up the possibility of placing  
good RDF descriptions of these links at the http://www.iana.org/ 
assignments/relation/, as well as making the link relation very  
extensible (people who want to try out new link relations, can just  
use their own, unambiguous url).

I would recommend you adopt that too. Perhaps you can even adopt the  
iana name space. If we could get them to put the appropriate rdf  
document at that location, people who created/coined new link  
relations could describe these relations as being superproperties or  
subroperties of relations the browser already knows, which would  
allow the browser to partially interpret those.

Just a thought.

Henry

On 23 Nov 2006, at 12:05, Henri Sivonen wrote:

> "If the alternate keyword is used with the type attribute set to  
> the value application/rss+xml or the value application/atom+xml,  
> then the user agent must treat the link as it would if it had the  
> feed keyword specified as well."
> syndication feed. If the alternate link type is also specified,  
> then the feed is specifically the feed for the current document;

---

From: "Thomas Broyer" <[email-masked]>
Date: Thu, 23 Nov 2006 23:28:59 +0100

> http://whatwg.org/specs/web-apps/current-work/#alternate0

This conforts me in thinking that the application/atom+xml media type
should be updated to add a "type" parameter with values "feed" and
"entry".
There would be no ambiguity between these two links:
<link rel="alternate" href="application/atom+xml;type=feed"
   title="This is a feed, which happens to be an 'alternate' of the
current page" />
<link rel="alternate" href="application/atom+xml;type=entry"
   title="This is a standalone entry" />

I expect aggregators to allow me to subscribe to feeds (subscribe in
the sense or "watch for new –or updated– entries) or individual
entries (subscribe in the sense of "watch for updates"). With
rel="alternate" and an RSS or Atom media type, those aggregators could
show a "subscribe to this page" button. With an RSS or Atom media type
and another 'rel', they could a "subscribe to {@title}" button.

For example, with these two links:
<link rel="contents" type="text/html" href="/index.html" />
<link rel="contents" type="application/atom+xml" href="/feed.atom" />
a browser could show "Go to Table of Contents" and "Subscribe to Table
of Contents" buttons.

> syndication feed.

"Being a syndication feed" is expressed by the media type, there's no
need for a 'rel' value.

The only reason for such a 'rel' is to replace the "contents" value in
the example above:
<link rel="feed" type="text/html" href="/index.html" />
<link rel="feed" type="application/atom+xml" href="/feed.atom" />
in "blog-like" use-cases where an HTML page serves the same purpose as
a syndication feed, just in an 'alternate' format.

-- 
Thomas Broyer

---

From: Henry Story <[email-masked]>
Date: Thu, 23 Nov 2006 14:43:06 -0800

> a syndication feed, just in an 'alternate' format.

Exactly: you have just made one good point why one should not use  
mime types to identify the relation. After all there may be many  
different feed representations: html, rss 1.0, rss 2.0, atom,   
rdf, ... etc...

There are many other good reasons to not use the "alternate" relation  
everywhere. The spec [1] for feed makes the case for a useful  
distinction between a feed that can be used to track updates of the  
content one is looking at, and something that is just an alternate  
representation of the content one is looking at expressed in  
application/atom+xml format. This would be the case for the front of  
my blog page.

Henry

[1] http://whatwg.org/specs/web-apps/current-work/#feed0

---

From: Eric Scheid <[email-masked]>
Date: Fri, 24 Nov 2006 12:31:35 +1100

> "Being a syndication feed" is expressed by the media type, there's no

I disagree, but for slightly different reasons. Consider these two links:

    <link rel="feed"
        type="application/atom+xml;type=feed" href="/latest.atom" />
    <link rel="alternate"
        type="application/atom+xml;type=feed" href="/2006/10.atom" />

They are both Atom Feed Documents, but the former is the syndication feed to
which one would reasonably subscribe to for delivery of more content like
you're looking at, and the latter is simply an alternate representation of
the current content (in this case being an archive page for October 2006),
and subscribing to it would be foolish.

Also, how do we have syndication feeds in different representation formats
(eg. RSS), or are you proposing the ";type=feed" gets appended to all the
various media types as needed?

> associated with a particular Web page."

There's a third case they don't mention here, which is if 'alternate' is
used but 'feed' is not also specified ... in which case it's not a "feed" in
the sense of a source of continuing updates, but more like a static resource
(subject to the usual bit rot and tweaky updates).

The three cases are:

    @rel="feed"
    @rel="alternate feed"
    @rel="alternate"

Would be nice if there was an RFC we could point at which clarified what is
meant by each. Would go a long way towards overcoming deployment inertia.

e.

---

From: Lachlan Hunt <[email-masked]>
Date: Fri, 24 Nov 2006 15:52:22 +1100

> consideration as a Proposed Standard.

I don't think that's a good idea for several reasons, primarily because 
feed autodiscovery isn't just for Atom, it's for RSS, RDF and other 
syndication formats as well; the quality of the spec is poor; and, as 
Henri pointed out, Web Apps 1.0 is already defining it.  See below for a 
more detailed explanation.

> I suggest a relationship value of "feed", to use when pointing to a feed.

I agree.

> deployed trumps what's technically correct.

I agree that compatibility with existing practice is important, but that 
doesn't mean the situation can't be improved in a backwards compatible way.

Thomas Broyer wrote:
> Henri Sivonen wrote:

For the user, why would such a distinction be useful?  Also, given what 
the WA1 says about rel="alternate feed":

   If the alternate link type is also specified, then the feed is
   specifically the feed for the current document

Then wouldn't that have effectively the same meaning when used on an 
individual article's page?

> "Being a syndication feed" is expressed by the media type, there's no

No, the MIME type only indicates the format, not the type of relattionship.

> http://ietfreport.isoc.org/idref/draft-ietf-atompub-autodiscovery/

The sections Syntax rules inherited from HTML and Syntax rules inherited 
from XHTML are not useful.  In the case of XHTML, the syntax is defined 
by XML.  In the case of HTML, the syntax is defined in HTML4 (though 
it's being redefined in HTML5).  It is not necessary for this spec to 
provide a summary of the syntax rules, although it may do so 
informatively, it should instead normatively refer to the HTML 4.01, 
XHTML 1.0, XML 1.0 and/or (X)HTML5 specs.

The value of the rel attributes are being defined in Web Applications 
1.0, as Henri pointed out already.  The spec should not mandate the use 
of "alternate" for syndication feeds, but rather define "feed" and 
specify the conditions under which "alternate" implies "feed" (for 
backwards compatibility).  That is what WA1 does.

When rel="feed" is used, the type attribute should not be required, and 
it most certainly must not specify specific MIME type to use.  There are 
various syndication formats in use, including Atom, RSS and RDF. 
Although, for compatibility when alternate is used, UAs need to treat 
application/atom+xml and application/rss+xml specially to imply feed, 
the latter may use application/rdf+xml and all three of those may also 
use application/xml and (although not recommended) text/xml.

The spec should not require that autodiscovery only work for <link> 
elements.  The rel and type attributes may also be used on <a> elements 
and, although not all existing UAs currently support that, the spec 
should define that either <link> or <a> may be used.

 From the spec:

| Each autodiscovery element SHOULD point to a different Atom feed.

How should UAs handle cases where 2 links point to the same location? 
Should both be presented to the user separately?  Should one take 
precedence of the other?  Which one: the first one?  What if one is a 
<link> and the other is an <a> in the document?  It's common for pages 
to include both like that, given that currently only <link> works for 
autodiscovery and <a> is useful for UAs that don't support autodiscovery.

The sections  rel attribute variations, type attribute variations and 
link element variations read like a bunch of test cases.  It's good to 
provide examples, but these sections have no normative requirements and 
it's unnecessary to provide examples for virtually every possible 
variation.  The examples should ideally be moved up to the sections that 
state the normative requirements about the syntax, not be separate 
sections on their own.

The references to HTMl4 and XHTML1 should be normative references, not 
informative, because those specs define the syntax and semantics of the 
elements being used.  In other words, it's a requirement that, any UA 
implementing this spec, also implements the relevant sections of those 
specs.

However, since the Web Applications draft already covers all of these 
issues fairly well, I believe it is unnecessary for this draft to be 
resurrected.  Instead, a few of the good ideas from this draft should be 
integrated into the WA1 spec.

-- 
Lachlan Hunt
http://lachy.id.au/

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Fri, 24 Nov 2006 14:12:11 +0800

> Web Apps 1.0 is already defining it

> integrated into the WA1 spec.

Web Applications 1.0 is new markup language based on HTML under development. UAs that support feed autodiscovery are not necessary to support Web Apps 1.0. Relying on the definitions in the specification of Web Apps 1.0 is not appropriate.

The reason of using "alternate" is that, "alternate" was already defined the HTML 4.01 Specificiation and it is widely used by UAs. [ http://www.w3.org/TR/html401/types.html#type-links ]

If we need to define more link type, we may need to do the following as recommended by the specification.

"Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details."

On the other hand, the W3C Widgets 1.0 autodiscovery is also using "alternate". [ http://www.w3.org/TR/widgets/#autodiscovery ]

> should define that either <link> or <a> may be used.

I think that only <link> should be used. All feeds linked by <a> should be ignored during the process of autodiscovery.

Franklin Tse

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lachlan Hunt
Sent: Friday, November 24, 2006 12:52
To: atom-syntax
Subject: Re: PaceResurrectAutodiscovery

I agree.

 From the spec:

-- 
Lachlan Hunt
http://lachy.id.au/

---

From: Lachlan Hunt <[email-masked]>
Date: Fri, 24 Nov 2006 18:44:42 +1100

Tse Shing Chi (Franklin/Whale) wrote:
>> However, since the Web Applications draft already covers all of 
>> these issues fairly well, I believe it is unnecessary for this 
>> draft to be resurrected.  Instead, a few of the good ideas from 
>> this draft should be integrated into the WA1 spec.
> 
> Web Applications 1.0 is new markup language based on HTML under 
> development. UAs that support feed autodiscovery are not necessary to 
> support Web Apps 1.0. Relying on the definitions in the specification 
> of Web Apps 1.0 is not appropriate.

They don't need to support it fully, UAs can just implement the parts 
they need.  The relationships can still be defined within it, just like 
many were defined in HTML4.

> The reason of using "alternate" is that, "alternate" was already
> defined the HTML 4.01 Specificiation and it is widely used by UAs. [
> http://www.w3.org/TR/html401/types.html#type-links ]

I'm aware of the reason for choosing alternate originally and I accept 
that it needs to be supported like that for backwards compatibility, but 
that doesn't mean we can't fix the mistake.

> "Authors may wish to define additional link types not described in
> this specification. If they do so, they should use a profile to cite
> the conventions used to define the link types. Please see the profile
> attribute of the HEAD element for more details."

The profile attribute isn't used in reality.  Authors rarely set it, or 
it's set by their CMS to some default value and they don't bother to 
change it.  Many of the tools that implement microformats don't even 
bother to check for the presence of the correct profile attribute, they 
just look for the values of the rel and class attributes.  The profile 
attribute will most likely be dropped from HTML5.

> On the other hand, the W3C Widgets 1.0 autodiscovery is also using
> "alternate". [ http://www.w3.org/TR/widgets/#autodiscovery ]

That's currently a first working draft and I think that's a mistake, 
rel="alternate" is not designed as a relationship for everything, it was 
designed for the specific purpose of linking to alternative 
representations.  In the case of feeds, it sort of fits the definition, 
though not completely, but it certainly doesn't in the case of a widget. 
  They should instead define something like rel="widget" because a 
widget is not necessarily an alternate representation of a document.

> I think that only <link> should be used. All feeds linked by <a>
> should be ignored during the process of autodiscovery.

Why?

-- 
Lachlan Hunt
http://lachy.id.au/

---

From: "Thomas Broyer" <[email-masked]>
Date: Fri, 24 Nov 2006 09:28:40 +0100

> different feed representations: html, rss 1.0, rss 2.0, atom,

My problem is that:
1. there is no need for a "feed alternate" as spec'd by the WhatWG:
   - when you (as an autodiscovery tool) look at a resource, it might
point to a 'feed' within which it is an 'entry' (or 'item'), this
'feed' might be many different formats, if it happens that you know
how to subscribe to one of the proposed formats, you can provide a
"subscribe to feed" ("within which the current 'page' is an 'item'"
implied) button;
   - when you look at resource which is a 'feed' (and this kind of
thing cannot be "autodiscovered"), then you'll have links to other
formats as 'alternate's, if it happens that you know how to subscribe
to on the proposed formats, you can provide a "subscribe to _this_
feed" (or "subscribe to this page") button
The condition to show a "subscribe" button is whether you know how to
deal with the format, the text you'll use on the button depends on the
relation of this "feed resource" wrt the "current page".
2. stating that if rel="alternate" and @type is RSS or Atom (feed or
entry), then treat the same as rel="feed alternate" is a Bad Thing:
the 'alternate' might be a standalone Atom entry, or might be an
"archive feed": in the former case, a type=entry would disambiguate
it; in the latter case, you'll still provide a "subscribe button"
(because you have no mean to detect it is an "archive feed" without
downloading it) but when the user will click it and you'll dereference
the link, you'll pop up a "the feed is marked as being an archive,
which means it won't be updated, are you sure you want to subscribe?"
message box. If the feed has a <link rel="current" /> with a @type you
know how to deal with, you can change the message box to add "however
the feed provides the location of a 'living feed', do you want to
subscribe to this one instead?".

So, what I'm saying is: I'm not willing to use media types to identify
relations (the fact that you can technically subscribe to a thing
depends on the format of that thing, whether you can parse it or not),
I'm willing NOT TO use relations to identify "groups of media types"
(the ones looking like feed: a container with metadata and contained
items with their own metadata).

Last, but not least, "alternate stylesheet" has a special meaning, and
using "alternate feed" in a different way is a bit confusing...

My main problem with autodiscovery is this use case: the following
links on an "entry page" in a blog-like scenario, where comments on
the entry are shown at the bottom of the page:
<link rel="alternate" type="application/atom+xml"
    title="A standalone Atom Entry alternate representation, might
even be updatable using HTTP PUT" />
<link rel="XXX" type="application/atom+xml"
    title="Comments on this entry" />
<link rel="YYY" type="application/atom+xml"
    title="Site-wide feed" />

1. the first one should not be seen as a "feed" link; I'm proposing
adding a type=entry parameter to the application/atom+xml media type
to help disambiguation; I'm also disagreeing here with the rule of the
WhatWG (rel="alternate" + "feed" media type => rel="feed alternate")

2. which values to give to XXX and YYY?
If XXX is 'alternate', then you need a type=feed parameter not to
confuse the two first links.
XXX and YYY should not be the same, the relations are not the same:
XXX is "contained" while YYY is a "container".
I'm proposing XXX=alternate and YYY=feed; along with adding a
type={feed,entry} to the application/atom+xml media type.

> content one is looking at,

You don't need a special format for that, you could just regularly
poll the resource with If-Modified-Since and If-None-Match.
A special format (which would just be an 'alternate', and nothing
more) helps present it in a unified way along different web sites.

> and something that is just an alternate representation of the content
> one is looking at expressed in application/atom+xml format.

That would be 'feed alternate'? If so, then your other case above does
not fall in the 'feed' case: from the WhatWG, "otherwise, the feed is
just a syndication feed, not necessarily
associated with a particular Web page": how can you describe a
relationship between to things (that's what is doing a link) and at
the same time say that the other end of the link is "not associated
with a particular Web page"?

> This would be the case for the front of my blog page.

rel=alternate is enough in this case.

-- 
Thomas Broyer

---

From: Henri Sivonen <[email-masked]>
Date: Fri, 24 Nov 2006 11:19:51 +0200

> even be updatable using HTTP PUT" />
...
> 1. the first one should not be seen as a "feed" link;

That ship sailed long ago. For backwards compatibility, UAs will  
treat links like the one quoted above as feed autodiscovery links-- 
not as standalone APP editing links. It is too late to apply elegance  
retroactively.

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

---

From: "Thomas Broyer" <[email-masked]>
Date: Fri, 24 Nov 2006 10:32:31 +0100

> not as standalone APP editing links. It is too late to apply elegance

…except if you update application/atom+xml to add a type=entry
parameter... in which case the existing code will probably won't
"find" the link...

In the absence of 'type' parameter, you have no mean to know whether
the Atom DOcument is a feed or entry, so you treat it as a "possible
feed", just in case. And you're backwards compatible.

-- 
Thomas Broyer

---

From: Henri Sivonen <[email-masked]>
Date: Fri, 24 Nov 2006 11:44:42 +0200

On Nov 23, 2006, at 22:42, Henry Story wrote:

> assignments/relation/,

How could new link relations be described in RDF to such a degree  
that the description would actually be useful for software processing  
but simple enough to actually be implemented? Is it realistic to have  
UAs whacking IANA server effectively performing a DDoS on it?

> as well as making the link relation very extensible (people who  
> want to try out new link relations, can just use their own,  
> unambiguous url).

How are full URIs distinguished from strings that need to be appended  
to "http://www.iana.org/assignments/relation/" to obtain the full  
URI? Are UAs supposed to look for a colon as with XForms input  
methods? Where is this specified?

In practice people seem to want to use one-word link relations even  
when they are coming up with their own.

> I would recommend you adopt that too. Perhaps you can even adopt  
> the iana name space. If we could get them to put the appropriate  
> rdf document at that location, people who created/coined new link  
> relations could describe these relations as being superproperties  
> or subroperties of relations the browser already knows, which would  

Well, RDF is not viewed that favorably by the WHATWG. Also, the  
barrier for entry for the IANA registration process is likely too  
high. (It certainly is for MIME types.) As for using the same  
namespace, the HTML5 definitions for the link types don't necessarily  
match the Atom definitions.

Recently, a WHATWG-managed registry for HTML5 rel values has been  
discussed informally. The idea was that conformance checkers could  
consult an online registry instead of only allowing a fixed list of  
values or allowing everything. RDF is an overkill for this. Even XMDP  
isn't the simplest thing that could possibly work. The simplest thing  
that could possibly work is a GETtable text/plain; charset=utf-8  
resource at a well-known URI with one rel value per LF-separated line.

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

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Fri, 24 Nov 2006 20:47:54 +0800

> Why?

Autodiscovery should be limited to <head>...</head>. If an author wants his feeds to be discovered automatically by UAs, he should use <link>. Providing additional or same feed links using <a> is only for linking and does not affect the autodiscovery. Scanning whole document is not necessary and increases the complexity.

Franklin Tse

-----Original Message-----
From: Lachlan Hunt [mailto:[email-masked]] 
Sent: Friday, November 24, 2006 15:45
To: Tse Shing Chi (Franklin/Whale)
Cc: 'atom-syntax'
Subject: Re: PaceResurrectAutodiscovery

Why?

-- 
Lachlan Hunt
http://lachy.id.au/

---

From: Lachlan Hunt <[email-masked]>
Date: Sun, 26 Nov 2006 01:24:28 +1100

Tse Shing Chi (Franklin/Whale) wrote:
> Autodiscovery should be limited to <head>...</head>. If an author 
> wants his feeds to be discovered automatically by UAs, he should use 
> <link>. Providing additional or same feed links using <a> is only for 
> linking and does not affect the autodiscovery. Scanning whole 
> document is not necessary and increases the complexity.

Ah, but this works!

<html>
<head>
  <title>Feed Autodiscovery</title>
</head>
<body>
   <p>... really long body ...</p>
   <link rel="alternate" type="application/atom+xml" href="/feed">
</body>
</html>

I tested that with both HTML and XHTML and both tests worked in Firefox, 
Opera and Safari. IE7 was the only broswer that appeared to do what you 
suggest, at least to some degree.  But given that IE7 is in the minority 
in this case, and doesn't handle link elements in the body like other 
browsers (the way it's being defined in HTML5), I consider that a bug in IE.

-- 
Lachlan Hunt
http://lachy.id.au/

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Sat, 25 Nov 2006 23:02:10 +0800

Your example is a invalid HTML document.

<link> can only be put inside <head>.

While you have mentioned HTML 5, you may take a look on XHTML 2. XHTML 2 allows all elements inside <body> to have a "href" attribute and thus they can be a link without using <a>. It is very complicated case for UAs to scan all.

IE 7 is actually doing a good job, it is rejecting all <link> elements which are put in a wrong position. I cannot understand why Firefox, Opera and Safari detect the links.

Franklin Tse

-----Original Message-----
From: Lachlan Hunt [mailto:[email-masked]] 
Sent: Saturday, November 25, 2006 22:24
To: Tse Shing Chi (Franklin/Whale)
Cc: 'atom-syntax'
Subject: Re: PaceResurrectAutodiscovery

Ah, but this works!

<html>
<head>

-- 
Lachlan Hunt
http://lachy.id.au/

---

From: Lachlan Hunt <[email-masked]>
Date: Sun, 26 Nov 2006 02:56:50 +1100

Tse Shing Chi (Franklin/Whale) wrote:
> Lachlan Hunt wrote:

That's not the point.  In the real world, authors make many stupid 
mistakes and elements appear all over the place, which browsers have to 
deal with.

> While you have mentioned HTML 5, you may take a look on XHTML 2. 
> XHTML 2 allows all elements inside <body> to have a "href" 
> attribute and thus they can be a link without using <a>. It is 
> very complicated case for UAs to scan all.

XHTML 2 effectively dead.  That href-on-any-element feature is one that 
browser vendors have already stated to be difficult to implement.  In 
fact, XHTML 2 as a whole is already near impossible to implement in the 
real world, and, if the WG goes through with their stated plan to reuse 
the XHTML 1.x namespace, it will be totally impossible to implement. 
Therefore, XHTML 2 is irrelevant to this discussion.

> IE 7 is actually doing a good job, it is rejecting all <link> elements 
> which are put in a wrong position.

No, IE's behaviour is extremely inconsistent and buggy.  This test 
actually works in IE.

<!DOCTYPE html>
<title>Autodiscovery</title>
<div>
   <link rel="alternate" type="application/atom+xml" 
href="http://lachy.id.au/log/feed">
   <p>This case still works in IE!
</div>

> I cannot understand why Firefox, Opera and Safari detect the links.

Because they have to deal with real world content.  For example, 
although this isn't a an autodiscovery link, see where Google have 
placed the prefetch link in this page.

http://www.google.com/search?q=Microsoft

<link rel="prefetch" href="http://www.microsoft.com/">

Because browsers have to handle all link elements the same way, 
regardless of their attributes, they also have to handle the equivalent 
for autodiscovery links.

-- 
Lachlan Hunt
http://lachy.id.au/

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Sun, 26 Nov 2006 00:12:01 +0800

No. Authors take the responsibility to correct the mistakes. Browsers should not help them to do so.

I would like to repeat once again: HTML 4.01, HTML 5, XHTML 1.0 and XHTML 1.1 allow <link> elements put inside the <head> section only.

Even though the behavior of Internet Explorer 7 is inconsistent, it can handle valid examples, it is the most important point.

I cannot imagine if <meta> and <title> are being used anywhere in a HTML document.

Franklin Tse

-----Original Message-----
From: Lachlan Hunt [mailto:[email-masked]] 
Sent: Saturday, November 25, 2006 23:57
To: Tse Shing Chi (Franklin/Whale)
Cc: 'atom-syntax'
Subject: Re: PaceResurrectAutodiscovery

<!DOCTYPE html>

-- 
Lachlan Hunt
http://lachy.id.au/

---

From: Lachlan Hunt <[email-masked]>
Date: Sun, 26 Nov 2006 03:38:11 +1100

> should not help them to do so.

Sorry, browsers have to deal with the infinite number of legacy 
documents that already make an infinite number of mistakes. 
Significantly changing that behaviour is just not possible.

However, this is getting way off topic for this list.  If you have an 
issue with the way HTML5 error handling is being defined, I suggest you 
raise the issue on the WHATWG mailing list.

> I cannot imagine if <meta> and <title> are being used anywhere in a

Here's one example.

http://au.lge.com/

Note the meta element that occurs within a <table>, of all places!

-- 
Lachlan Hunt
http://lachy.id.au/

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Sun, 26 Nov 2006 00:50:11 +0800

> Significantly changing that behaviour is just not possible.

The IE team is correcting this kind of mistakes: http://blogs.msdn.com/ie/archive/2005/08/29/457667.aspx.

It is possible that <link> and <meta> in places other than <head> may not get parsed in the future.

> http://au.lge.com/

Horrible! <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> inside a table. But... meta name="description" and meta name="keywords" are in a correct location.

Franklin Tse

-----Original Message-----
From: Lachlan Hunt [mailto:[email-masked]] 
Sent: Sunday, November 26, 2006 00:38
To: Tse Shing Chi (Franklin/Whale)
Cc: 'atom-syntax'
Subject: Re: PaceResurrectAutodiscovery

Here's one example.

http://au.lge.com/

-- 
Lachlan Hunt
http://lachy.id.au/

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Sun, 26 Nov 2006 01:03:22 +0800

== Correction ==

> The IE team is correcting this kind of mistakes: http://blogs.msdn.com/ie/archive/2005/08/29/457667.aspx.
 
It should be " The IE team is removing support to this kind of mistakes

Franklin Tse

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tse Shing Chi (Franklin/Whale)
Sent: Sunday, November 26, 2006 00:50
To: 'Lachlan Hunt'
Cc: 'atom-syntax'
Subject: RE: PaceResurrectAutodiscovery

Franklin Tse

-----Original Message-----
From: Lachlan Hunt [mailto:[email-masked]] 
Sent: Sunday, November 26, 2006 00:38
To: Tse Shing Chi (Franklin/Whale)
Cc: 'atom-syntax'
Subject: Re: PaceResurrectAutodiscovery

Here's one example.

http://au.lge.com/

-- 
Lachlan Hunt
http://lachy.id.au/

---

From: Henry Story <[email-masked]>
Date: Tue, 28 Nov 2006 11:05:41 -0800

On 24 Nov 2006, at 01:44, Henri Sivonen wrote:
> that the description would actually be useful for software  
> processing but simple enough to actually be implemented? Is it  
> realistic to have UAs whacking IANA server effectively performing a  
> DDoS on it?

Just some interesting uses of this beyond your question:

- The RDF file would serve as a useful machine readable description  
of the relation, and so serve as documentation.
- This would simply make those terms re-useable in other rdf  
vocabularies, which could be very useful. Do you have an RDF file  
that needs the notion of an alternate link? Well just use elements  
from that vocabulary.

But to get to your point:

The description on the server would probably not be very advanced. It  
would probably be very simple, like the Dublin Core vocabulary  
( http://dublincore.org/ ). And so you are right this would probably  
not say much more than that :alternate is a relation. Perhaps one  
could even specify the Domain and the Range of the relation to be  
documents.

Not much that one could automate. The default relations would rarely  
change, so User Agents would never query the server directly, and so  
you would not have a DDoS on them.

On the other hand, clients wanting to define new relations (as URLs)  
could place the definitions of these relations on their server, and  
say some more interesting things such as

<http://my.eg.com/rel#entry> rdfs:subPropertyOf <http://iana.org/ 
assignments/relation/alternate> .

The user agent would now know that this new entry relation is also an  
alternate relation. Perhaps this could save having to place both  
relations inside of every document.

> How are full URIs distinguished from strings that need to be  
> appended to "http://www.iana.org/assignments/relation/" to obtain  
> the full URI? Are UAs supposed to look for a colon as with XForms  
> input methods? Where is this specified?

This is specified in the atom syntax document.

[[

The value of "rel" MUST be a string that is non-empty and matches  
either the "isegment-nz-nc" or the "IRI" production in [RFC3987].  
Note that use of a relative reference other than a simple name is not  
allowed. If a name is given, implementations MUST consider the link  
relation type equivalent to the same name registered within the IANA  
Registry of Link Relations (Section 7), and thus to the IRI that  
would be obtained by appending the value of the rel attribute to the  
string "http://www.iana.org/assignments/relation/". The value of  
"rel" describes the meaning of the link, but does not impose any  
behavioral requirements on Atom Processors.

]] http://www.atompub.org/rfc4287.html#rfc.section.4.2.7.2

> when they are coming up with their own.

Yes. My guess is that this is because

1. They probably don't think of the issue of name clashes
2. There is no shorthand way of saying something like iana:alternate
3. There is no behavior associated with the name

If the relation pointed to a document that could have some behavioral  
impact on the browser with the user could adjust by doing something  
at the url of the relation, then there would be an immediate  
understanding of the value of using URIs.

>> or subroperties of relations the browser already knows, which  
>> would allow the browser to partially interpret those.
>
> namespace, the HTML5 definitions for the link types don't  
> necessarily match the Atom definitions.

I believe I have a good explanation for why people may have good  
reasons to dislike RDF/XML.
see: http://blogs.sun.com/bblfish/entry/crystalizing_rdf

> values or allowing everything. RDF is an overkill for this. Even  
> XMDP isn't the simplest thing that could possibly work. The  
> simplest thing that could possibly work is a GETtable text/plain;  
> charset=utf-8 resource at a well-known URI with one rel value per  
> LF-separated line.

Look at the Turtle notation for RDF. It is very simple to parse.
The advantage of using RDF is that it you don't have to re-invent a  
semantics. Even if simple it would be helpful to help people get  
familiar with the technology.

Henry