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
