I'm now generating an Atom feed for every entry on this site. To access the feed for a particular entry simply add .atom to the end of its archive URL. For example, this entry's Atom feed can be found at /2004/06/modified.atom Comments are included in the feeds of those entries that have them.
Supporting Atom should be easy. And it is, mostly. But I did run into some problems supporting feed-level modified. This element is required in Atom 0.3, but even the format's most high-profile supporters disagree on its use. I suspect most of the confusion is a result of poor tool support. Look at how WordPress, Movable Type, and Textpattern arrive at a modification date:
WordPress (wp-atom.php)
<modified><?php echo mysql2date('Y-m-d\TH:i:s\Z', get_lastpostmodified('GMT')); ?></modified>
Movable Type (Atom Index Template)
<modified><MTEntries lastn="1"><$MTEntryModifiedDate utc="1" format="%Y-%m-%dT%H:%M:%SZ"$></MTEntries></modified>
Textpattern (atom.php)
tag(date("Y-m-d\TH:i:s\Z",$last),'modified');
They're grabbing the most recent entry and hoping its modification date happens to be the date of the last updated entry in the entire feed. They'll be right most of the time, I guess. Most of the time. Isn't that the kind of ambiguity Atom is supposed to suppress?
These tools are getting it wrong because it's not as easy as you think to arrive at a feed-level modification date. Here are a few things you can't do:
At the very least, the spec should be written more clearly, in terms authors of publishing tools -- programmers -- can understand. If tools should use the modification date of the most recently modified entry, then the spec should say that. Specifications should be written such that people who think programmatically can translate the words into an algorithm. This a great example of how spec text is confusing, even when you're asking for something that seems simple, like the date of the most recent modification.
But making the spec more clear, while still a good idea, will make no difference if publishing tools can't natively produce the required information. If aggregators absolutely must know when a feed was last modified, let them figure it out -- based, presumably, on entry-level dates -- on their own. It's clear publishing tools will resort to including whatever is easiest for them to generate, anyway, even if it's the wrong date.
Why does this matter so much? It wouldn't if atom:modified weren't required. Is there a compelling reason this element isn't optional?
Clamoring for a Gmail invite? I've got two. I'll give one each to the first two people who comment on this entry. Be sure to leave your email address; it won't be displayed. Consider it thanks for reading.
Update: Read this comment for information on getting a Gmail invitation.
Brian Garside's message to those who would point out validation errors by e-mail -- don't do it! -- has generated a lot of back-and-forth at Dave Shea's mezzoblue. For the record, I want you to point out my validation errors. I can't catch everything and I appreciate those who care enough to take the time.
Unfortunately, the resulting discussion has led Keith Robinson to "retire" as a standards advocate, citing frustration with those of us who demand 100% standards compliance from our standards-gurus. Keith has felt this way for a while, as evidenced by his much-linked rant from last year. I didn't get it then, and I don't get it now. Jacques Distler on the importance of validation:
Not [the point] of the the Web (nor of the internet, nor of life), but it is *surely* the point of Web Standards. I am *baffled* that anyone can *advocate Web Standards* and simultaneously hold that validation doesn't matter. Maybe you mean something different by the term *Standards.*
You can't support standards without, well, supporting standards! What's so frustrating about Keith's stance is that it gives designers with less experience an excuse to ignore difficult errors, all while patting themselves on the back for making an attempt. You can't, by definition, support standards without adhering to the rules outlined in the standards. By definition.
I like Keith and read his site regularly. He says a lot of smart things about the Web every week, but his retirement from standards happened a long time ago, the day he decided to support only parts of standards and not others.
Yes, folks, there are other things to worry about. This Web thing isn't easy. But standards are a baseline. They make things easier, not harder. That's the message.
I've been blogging for one year. When I wrote the first entry to this weblog I was in a wheelchair, having just returned home from the hospital after breaking both legs and my back's third lumbar vertebra in a car accident. I'm doing much better, close even, after what likely will have been a final leg surgery a few weeks ago, to a full recovery.
The accident was the impetus to return to school, start this weblog, and generally quit fucking around. I'm having a lot of fun writing here, and it's still exciting to hear from readers. It's been a long year, but this weblog has helped make it a good one.
So, thanks to all who've visited in the last year. Come back soon.
The news this morning, as reported by both sides of the larger syndication debate, is that the W3C's Atom pitch seems to have done little to abate the format's IETF inertia (Dave Winer's take; Sam Ruby's take). Matt May explains why he thinks the W3C is the appropriate home for Atom:
A W3C Recommendation comes with a test suite, which is hugely beneficial on specs that require a great deal of interop. It comes with proof of interoperable implementations, developer testimonials, and publicity. Not bad for free.
I'll let those familiar with each organization discuss the internal differences between the two groups. But while everyone close to the format contemplates completion schedules and decision-making guidelines -- important matters, to be sure -- I'm wondering which body will accelerate adoption of the format. To the average developer the W3C means Web standards. XHTML, CSS, and even XML, of which Atom is a vocabulary, are each W3C standards. The obvious consequence of hosting multiple successful, pervasive formats is that the W3C has become the Web's de facto standards body (second only to the WaSP in a Google search for "web standards").
Most developers are familiar with both the style and format of W3C documentation and with the validators that support it. Content producers, especially the newcomers who are summarily directed to a W3C validator the first time they ask for help with CSS, will be more likely to find and support Atom if it's in turn supported by the same group that brought them every other standard with which they're familiar.
Everything I create on the Web for the foreseeable future will be marked-up with XHTML, styled with CSS, and syndicated with Atom. It would be nice -- not necessary, but nice -- to find all three formats in the same place.