Subject: Re: PaceDates

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 29 Jul 2004 23:15:07 +0200

On Thu, 29 Jul 2004 19:27:36 +0100, David Powell <[email-masked]>  
wrote:

> I realise that this is only a SHOULD, but I think that there are  
> sensible reasons for allowing atom:date to be in the future.

I think the consensus is that it's not.

> How about a feed of upcomming events, or weather forecasts

If these are compelling use cases Atom needs to support, we should embrace  
Dublin Core's 'available'[1] date that I think should cover these use  
cases pretty well.

> I don't think that this recommendation improves interoperability

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. e.g. atom:issued should never  
have a future date if the entry already available to its intended  
audience. This applies for all the other dates provided as well, I think,  
but if we embrace 'available', that text might be moved or changed.

> This is not how I see atom:date at all.  I see it as a piece of metadata  
> that a publisher wants to associate with the content of the
> entry, rather than a date associated with the publishing process like  
> the other dates are.

I can almost agree with that, besides that the current tools don't  
separate subjective from objective, internal from external or  
publisher-provided from process-provided. They mix all of these terms  
together, and most of them do it in one date. That's why the element is  
called 'date', and nothing more meaningful.

> I see it as a useful field that is present for more reasons that  
> backwards
> compatibility.

atom:date exists purely to cater for the date the current publishing tools  
provide for their entries. Please see BlogToolDateSurvey[2] for details.

> -1 to the SHOULD NOT.

Why? atom:Date is a semanticless date. It means absolutely nothing.  
There's no way to know what a publisher meant with it, unless you do some  
kind of feed-origin-tool-sniffing and then apply the correct semantic on  
the element based upon what type of tool published the entry. If you want  
to do that, okay, but I think all such sort of behaviour should be  
discouraged.

Publishers should strive to use one of the more meaningful Dublin Core  
dates instead. What is the future use case for not meaning anything in  
particular with the date associated with an entry? If there are use cases  
and semantics that aren't covered by the other dates specified in that  
pace, please let me know, and we can try to find some that do, but  
atom:date is only provided for compatibility reasons.

> Also I don't like the use of the word "tools" in that paragraph, I'd  
> prefer "publisher".

I agree. Changed.

> This is a place that allows the user to associate a date with an entry
> if they want to.

Some tools do this, others don't.

> I don't think that tools should generate it, other than perhaps to
> propose Now() as a default.

Movable Type does this, and will preserve that 'Now()' forever, if the  
user doesn't change it. Therefore, this date can both be purely  
tool-provided or publisher-provided from entry to entry. There's no way to  
tell the difference.

>> The content of an atom:date element MUST according to RFC 3339 have a
>> time zone whose value SHOULD be "+00:00" or "Z".
>
> I disagree with the SHOULD.  In fact I think that this date is more  
> useful if it includes the timezone of the publisher

I agree, so I've changed it.

>> atom:date MAY change to order the entries in an Atom feed or on a
>> front page of a website correctly.
>
> This implies that atom:date should be used to indicate the sort order,  
> but I'd rather we didn't say anything about that - it is up to the  
> User-Agent to decide on a sort order.  So, I'd rather just drop that  
> sentence.

Good point. Sentence dropped.

> I'd prefer the atom:date section to look something more like this:
>
> [...]

Could you read through the pace again now, as I've done some big changes  
according to yours and Eric's suggestions?

> It would be good to get Tim's travel journal example in the document  
> somewhere because that explains it pretty well.

What does his example explain, exactly?

____
[1] <url: http://dublincore.org/documents/dcmi-terms/#available>
[2] <url: http://intertwingly.net/wiki/pie/BlogToolDateSurvey>

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

---

From: Sam Ruby <[email-masked]>
Date: Thu, 29 Jul 2004 18:08:55 -0400

Asbjørn Ulsberg wrote:
> 
> On Thu, 29 Jul 2004 19:27:36 +0100, David Powell 
> <[email-masked]>  wrote:
> 

*sigh*

RSS 2.0, Blogger, MovableType, LiveJournal, etc would indicate otherwise.

I really, really, really would like to see dates being viewed as a way 
to model what is actually being used, as opposed to a PROCRUSTEAN BED[1].

- Sam Ruby

[1] http://www.bartleby.com/61/85/P0578500.html

---

From: Eric Scheid <[email-masked]>
Date: Fri, 30 Jul 2004 11:49:42 +1000

On 30/7/04 7:15 AM, "Asbjørn Ulsberg" <[email-masked]> wrote:
>>> [issued SHOULD be past tense]
>>

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

>> How about a feed of upcoming events, or weather forecasts
> 

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.

> 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'.

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).

e.

---

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

>>  I think the consensus is that it's not.

Okay. So it isn't consensus.

> RSS 2.0, Blogger, MovableType, LiveJournal, etc would indicate otherwise.

They allow for it, but for what reason? Either way, I've moved this  
«should not be in the future» into each date construct, and allowed for  
atom:date to be future.

If or when publishing tools move from the highly non-semantic atom:date to  
the more meaningful ones, it should be explicit what a future date  
actually does. If it's there to make the entry «unavailable», then the  
entry itself shouldn't be available. Hiding entries should not be up to  
the aggregators, but the publishing tools. If there are other use cases to  
have future dates, please let me know.