Henri Sivonen wrote:
On May 4, 2005, at 09:16, Mark Pilgrim wrote:
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.
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.
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 typesBlogging 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
