Subject: PaceDateUpdated posted

From: Antone Roundy <[email-masked]>
Date: Thu, 19 Aug 2004 11:11:31 -0600

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

Rationale

     * "Updated" is the most useful single date for enabling meaningful 
sort order. For those who wish to sort by "issued", they can get close 
enough by caching the first value they see in atom:updated, and sorting 
by the original value if atom:updated changes. Those who wish to sort 
by atom:updated can obviously do that too.
     * There are objections to duplicating dates from dcterms in the 
Atom core. dcterms does not have anything that matches atom:updated.

Proposal

Replace sections 5.6, 5.7 and 5.8 with the following:
5.6 "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.

atom:entry elements MUST contain exactly one atom:date element. The 
content of this element MUST conform to the Date and Time format 
defined in [WWW]RFC 3339.

Consumers MAY choose to sort based on this value. If the value of 
atom:updated for an atom:entry changes, consumers MAY choose to 
continue to sort based on the original value rather than the new value. 
If atom:updated specifies a future date, consumers MAY choose not to 
display entries until the date specified.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 20 Aug 2004 10:56:01 +1000

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

overall +1, with some caveats.

> "Updated" is the most useful single date for enabling meaningful
> sort order.

I don't care about "sort order". I do care about receiving data signalling
that an entry has has a major change according the the publisher. In other
words, don't get hung up with "sort order". It's a red herring.

> defined in [WWW]RFC 3339.

This first MUST requirement is too much since the entry may have never been
updated. I do agree though that once an entry has been updated, all
subsequent entries should have the latest updated value. If an publishing
implementation doesn't facilitate the concept of "updated" (vs modified), it
shouldn't be forced to fill this date field with junk values (some will
force 'modified' into it for every minor change, others will instead insert
the value of 'first published' into it for every subsequent version ... far
far better they simply omit the element completely).

> display entries until the date specified.

This whole "sorting" business is a red herring. My understanding of
'updated' is that it signals a major update, what the user-agent does with
that is an implementation detail.

e.

---

From: Antone Roundy <[email-masked]>
Date: Thu, 19 Aug 2004 19:32:19 -0600

> words, don't get hung up with "sort order". It's a red herring.
"One man's red herring..."  I could be wrong, but my impression has 
been that a lot of people ARE interested in using some date element for 
sorting--in fact that it's a primary use of dates.  Out of curiosity, 
other than signaling major changes, is there anything else you want to 
do with dates (possibly including other dates that "updated")?

> This first MUST requirement is too much
I made it a MUST on the assumption that we're only going to be able to 
get consensus on one objective date, and perhaps one subjective one.  
If we manage to get consensus on more than one, then we should discuss 
which to require, or whether to require at least one without specifying 
which.

> since the entry may have never been updated.
If we only get one date construct (and if this is it), then we'll have 
to use a slightly loose operational definition of "updated" which 
includes updating from non-existence to existence.  By that definition, 
creation == the first update.

> If an publishing
Unless we require nothing more than a subjective or very loosely 
objective date, some publishing implementations aren't going to be able 
to be precise[1], no matter what ends up in the spec.  The question is 
whether they'll be able to be sufficiently accurate[1] to meet the 
goals of date constructs, and how we should spec things to maximize 
accuracy.

> that is an implementation detail.
Based on suggestions from Sam, I've altered that paragraph so that it's 
more of a warning to producers than a suggestion for implementation 
details.

[1] http://www.imc.org/atom-syntax/mail-archive/msg08457.html

---

From: Eric Scheid <[email-masked]>
Date: Fri, 20 Aug 2004 13:18:02 +1000

On 20/8/04 11:32 AM, "Antone Roundy" <[email-masked]> wrote:

> "One man's red herring..."  I could be wrong, but my impression has been that
> a lot of people ARE interested in using some date element for sorting--in fact
> that it's a primary use of dates.  Out of curiosity, other than signaling
> major changes, is there anything else you want to do with dates (possibly
> including other dates that "updated")?

Well, it depends on whether we assume there are other date elements or not.

I would want to sort on publishing date or subjective content date (amongst
other things, like sort by category, author etc). Generally speaking, I
would sort on subjective content date, but this is with the assumed context
of seeing each feed in isolation from other feeds (thus Pepys' diary
wouldn't be shoved down below everything else).

e.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 19 Aug 2004 22:03:52 -0700

>Well, it depends on whether we assume there are other date elements or not.

Let's not assume that we know that. The WG has definitely not decided 
for "one date only", and has definitely not decided for "multiple 
dates".

For example, the two proposals so far (UpdatedAsChosenByThePoster and 
SubjectiveBasedOnContent) can exist together with no problem, or 
could each be the only date in an entry. Other combinations might not 
work together well.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Sam Ruby <[email-masked]>
Date: Fri, 20 Aug 2004 08:05:49 -0400

Paul Hoffman / IMC wrote:
> SubjectiveBasedOnContent) can exist together with no problem, or could 
> each be the only date in an entry. Other combinations might not work 
> together well.

Actually, there are three proposals so far, I posted PaceDateElement 
before either of those two were posted.  In fact, it doesn't make sense 
to combine it with either of those paces, as currently stated:

PaceDateElement and PaceDateUpdated are similar enough that I am willing 
to support either - as long as they are mutually exclusive.

PaceDateElement and PaceDatesubjective are conceptually compatible, but 
they chose the same name for the element name.

- Sam Ruby