W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2006

[whatwg] Inferring rel="feed" from the media type

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 29 Nov 2006 17:59:57 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0611291755560.8094@dhalsim.dreamhost.com>
On Wed, 29 Nov 2006, Mark Baker wrote:
> HTML 5 says;
> "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://www.whatwg.org/specs/web-apps/current-work/#link-type
> I believe this in error.

It is intentional, as a way of grandfathering widespread legacy practice.

I agree that it is suboptimal. I'm not sure how to cater to both the 
existing content and, moving forward, to allow Atom to be used with 
rel=alternate to mean "alternate representation that isn't a feed".

> But it isn't a feed, and it isn't something you'd want syndication tools 
> to auto-discover as a feed, since that will just confuse users.

Putting a real feed first would get around this, but you're right that in 
the case you described (and assuming no feed), there'd not really be a way 
to get around this other than simply not including the type="" attribute.

> In addition, the media type on link is non-authoritative, meaning that 
> feed-semantics would be inferred before it was even ascertained that the 
> would-be representation was actually an Atom or RSS document.

Yeah. I think the spec is clear that the real MIME type overrides it once 
the file has been fetched; but again, existing practice constrains what we 
can do here.

In conclusion, I'm not sure we can do anything here. We're stuck between a 
rock and a hard place, as it were.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 29 November 2006 09:59:57 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:50 UTC