Mark has posted an excellent tutorial, How to make a linkblog in Atom. I find Mark's tutorials to be admirably well done. A couple comments follow.

As I mentioned recently, I think Atom is important because so much effort is going into designing its usage protocols. Mark's tutorial is a good example: it's basically a protocol-by-example, and I think it reveals a clearer design than what one gets out of the format itself.

Definitely look at Mark's linkblog itself too—note that this page is actually the Atom XML file with an XSL stylesheet. Nice example of how well that can work.

Here is the entry Mark describes in the tutorial. Note the cross-reference to a related link. Conceptually, this is very interesting. I wonder if the way its visually presented could be refined (in other words, something seems off about it to me, but I don't have a good suggestion, so maybe I'm wrong).

Structurally though, both the main link and the related link are both expressed through the same data structure, a <link rel="related" . . . > tag. This is concerning, as the structure doesn't reflect the two different meanings (i.e., primary citation vs. related / cross-reference citations) that Mark is using.

This makes me question the use of the link tag altogether in this context: why not just put the links and summary together in a content element? I guess the easy answer is that it's easier to parse a separate summary and separate links—and since one of the links is being used as a linkable title, this seems required.

But, in general, this suggests to me that a linkblog and a content blog are not really the same interaction protocol, since a link blog always links out rather than being a destination (e.g., of content), and a content blog can either link out, be a destination, or be both (though content blogs, practically as a standard, are represented in RSS/Atom as destinations, i.e., the "main link" title is a link to the content, and not a link out).

The mixing of these protocols is evident in RSS, where the meaning of a link element is not strict (and, which I found to be a totally disorienting experience when clicking those main links in RSS readers). And, given that history, it looks like Atom is making a good effort to clarify and account for both protocols.

But, if I ran the zoo, I'd just have two, slightly different, formats for link and content blog feeds. (And this would assume that people would have feed readers that could just deal with processing the different formats, without requiring users to know that they are different formats). In particular, do I want to "read" a linkblog the way I want to read a content blog? Probably not.

But, the formats are less important than the protocols. And, as I said, the effort going into describing these protocols for Atom is an indicator of why it's more important than just a format—and even why some of these format constraints aren't worth being too concerned about.