|
Atom 0.2 is out. Although not an official spec, it looks like it's now solid enough to comment for people who are, shall we say, wiki-shy. So here's mine.
Choice of Top-Level Element
Atom 0.2, unlike RSS 2.0, has <feed> as its top element. While this is fine if all you want to use Atom for is blog notifications, it's too restricting for future growth.
For example, it doesn't handle cases in which several feeds are held in a single container. (For example, one can think of an Atom replacement for the ugly and restrictive OPML format, in which you have a single XML tree that only holds feed elements, with no content.)
I think we need a top-level element that would hold the <feed> element, as well as any @version information we'd care to put.
The <link> Element
The spec mandates one <link> element per <feed> and <entry> elements. It says this about the element:
[T]he link to the website described by this feed
and:
[p]ermanent link to a representation of this entry
Here's what it doesn't say, but is implied: the definition of a <link> element in this manner means that it is useful mostly to humans. Of course, one may build tools that would make good use of this element, but in general, such links cannot be relied upon.
Why am I saying that? After all, this is what RSS 2.0 does today, so it is the proven way of doing things, right?
Well, I don't think so. Let's consider the use of the permalink in weblogs. Most weblogs today fall into one of two camps: "Take That" weblogs provide the entire content of each entry in the feed. "E.T. Phone Home" weblogs provide only a teaser, and readers who want to actually read the entry are forced to do so with their browsers.
Now, consumers who prefer the first type of weblogs (TTW) rarely click on the <link> element, bacause they have no reason to. There are some weblogs that I couldn't recognize on sight, simply because I read them entirely using Aggie, without ever navigating to the site itself. For them, the element is mostly useless.
Other consumers rather like that they get only a teaser, and they get to decide if they want to navigate to the site or not. They also like getting to the site, to see everything in original colors, etc. For them, the link is everything.
Note, however, that in both cases the element is not used by the aggregator itself. To the aggregator, there's little difference between the <link> element and the <tagline> element -- they're both for consumption by humans.
So what? I have no problems with having a <link> element. I do have a problem with (1) having this element mandatory, and (2) the apparent thinking this mechanism is enough.
Don't Make <link> Mandatory
<link> should not be mandatory. It assumes a web presence, which is not always there. Suppose your printer delivers "job-done" notifications back to use in an Atom feed. What should it put in the <link> element? The URL of HP?
<link-to-atom>
Why is today's <link> element not enough? Suppose a producer of the feed does not want to provide full content (for example, because it takes too much bandwidth) but he has some readers (me!) who would like information to come to them rather than the other way around. With Atom 0.2, one has to give.
IMHO, this is exactly the type of limitations Atom was born to solve. The solution would be to provide another type of link element, <link-to-atom>, whose contents is a URL to a resource in Atom format itself. When attached to a feed, it provides the URL to the feed in Atom format, thus making the feed declare where it is located. (This has the pleasing property of allowing aggregators to track changes in feed location naturally, and producers who can't generate redirect pages happier.) When attached to an entry, it provides the URL to the Atom representation of the entry itself, only this time with the whole contents.
(Bandwidth-aware producers might also note that such a mechanism reduces their bandwidth consumption even more, because clients don't need to download all the "fluff" that entries usually contain in their web page.)
<generator>
This is a cosmetic remark. If we want the <generator> element to provide both a URL and a display name, then the URL should be an attribute and the elements' content be the display name, not the other way around. This is how anchor elements work in HTML, and I see no reason not to keep this format.
<author/url>
There must be a good reason why this is called <url> and not <link>, but I just don't see it.
<entry/id>
Yes, YES, YES
I can't stress this enough: a mandatory <id> is the most important feature in Atom, and it alone is sufficient to justify the whole effort.
Here's a simple use model that is not currently supported: Suppose I write a short article about (say) Atom 0.2. I want people to read this article, so I post it on my weblog. I want more than two people to read it, so I also post it to the Atom mailing list, the Wiki, as a remark at Sam Ruby's weblog (I'm sure he won't mind), and any other place I can spam. Now how can someone who reads several of these "water fountain" sources tell that he's already seen the element? How can he comment and make sure the comment propagates everywhere the original went?
Today, we have poor connection between distribution channels: People who leave comments in other people's weblogs don't post them to their own weblogs. Remarks I make in a mailing list remain confined there, unless I repeat them on my weblogs, and there's no way a smart universal client could weave them all together.
<id> will allow us to change all that. Technically, it's as old as SMTP and NNTP, who put it to good use. As a concept, it's as old as Adam's naming all animals. 3000+ years later, we still use these names [*]
content/mode
If this attribute is optional, the spec should call out what the default mode is.
[*] If you speak Hebrew, that is.
|
![[Valid RSS]](images/valid-rss.png "Valid RSS"){kind=small}
