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?
Actually, MT doesn't save unmodified files (well, it doesn't if your server has the Digest::MD5 module installed, anyway). That doesn't help it much, though: it would need to build an Atom feed template, see whether or not it would save it, and if it would then build it again with the current date-time as feed/modified. That's ugly.
What you really want is whatever's latest of the template modification datestamp or the most recently modified entry, but MT isn't going to be doing that, because it doesn't actually track template modifications (though it tracks the mtime of the linked file, if you save your templates both in the database and as a separate file that you might edit outside MT - that might work for a hack, though not for a standard feature).
Thanks, Phil. That's helpful.
You're right. To support
atom:modifiedtools must track template modifications; it's the only way to account for feed-level changes, including, as Eric pointed out, the removal of entire entries.My tool doesn't track template changes, either. At least I'm in good company.