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 element.

<link rel="related" type="text/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="" 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

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

5.4.1  rel

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.

The URI in the href attribute points to an alternate representation of the containing resource.
The Atom feed at the URI supplied in the href attribute contains the first feed in a linear sequence of entries.
The Atom feed at the URI supplied in the href attribute contains the next N entries in a linear sequence of entries.
The Atom feed at the URI supplied in the href attribute contains the previous N entries in a linear sequence of entries.
The URI given in the href attribute is used to edit a representation of the referred resource.
The URI in the href attribute is used to create new resources.
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.


Monday, May 31, 2004 7:32:40 PM (GMT Daylight Time, UTC+01:00)
It seems you're blowing this out of proportion a bit -- while it's true that Mark appears to be violating the letter of the spec, I don't think anyone's going to choke because someone's using a new value in an enumeration (that'd certainly be bad for forward compatibility!).
Monday, May 31, 2004 8:01:13 PM (GMT Daylight Time, UTC+01:00)
Given that I am the author of an Atom-enabled aggregator, how exactly am I supposed to determine what features to support? I had assumed the specs are the final word, but now it seems I was mistaken and blog postings/wiki/email threads are all as valid as well. The more I look at Atom, the more it feels like RSS is looking right back at me.
Monday, May 31, 2004 8:27:50 PM (GMT Daylight Time, UTC+01:00)
The two specifications are inconsistent. The format specification limits the acceptable values of @rel to those enumerated in the API specification. However, the API specification only refers to those values as "well-known", and implies that other values are acceptable, as in HTML.

The specs currently suck with regard to this issue. There are a number of proposals that address it. It'll get fixed.
Monday, May 31, 2004 10:26:00 PM (GMT Daylight Time, UTC+01:00)
Hmm, I wrote a feed for my linkblog using Mark's guidelines. Never working with RSS/Atom before it was kind of fun,quick & easy.

Anyway, I noticed that RSS Bandit ignores the links from the feeds written this way. How would you recommend to do the links themselves following his template? I'm not using the "via" tag...
Tuesday, June 1, 2004 12:43:48 AM (GMT Daylight Time, UTC+01:00)
Going back to RSS enclosures, a very good thing about the "via" rel is that it can be used to satisfy the netiquette of linking back to MP3 hosts.

(And ignoring the issue of usecases for enclosures).
Comments are closed.