Mark Pilgrim has a blog post entitled how to make a linkblog in Atom which shows one technique for syndicating a list of links in an Atom feed. Unfortunately there is one problem with Mark's article, the technique it recommends violates the ATOM 0.3 specification and generates an invalid feed.
There are two problem sections in Mark's article. In the first How to link to an article he writes
But what about the super-fascinating thing we're actually linking to? That goes in its own
<link rel="related" type="text/html"
href="http://home.introweb.nl/~dodger/itunesserver.html"
title="Setting up an iTunes server in FreeBSD"/>
and in the section entitled How to credit people whose links you republish he writes
Simply put, a "via" link is a link back to where you found the link you're posting. In this example, I discovered the article on setting up a FreeBSD iTunes server via Jeffrey Veen, so let's give him some credit:
<link rel="via" type="text/html" href="http://www.veen.com/jeff/archives/000545.html" title="Jeffrey Veen"/>
The problem with both sections is that Mark uses values for the rel attribute that are not considered valid by the Atom 0.3 specification. In Section 3.4.1 of the Atom specification it states
3.4 Link Constructs
A Link construct is an element that MUST NOT have any child content, and has the following attributes:
3.4.1 "rel" Attribute
The "rel" attribute indicates the type of relationship that the link represents. Link constructs MUST have a rel attribute, whose value MUST be a string, and MUST be one of the values enumerated in the Atom API specification http://bitworking.org/projects/atom/draft-gregorio-09.html.
On navigating to the provided URL and reading Section 5.4.1 of the Atom specification which defines the valid values of the rel attribute of the link element there is the following list
This attribute describes the relationship from the current document, be it HTML or Atom, to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types. Note that these values are case insensitive. With type="application/x.atom+xml" we have the following interpretations of the relations.
- alternate
- The URI in the href attribute points to an alternate representation of the containing resource.
- start
- The Atom feed at the URI supplied in the href attribute contains the first feed in a linear sequence of entries.
- next
- The Atom feed at the URI supplied in the href attribute contains the next N entries in a linear sequence of entries.
- prev
- The Atom feed at the URI supplied in the href attribute contains the previous N entries in a linear sequence of entries.
- service.edit
- The URI given in the href attribute is used to edit a representation of the referred resource.
- service.post
- The URI in the href attribute is used to create new resources.
- service.feed
- The URI given in the href attribute is a starting point for navigating content and services.
As can be seen neither related nor via which are used in Mark's article are in the above list. I had expected the Feed Validator written by Mark Pilgrim and Sam Ruby to flag this error but currently when one validates Mark's b-links feed it validates as Valid Atom. I have filed a filed bug# 963354 in the Feed Validator's Bug Database about this issue. Hopefully this error will be resolved soon.
On a final note, it is bad enough that we are going to have to deal with two versions of Atom in the wild (Atom 0.3 and whatever comes out of the standards process) it would be unfortunate to further fragment this by deploying intermediate versions of the format based on mailing list discussions. One of the benefits of Atom is supposed to be that it will usher in an era of rigorously defined specifications in the syndication space, that won't be worth much if people ignore the specifications and go their own way.