Monday, May 23, 2005, 6:18:53 AM, Roger B wrote:
> I'm asking you specifically because you seem to be approaching your > argument in a reasonable tone and fashion. My apologies if I'm > pestering. No apologies required, I welcome any useful criticism. > Near as I can tell, folks have modification dates. In my case, that is > a date that is updated every time the user clicks "save". In Tim's > case, that is a date that he chooses. In other apps, that may be a > date that matches when a new comment was added to a blog entry. > Nothing in the spec is going to change these realities. > And none of these approaches are *wrong*, or invalid. We each get to > define "change" in our own apps, so we can approach atom:modified's > MUST clause as we see fit. For all practical purposes, it doesn't > matter whether folks use atom:updated or atom:modified. > You're going to get the same date. You may get the same date in some cases, but not all. explained below... > With that in mind, what are the actual benefits of atom:modified over > atom:updated? The end result will always be identical, unless I'm > missing a crucial, well-hidden point. When a publisher updates an existing entry, the value that they put in atom:updated combines three parameters: a) The last modified date of the entry (ie: the value that would go into atom:modified if it existed) b) The atom:updated value of the previous instance. c) Whether the publisher's opinion is that the change is significant. (some publishing systems may not allow the publisher to express this opinion - in that case, this parameter will be hard-coded) The publisher chooses whether the new atom:updated value should be the current modification date, or the previous atom:updated value based on whether, in their opinion the change is significant. If a publisher wants to change an entry, and wants to indicate that in their opinion the change was not significant, the current draft allows them to do this by publishing a new version of the entry with the same value of atom:updated as the previous version. The problem is, for a set of instances of an entry (ie where the entry was modified over time) atom:updated is the only way for a publisher to indicate the order of those instances. So these instances become second-class, in the sense that the publisher is prevented from communicating this information. Given multiple instances of an entry, one original, and one that has been corrected, it is impossible to tell which is which, so any processor has a 50% or greater chance of displaying the wrong version. Fortunately, under typical circumstances, a Feed Document doesn't contain more than one instance of the same entry, so you can work out the order of instances from two separate polls based on when you polled the feed. But under other circumstances this is important. An example - Atom is supposed to support archiving according to the charter, but it isn't possible to archive a feed, unless you don't mind either a) the order of instances of entries that appeared in your feed being lost (so that it is impossible for a reader to tell which of two instances is the later one that incorporates corrections); or b) the archiver stripping out older instances before putting them in the archive - but this means that you only have a partial archive of what was published in your feed. Note that without atom:modified an archiver could only support b) if it was tightly coupled with the publishing process because the current draft of Atom is incapable of representing the modified dates of entry instances necessary for the archiver to strip out the older instances. (see <http://www.imc.org/atom-syntax/mail-archive/msg15549.html> - for more discussion of this example) PubSub is another example of a system where this is a problem - it's probably best to read what Bob Wyman says about that though. The recommendation made by PaceAllowDuplicateIDs to use atom:updated to select the latest instance of an entry, is a completely inappropriate use of atom:updated given its semantics, but unfortunately it is the only course of action unless atom:modified (or something similar) is introduced. > Please note that it has not escaped me that this cuts both ways. Why > fight for atom:updated over atom:modified when it is beyond the scope > of the Atom spec to define the nature of change in the universe? Hey, > if Tim doesn't consider a typo a real modification, then it just > isn't. Period. It's his writing, his app, and he defines the rules and > the terms. It has been suggested that atom:modified is being proposed because the processor mistrusts the publisher, or the publisher's opinion, or because the processor doesn't find the opinion significant. This couldn't be further from the truth. Without atom:modified, the feature of atom:updated that allows a publisher to express their opinion on significance, is a false promise. If publishers don't update atom:updated, the entry becomes second-class. In effect, in your example, if Tim wants to use Atom in certain ways, he won't get the option to express whether his modification is significant or not because the meaning of atom:updated in the spec is distorted by the implications of PaceAllowDuplicateIDs. -- Dave