Subject: Next step on Dates

From: Tim Bray <[email-masked]>
Date: Wed, 18 Aug 2004 15:07:54 -0700

OK, it's time for us to try to push the the infamous "dates" issue 
along one more step.  Frankly, I would never have predicted how hard 
this was going to be.

Here's what I think we learned as a result of the last go-around:

1. There is consensus behind at least one date in atom:entry.
2. There is support for a variety of combinations of dates, but with 
distressingly little consensus on the combinations or the semantics of 
the individual dates.
3. There are more problems than we'd appreciated in calling out to the 
Dublin Core dates.

The problem is that the lack of consensus puts us at risk of getting 
*no* dates in Atom.  Which I think we can agree would be a mistake.  So 
I think our next step is to try to push one or maybe more date elements 
across the goal line, where the goal line for some date proposal is 
defined as a significant number of people speaking up to say they want 
it in Atom and a relatively small number of people saying they'd rather 
not have it, and ideally almost nobody saying it's disastrous and they 
can't live with it.  I'm sorry, this definition of consensus is "rough" 
indeed, but I suspect it's the best we're going to get on this topic (I 
believe most other issues will be less work).

So, concretely, here are the steps:

1. All the current Date* paces are closed.  They were useful, and 
thanks to those who wrote them.
2. We encourage the submission of a new round of Paces, each proposing 
a single date for acceptance in Atom.  The date should have a name, 
i.e. not "a", "b", "c".  The name of the Pace is not significant, so 
try to avoid anything controversial or semantically loaded.  No 
suggestion will be taken seriously unless it contains expressions of 
support from at least three people who have been active on the list - 
this is to prevent us from wasting time on suggestions that have little 
chance of achieving consensus.  Please only solicit support for your 
proposals in private correspondence.
3. Repeat:  Each Pace can only propose *one* date.
4. When we get the next round of single-date Paces, we'll give each one 
a chance to get over the goal line as defined above.

This is going to work best if we can consider the proposals 
independently, i.e. they preclude each other as little as possible.

The issue of whether we make any mention of the dc: dates will be 
treated for the moment as orthogonal and we'll take it up later.

Let's get the new round of Paces in by the end of Monday the 23rd, and 
see if we can put this to bed next week.

Yes, this is all feels like more work than it ought to be, but we've 
gotta get through this one way or another. -Tim

---

From: Antone Roundy <[email-masked]>
Date: Wed, 18 Aug 2004 17:10:29 -0600

I've been a little surprised at the near total lack of response to 
Sam's "Accuracy and Precision in dates"[1], so I'll bring it up again.  
Here's the executive summary of my response[2]:

Questions:
1) What are we trying to accomplish with dates in Atom?
2) What Date Construct definition(s) would maximize our ability to 
accomplish that?

Possible answers:
To #1:
A) Enable a desirable sort order
B) Provide a meaningful display date

To #2:
The following 2:
I) "Updated"--the objective date of the most recent modification which 
the publisher subjectively decided was significant enough to highlight.
II) A subjective "display" date.

FAQ:
i) "What if I want to sort by 'Issued'?"
You can get close enough (see Sam's email[1]) by caching "Updated" the 
first time you see an entry, and continue to sort by that value even if 
the publisher modifies "Updated".

ii) "What if I don't want to change the date in my feed, even if I make 
a huge modification?"
Fine.  Don't change it.  You've subjectively decided not to highlight 
the change, so the unchanged date fits the specification.

Antone

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

=======================================

P.S. If this all sounds reasonable to you, see 
PaceDateAntoneRoundy2[3], which never seems to have made it on to the 
issues list, and the announcement of which, in another surprise to me, 
garnered a similar amount of discussion as "Accuracy and Precision in 
dates".  The following is an except from a response I sent to an 
offline message about this proposal:

