The problem is simple. Most people are using the REL attribute with the value ALTERNATE to let people find their feed. An example for those who are clueless:
<link rel="alternate" href="/weblog.atom" type="application/atom+xml">
Pretty simple, not? People include this line on every page their weblog is running, also the archived entries so people who are visiting the site through a so-called “deeplink” can easily subscribe. We call that usability. Taking steps away to make it easier for the user is always a good thing. On this weblog, however, I only link to the feed from the frontpage, the feed for HREF is linked from the HREF page and, how unexpected, the feed for the comments is linked from the comments page. When I implemented it like that some time ago I did it to comply with the semantics of the ALTERNATE value of the REL attribute. When I would point to my main feed (containing the last several items) from some random archived page I would abuse its semantics and instead use it for something that should probably be solved differently.
Since eventually you might find yourself in a situation that you actually want alternative versions of your write-ups stored in Atom feeds. I think we need something like rel="feed" or rel="main-feed". Or perhaps I should just not botter and get on with it.
I agree. I too removed the Atom and RSS links from the archive pages (years, months, days, and entries), because my index.atom is an alternate version of /weblog/index.php, and that page alone.
I am, however, considering giving these archive pages (or at least the entry ones) an actual Atom equivalent, so that you can subscribe to a specific entry.
By the way, I think it’d make perfect sense to put something like <link href="/index.atom" rel="Start" type="application/atom+xml" /> on the archive pages. After all, you’re pointing to the start of the weblog: it just happens to be in a somewhat less conventional format (but that’s where the type comes into play).
I see how
would make sense, too.
main-feed
O great. Perhaps alternate start, just like we have alternate stylesheet now? Nice thought.
But then, what's next? alternate next? (sorry, bad joke) Well, why not. :)
I think "alternate" is an awful choice. I have feeds that are not alternate to anything, and I have feeds that have a well defined relationship which is mutually incompatible with alternate.
rel="feed" plus any other applicable relationship is a much better choice. I want to be able to put rel="help feed" or rel="index feed" in my markup
Besides: I'd also like to see the type attribute requirement go. It's redundant. We have content-negotiation for such stuff.
start would be the very first archive page (or the first of the year or month). top is the home page.
rel="contents" or rel="ToC" with the appropriate type attribute would probably work better from a semantic PoV.
That would be the best thing to do in your case, Arve (and for some of my sites too, actually). However, in the case of my weblog, the main Atom feed is exactly the same as the main index, other than it using a different taste
of xml (or so it should be: it requires some more hacking since the re-install of my cms).
The conclusion is clear: if your Atom file is an alternative to something, use alternate; if it's not, don’t (and find a label that describes it’s relation to the refering file properly).
I also agree about the type attribute … or so I would, in an ideal world. I already dropped many of them on my personal site: some, I just don’t need (like text/css), and others because it actually adds functionality (for instance; modern browsers get png or svg where others get gif, jpg, or ico). However, I’ve experienced best results with existing media when I keep the Atom and RSS ones. (I expect this to chance soon, though.)
The Atom Autodiscovery RFC is intentionally vague on this point. It simply states that "the purpose of Atom autodiscovery is for clients who know the URI of a web page to find the location of the page's associated Atom feed." The spec does not define the exact nature of this association. If you would like to point to the same feed from every page on your site, that would violate neither the letter nor the spirit of the spec.
Somewhat agree. rel="alternate" is not always proper value. One of the reasons is that the page doesn't have the same number of items as the feed has (typically, 15 items). If the numbers are different, the feed is not exactly an "alternate" of the page.
I would like rel="alternate latest" or rel="alternate latest index", using values already introduced in the W3C spec.
The Atom Autodiscovery spec says that the rel attribute MUST contain the value "alternate" for it to be interpreted as providing a link to the feed.
Thus, while an archive page with @rel="alternate" would not violate the Atom Autodiscovery spec, it does violate a reasonable definition of what "alternate" means.
Also, according to the spec, a link element with rel="feed" (and only "feed") would not be seen as an autodiscovery link. This is a pity.
Indeed, I completely agree that alternate is the wrong choice. I also think rel="feed" is the way to go and I included it within my Web Communication Link Relationships proposal that I wrote a while back.
Also, in order to differentiate between the main blog feed and other available feeds, it could be used in conjunction with alternate. So, for example, you could use rel="feed" for your weblog feed and rel="alternate feed" for your href feed. Though perhaps that too, is pushing the definition of alternate, since the two feeds aren't alternate representations of each other.
Besides: I'd also like to see the type attribute requirement go. It's redundant. We have content-negotiation for such stuff.
Content negotiation is nice when it works, but unfortunately the HTML 4.01 type attribute was not well designed, since it only accepts one value, unlike that proposed for XHTML2. It would be nice to be able to do this (this will be possible in XHTML 2)
<link rel="feed" type="application/atom+xml,application/rss+xml,application/rdf+xml,application/xml" href="/feed">
However, it is currently possible to do the equivalent with multiple link elements:
<link rel="feed" type="application/atom+xml" href="/feed"> <link rel="feed" type="application/rss+xml" href="/feed"> <link rel="feed" type="application/rdf+xml" href="/feed"> <link rel="feed" type="application/xml" href="/feed">
Although, It is unfortunate that very few, if any, feed readers actually send proper accept headers, so the above probably wouldn't do any good anyway.