PaceDateKenMacLeod to be withdrawn

[Ken MacLeod <ken@xxxxxxxxxxxxxxxx>]

I've seen only one possible message in support of PaceDateKenMacLeod
(a date indicating last change of an entry) and several against, so
I'm moving to withdraw it.  However, I would like to resummarize the
use cases for the change date.  If anyone gets an, "oh, I didn't think
of that" positive reaction, then say so, otherwise there is no need to
reply.  Note the second use case has not been mentioned previously.

Use cases for atom:e:

  1) When compared to a stored value of atom:e from a previous read,
     indicates (by being "later") whether any additional processing
     needs to be performed (such as overwriting the stored
     representation of the entry or further processing to determine
     whether the entry should be passed on or displayed).

  2) If the same entry (same atom:id) is read from multiple sources
     (such as republishers) they may possibly differ, the value of
     atom:e indicates which is the latest.

  3) If the same entry (same atom:id) appears more than once in the
     same feed, the value of atom:e is one indicator that can be used
     to determine which to process (store, pass on, or
     display).  Another strong indicator would be xml:lang.

atom:e serves the same purpose as the HTTP header Last-Modified.  Best
practice would be for publishing systems to ensure that the
Last-Modified value of the entry on the server (any representation) is
the value represented in atom:e.


What happens in each case if atom:e is not adopted:

  1) Assuming the source is authoritive (the original source), each
     new read of an entry can be considered the "latest" and be
     overwritten.  Impact: minimal, unnecessary processing may occur.

  2) This behavior is undefined.  Impact: In the event that an entry
     differs between two or more sources (based on the time they
     retrieved the entry), there is then an equal or greater than 50%
     chance that silent data loss will occur.

  3) This behavior is undefined, particularly it is also not defined
     as invalid in Atom format-01.  Impact: Should this practice not
     be explicitly disallowed and a producer emits an entry more than
     once, there is then an equal to or greater than 50% chance that
     silent data loss will occur.  Empirically, the chances of silent
     data loss approaches certainty, as most publishers put "new"
     entries towards the beginning of feeds and most consumers process
     entries in feed order so that later entries would overwrite
     earlier ones.

  -- Ken