> I think there are a number of different axes along which people are 
> divided.  I think the proposal deals with a lot of the conflicts in a 
> way that I HOPE will make it possible to build consensus:
>
> * In the core vs. by reference: we define something in the core which 
> should cover most uses, but welcome people to use extensions to do 
> other things if they want to (which they always were welcome to do).
>
> * Duplication in the core of the things we think are most important 
> from dcterms vs. no duplication: no duplication, but a clear pointer 
> toward where to find the things that have already been defined in 
> dcterms if you need them.
>
> * Consumers HAVE TO be able to deal with a lot of dates, any of which 
> may or may not be present vs. keep the requirements simple: Keeps the 
> requirements simple, but points the way clearly for people who want to 
> do more complex things.
>
> * Have a clear way to specify a variety of time stamps vs. just bail 
> and stick with something not much better than RSS because it's too 
> hard to find consensus: bail on building the specific stuff into the 
> core, but provide a clear pointer for how to specify that stuff if you 
> want to.

[3] http://www.intertwingly.net/wiki/pie/PaceDateAntoneRoundy2

---

From: Sam Ruby <[email-masked]>
Date: Wed, 18 Aug 2004 19:50:32 -0400

Antone Roundy wrote:
> 
> I've been a little surprised at the near total lack of response to Sam's 
> "Accuracy and Precision in dates"[1], so I'll bring it up again.  Here's 
> the executive summary of my response[2]:
> 
> Questions:

Something to think about: typically one provides a means to display the 
date upon which you sort.

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

- Sam Ruby

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 19 Aug 2004 20:25:33 +0200

On Wed, 18 Aug 2004 15:07:54 -0700, Tim Bray <[email-masked]> wrote:

> 2. We encourage the submission of a new round of Paces, each proposing a  
> single date for acceptance in Atom.

How is possible to define relationships between dates, then? I, and some  
others, find it useful to only require _one_ date in atom:entry, but which  
date element publishers chooses to put in their feeds is up to them.

It is also desirable to gently force publishers to stop producing  
ambiguous dates, and start sharing semantics. Without any relationships  
between the dates, this is difficult to get into the specification. What  
would happen if only two out of four date paces are accepted, for instance?

It's good that we're taking a step forward, but I'm not sure that focusing  
on one date at a time is a good idea in the end, especially not if the  
goal is to reach consensus on whether to include them or not during this  
period.

It would be better to say that we're first only trying to get consensus on  
what the dates mean, and when we have a set of date elements we agree on,  
one could start creating paces that included the date elements and their  
relationship with each other.

Just my two cents.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Tim Bray <[email-masked]>
Date: Thu, 19 Aug 2004 11:27:31 -0700

On Aug 19, 2004, at 11:25 AM, Asbjørn Ulsberg wrote:

> It's good that we're taking a step forward, but I'm not sure that 
> focusing on one date at a time is a good idea in the end, especially 
> not if the goal is to reach consensus on whether to include them or 
> not during this period.

I'm quite sure that the path we were on was not moving to consensus on 
a selection of dates.  Right now, the one-at-a-time approach seems like 
the best bet for making progress on this issue.  Let's see how it goes. 
  -Tim

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 19 Aug 2004 20:33:54 +0200

On Thu, 19 Aug 2004 11:27:31 -0700, Tim Bray <[email-masked]> wrote:

> I'm quite sure that the path we were on was not moving to consensus on a  
> selection of dates.  Right now, the one-at-a-time approach seems like  

I agree that one-at-a-time is a good idea, but I'm not sure that  
discussing their semantics, behaviour, syntax, whether they should be in  
the core, and whether they should be a part of Atom or not all at once, is  
a good idea.

Seeing how difficult it is to even agree on what the different dates are  
and mean, we need to take as small steps as possible. The suggested step  
is imho a little too big. E.g., let's not choose whether any date elements  
should be a part of Atom yet. Let's just focus on what dates we need in  
Atom, and what they mean. Then, we can move on to including them in the  
core, in whatever way we'd like.

---

From: Tim Bray <[email-masked]>
Date: Thu, 19 Aug 2004 11:36:02 -0700

On Aug 19, 2004, at 11:33 AM, Asbjørn Ulsberg wrote:

>  Let's just focus on what dates we need in Atom, and what they mean.

No.  We tried that and failed resoundingly.  Asbjørn, please work with 
us on this one and see if we can make some progress. -Tim