There are reasons for why atom:updated is specified the way it is.

Atom 0.3 had a mandatory modified element that tracked the time when the entry was last touched in any way. But the publishing system people on the WG fought tooth and nail against having to track the time when the entry was last touched. In fact, because consensus was that some date information would be mandatory, the publishing people fought against having to make any particular promises about how they come up with the date. So the spec had to avoid imposing any particular implementation.

In the course of this discussion it was also agreed that there’s something much more useful that publishing systems could tell consumers. After all, no one wants to re-read an entry just because the author fixed a typo. But if the author has made an update that adds important information, or he noticed he was wrong about something and struck out that text while adding a new explanation, or such, then that constitutes an update that subscribers probably want to know about. A publishing system that generates Atom should give the user an “Is this a significant update?” check box, and should change atom:updated only when the user thereby requests it.

So that’s how atom:updated ended up being the last significant update, but only fuzzily specified.

On the other end of the wire, changes to the entry text that do not coincide with changes to atom:updated should be ignored by feed readers, but changes that do coincide should be brought to the user’s attention. (If the entry text does not change, atom:updated changes should be ignored.) That’s the idea, anyway. I doubt it’s going to work out that way on the open web, unfortunately. But Atom gives you the tools to provide this useful feature, and in closed systems it will probably get used.

Maybe one day there will be an annotated version of the Atom (and Atompub) spec(s), detailing the reasoning that led to specific things being done the way we did them. There are quite a few cases that may seem strange or wrong if you don’t know what we were thinking, even though there was a solid reason for most of them. (But not for some, which were – as we have since realised – honest mistakes.) Maybe.

—Aristotle Pagaltzis

I think that atom:updated has the right definition; any tighter specification would force a certain way of implementing syndication feed generators, or at least make certain approaches much harder. Having a loose specification also makes sure that feed consumers know not to put too much weight on it, which is important because various implementations will get it wrong no matter what the specification is (partly because incorrect handling of atom:updated doesn't break feeds and thus people will miss it).

I don't understand why feed readers should ignore text changes if there's no change to atom:updated. No matter what, the text is no longer the same as what the user has read, and that seems worth noting in some way (possibly less prominently than if both the text and the update time change).

The idea is that text changes without a corresponding atom:updated bump supposedly are typo fixes or other suchlike minor edits. Certainly the reader should update its copy of the entry text when it sees a change, and it might even flag entries with minor edits somehow. But it should not mark the entry as unread again or otherwise intrusively alert the user to the change, because presumably it’s a small one that doesn’t affect meaning.

Of course, the situation right now is that readers never mark a read entry as unread again. Since no minor/major edit distinction exists in most formats (indeed most of them do not even admit that an entry might change over time, as Atom does with the atom:published/atom:updated dichotomy), and the overwhelming majority of edits is minor, being silent about updates (and occasionally missing a major one) is a much better strategy than highlighting them all (and flooding the user with alerts for trivialities).

—Aristotle Pagaltzis