On Nov 8, 2005, at 12:28 AM, David Powell wrote:
I think actual modified dates are a more useful sort key for the
protocol than the partially subjective atom:updated. The only drawback
I can see is that it adds some burden for implementors who don't
require it (although to support conditional GET, the servers must
retain the actual modified date anyway).
It seems kind of wasteful for us to have the atom:updated argument
over again, but that seems to be what's required. The reason we have
atom:updated, not atom:modified, is as follows:
1. Either you trust the party on the other end of the protocol or not.
2. If you trust the party, then you are probably prepared to agree
that an update that party doesn't think is significant, is
insignificant.
3. If you don't trust the party, then you know perfectly well that
they might lie about atom:modified, so you'll fetch the data and
check for changes anyhow.
4. If you have an atom:modified that is required to be updated on
every change no matter how insignificant, you have opened the doors
to endless arguments as to what constitutes a change: adjusting white
space between attribute values? Changing the stylesheet? Either you
trust the publisher's judgment or you don't.
Thus, trying to write a dependency on a date-you-trust-a-publisher-to-
provide-even-if-the-publisher-thinks-it's-not-significant into the
protocol is a waste of time.
-Tim
