Subject: A more concise round of date proposals

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 10 Aug 2004 21:13:32 -0700

Greetings again. The cone of silence about dates lifts.

We have three good, different proposals for what people think is 
needed for dates in Atom. Thanks to Asbjørn, Sam, and Antone for 
putting them together.

Please take a look at:

<http://www.intertwingly.net/wiki/pie/PaceDateAsbjornUlsberg>
<http://www.intertwingly.net/wiki/pie/PaceDateSamRuby>
<http://www.intertwingly.net/wiki/pie/PaceDateAntoneRoundy>

In your comments on them, please state what style hat you are wearing 
(client developer, content aggregator, publisher, and so on) and 
which you think best fits your needs. It is OK to talk about your 
wants as well, but please focus on needs, given that this is for the 
Atom *core* document.

And feel free to start threads with appropriate subject lines. This 
WG tends to not change subject lines often enough.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Roger B." <[email-masked]>
Date: Tue, 10 Aug 2004 23:56:09 -0500

My role: publishing developer, aggregator developer

All three paces meet my absolute needs, since each provides for a date that
I can produce and consume, and none of them force me to fill an element with
bogus data.

PaceDateAsbjornUlsberg:
I don't care for flagging atom:d as a SHOULD NOT. Other than that, no major
complaints. Minor complaints include the complexity of multiple core date
elements.

PaceDateSamRuby:
My preferred solution. When wearing my feed consuming hat, I just need a
date... any date. The freedom to ignore the subtleties of individual
publishing systems/processes would be nice. I don't need to know whether the
date indicates modification, issuance, creation, or whatever. 

When wearing my publisher hat, I'm dealing with users who can modify their
own feed templates, and can therefore make their own decisions about placing
dates inside elements. With Sam's proposal, it's impossible for them to make
a mistake when working with the core date element. The other proposals make
mistakes inevitable. (Given the complexity of things like Atom's content
element, though, this may turn out to be the least of my concerns.)

PaceDateAtoneRoundy:
A middle ground between the other two, lacking the SHOULD NOT on atom:d. Not
my preference, but no major complaints jump out at me. Minor complaints
match those for PaceDateAsbjornUlsberg

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/

---

From: Eric Scheid <[email-masked]>
Date: Wed, 11 Aug 2004 15:27:28 +1000

looks good, mostly.

The four date constructs which have semantics of (roughly)

[a] date of first issuance/publication
[b] date of any modification
[c] date of major update as determined by content publisher
[d] content related date value

hit, I believe, the 80/20 mark.

As a publisher, it wouldn't be very difficult to provide all four. Current
publishing tools don't support all four at this time, and might have to omit
one or two until a software update.

As a content consumer via various desktop/webtop aggregators, I need [d] or
[a] to put the content into context, and I need [c] rather than [b] to cut
through the noise to get to the signal.

As an aggregation tool developer, I would need [b] so I know I need to do a
full parse & database update. I would need [c] and [d] so I can pass the
value on to my users (with [d] it would be via highlighting updated
entries).

I also like how one date construct is required, rather than atom:entry being
larded with lots of date constructs (which for most cases would have the
same value, for that matter).

Having said all that, the things I don't like:

* timezone signal being lost in the wash. I don't really care to infer a
geographic location based on timezone, but I may want to know the time as
local to the user for additional context.

* RFC 3339 doesn't allow for unsynchronised times (ie. without a timezone).
As much as we really want to deprecate such things, there is unfortunately a
mass of dates already published which don't have timezone data. Given a
choice, I'd rather we didn't encourage bad data to masquerade as good data,
(while at the same time severely deprecating bad data, of course).

* atom:b (date of any modification) has an exclusion of external data ...
while the intent is good (for some some value of good), it raises problems.
If a feed incorporates external data such as geo:whatever or dc:terms, and
the inclusion of that external data is important and fundamental to the
feed, then atom:b should be updated even if only that external data is
modified. This pace provides atom:c to signal major changes of interest, so
a change in atom:b wouldn't necessarily result in a user being bombarded
with noise.

* the spec text is silent on the significance of "-00:00" as a TZD.

e.

---

From: Dave Pawson <[email-masked]>
Date: Wed, 11 Aug 2004 08:41:47 +0100

> <http://www.intertwingly.net/wiki/pie/PaceDateSamRuby>

Perspective: Author, reader.

+1.
Rationale: Simplicity. Easy to understand. Easy to implement.
Easy to remember.
Follows the KISS principle.
Has history.

-- 
Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl

---

From: Graham <[email-masked]>
Date: Wed, 11 Aug 2004 12:04:19 -0500

> hit, I believe, the 80/20 mark.

Make atom:a a MUST, flesh out the text a bit, absolutely perfect.

Graham

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 11 Aug 2004 20:52:01 +0200

On Tue, 10 Aug 2004 23:56:09 -0500, Roger B. <[email-masked]>  
wrote:

> PaceDateAsbjornUlsberg:
> I don't care for flagging atom:d as a SHOULD NOT.

This is now changed. The reason I first wrote SHOULD NOT was because it  
shouldn't be used as a substitute for any of the other dates. Now, I've  
added some text explaining if the Date Construct should be human- or  
tool-provided. atom:d is typically a human-provided date, while all the  
others are tool-provided.

Please let me know what you think.

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