Subject: Re: PaceDates

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 30 Jul 2004 08:29:00 +0200

On Fri, 30 Jul 2004 11:48:48 +1000, Eric Scheid  
<[email-masked]> wrote:

> disagree there is consensus ... the question of future dates being an  
> issue hasn't been discussed at all, or only in passing.

It has been discussed in #atom, and the ones discussing it seemed to agree  
that future dates were more of a bug than a feature. At least for the more  
formal dates of 'issued', 'modified' and 'created'.

> those feeds are better dated using the (so called deprecated) 'date'
> element, not the 'issued' element. A weather feed in particular should  
> have the date the information was released in the 'issued' date, just
> so readers can know that it's 48 hours old and thus unreliable.

Not so sure about that. What makes the weather report an un-issuable item?  
Why can't 'issued' be set to when the report is published to the web?

>> The point of the text is that you shouldn't put something out on the web
>> if it's not meant to be out on the web yet
>
> some may use it as a soft embargo date, meaning its not actually official
> until that date arrives. if you happen to see it before that date then  
> you are getting a 'sneak preview'.

Where is this semantic explained? Who is supposed to understand this? No  
aggregator can, at least.

> One of my client sites has several thousand pages, which they publish by
> baking them to static files. A complete site reload takes several hours.
> They'd like to put an issued date on their press releases. They don't  
> know if the press release would be at the beginning of the reload  
> process,
> or towards the end. Thus they'll start the reload at midnight, it'll
> finish about 6am, and the press release is officially issued at 8am (not
> 6pm the prior night).

So because the publishing process takes so long time, the 'issued' is set  
in the future? Well, that's okay if you have a fairly accurate feeling  
about when the entries will become available. Remember that the  
specification says «SHOULD NOT», not «MUST NOT» («MAY» for atom:date now,  
btw). So future dates are allowed, but shouldn't be encouraged.

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

---

From: Eric Scheid <[email-masked]>
Date: Fri, 30 Jul 2004 17:00:14 +1000

> Why can't 'issued' be set to when the report is published to the web?

that's what I said, isn't it? I'm saying the weather report, as issued by
the BoM this afternoon, for this coming Sunday should have:

    <issued>2004-07-30T16:00+10:00</issued>
    <date>2004-08-01T00:00+10:00</date>

e.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 30 Jul 2004 20:12:51 +0200

On Fri, 30 Jul 2004 17:00:14 +1000, Eric Scheid  
<[email-masked]> wrote:

> that's what I said, isn't it?

Yes. ;-)

> I'm saying the weather report, as issued by the BoM this afternoon, for
> this coming Sunday should have:
>

+1.

---

From: Ken MacLeod <[email-masked]>
Date: 30 Jul 2004 13:48:08 -0500

Asbjørn Ulsberg <[email-masked]> writes:

> > disagree there is consensus ... the question of future dates being
> > an  issue hasn't been discussed at all, or only in passing.
> 
> It has been discussed in #atom, and the ones discussing it seemed to
> agree that future dates were more of a bug than a feature. At least
> for the more formal dates of 'issued', 'modified' and 'created'.

Gah.  "At least for the more formal dates of 'issued', 'modified' and
'created'."  There's no concensus on the meaning of those terms, and
you didn't specify the Dublin Core definitions, therefore those terms
are meaningless, and therefore we couldn't have agreed about anything
on them.

Pedantic, yes, but absolutely critical in this conversation.

"Future dates" are a *current practice*, regardless of the field, or
the name of the field, we choose to put it in.  And surprisingly
enough, depending on concensus, it could go into a field with one of
those names when used in certain roles.  And we came to local
agreement on that in #atom too.

If people continue to bandy about the "labels" or "terms" that no one
agrees has the same definition anyway, we will continue to have this
problem.

I believe we would be much better off using the long descriptions of
fields, like "the date which the aggregator primarily displays to the
user", than using these damnable terms which everyone thinks mean
something, different than what the next person thinks.

  -- Ken