Subject: PaceDateUpdated, yes please

From: Tim Bray <[email-masked]>
Date: Mon, 30 Aug 2004 17:32:41 -0700

When I get off the airplane on which I'm writing all these emails I'm 
going to go sign up as a supporter of PaceDateUpdated.  I'm motivated 
both technically (it seems simple, useful, and consistent with prior 
art) and under my co-chair's hat, as I sense a chance to get this 
across the goal line and have at least one consensus date in Atom.

I personally hope to see at least one other date in the Atom core, but 
believe that approving this one is a necessary first step.

I think that anyone who objects to this one should speak up now.  I 
fervently hope that nobody does. -Tim

---

From: Eric Scheid <[email-masked]>
Date: Tue, 31 Aug 2004 13:35:35 +1000

> fervently hope that nobody does. -Tim

I object to some parts of PaceDateUpdated, but otherwise I'm +1.

I have a revised pace: stripped distraction of sorting, punted format rules
back to section 3.3 Date Constructs, doesn't explicitly replace
atom:modified, atom:issued, atom:created, stronger Rationale and rewritten
Abstract.

I'm mostly happy with this, except for the second sentence of the second
paragraph of the spec text... cleaner text could be written, surely.

http://www.intertwingly.net/wiki/pie/PaceDateUpdated2

------------------------

== Abstract ==

atom:updated is an objective machine readable date which can be used by an
author to signal that the changes they've made to an entry are significant.

== Status ==

Open

== Supporters ==

 * EricScheid
 * AsborjnUlsberg
 * ???

== Rationale ==

 * users want to be notified of significant updates to entries they have
previously read

 * users don't want to be bothered with every minor change that crosses the
wire

 * a simple modified date is too noisy, what with spelling errors and such.

 * while there are objections to duplicating dates from dcterms in the Atom
core, dcterms does not have anything that matches the semantics of
atom:updated.

== Proposal ==

Add a new sub-section to draft-ietf-atompub-format-01 in section 5
(atom:entry), near any other 'date' sections.

=== 5.x "atom:updated" Element ===

The "atom:updated" element is a Date Construct indicating the most recent
date and time when a change was made to the entry which the publisher wishes
to bring to the attention of subscribers. Such changes will typically not
include minor adjustments like spelling and grammatical corrections, content
reformatting, etc.

atom:entry elements MAY contain exactly one atom:updated element. If at some
point an atom:entry contained the atom:updated element, then all subsequent
instances of that atom:entry SHOULD also contain the atom:updated element
with the last value.

The content of this element MUST conform to the specifications of the Date
Construct defined in section 3.3.

Publishers MAY change the value of this element over time. The value of this
element SHOULD be the objective date of the actual update, and not a
subjective date related to the content.

== Impacts ==

* atom:updated is for the benefit of end users, while atom:modified is for
the benefit of the software in between (and users in absence of
atom:updated).

* it's optional, and it's absence is the same as if the publishing author
doesn't bother marking significant updates, and lack of support in
aggregator software is similarly non-fatal. It can be safely ignored,
although with loss of value/utility to the end-user.

== Notes ==

atom:updated is OPTIONAL, with the understanding that subsequent minor
modifications SHOULD carry forward the last atom:updated. That is SHOULD,
not MUST, because it's not a world-ending error and we need to allow for
situations where someone migrates from one CMS which supports atom:updated
to another CMS which doesn't. Also, rather difficult to test any given feed
instance for conformance to a MUST requirement.

Feed-reading software can use this date field to detect "significant"
changes and signal this to the end user (via flags, marked as unread, a sort
option, etc)

Format rules have been punted, leaving it to section 3.3 Date Constructs to
define. For simplicity's sake it is preferable that each specific date
element NOT have differing format rules.

----

CategoryProposals

---

From: Sam Ruby <[email-masked]>
Date: Tue, 31 Aug 2004 07:45:03 -0400

> http://www.intertwingly.net/wiki/pie/PaceDateUpdated2

I'm -1 on PaceDateUpdated2.  An optional updated element in the presence 
of a mandatory modified date will simply not get wide use.

By eliminating "Consumers MAY choose to sort based on this value. 
Consumers MAY choose not to display entries until the date specified in 
the atom:updated element.", you've opened the doors to significantly 
historical dates (e.g., Pepys' Diary[1]) and future dates.

- Sam Ruby

[1] http://www.pepysdiary.com/

---

From: Eric Scheid <[email-masked]>
Date: Tue, 31 Aug 2004 22:32:03 +1000

> of a mandatory modified date will simply not get wide use.

which is better:

(1) wide use of <updated> simply because it MUST be present,
    even if the modification isn't significant for a given entry

or

(2) <updated> only being deployed by publishers that facilitate the
    semantic of "major vs minor changes"

> historical dates (e.g., Pepys' Diary[1]) and future dates.

that's a good thing, right?

e.