Subject: PaceDateSamRuby

From: Antone Roundy <[email-masked]>
Date: Wed, 11 Aug 2004 12:46:57 -0600

'The "atom:d" element's content conveys a date associated with an event 
in the life cycle of the entry.'

This appears to be quite different from any of the kinds of time stamps 
we've discussed in the past.  It sounds like it's supposed to be an 
"objective" date, associated with an event--not pulled out of the air 
or time-shifted by convention like the 2005 model year for cars which 
begins in the latter half of 2004.  But what it objectively identifies 
is purposely unclear.  Does the fact that one can't depend on it to be 
the time stamp of any PARTICULAR event make the objectivity implied by 
the spec text useless?  Or is the intent simply to eliminate "fanciful" 
dates, and be satisfied that it's meaning has been narrowed 
sufficiently?  I'm still trying to decide whether that feels satisfying 
or not.

'Consumers MAY chose to sort based on this value.'
...but we're going to be fairly vague regarding whether it would make 
sense to do so.

'Consumers MAY chose not to display entries containing atom:d elements 
until the date specified.'
...but we're not really saying anything about what it means to post 
date an entry, so who knows whether doing this makes sense or not?  Is 
a posted dated entry not INTENDED for display till it's date comes up 
(but only as a suggestion--obviously the word is out once the entry is 
published)?  Or is a posted dated entry talking about a future event?  
There's no way of knowing...for a machine anyway.  Some post dating may 
be a thinly veiled ploy to get one's entries displayed above others' 
entries (which could be done with any other kind of Date Construct, so 
that's not a "vulnerability" unique to this proposal).

I'm ALMOST satisfied with using dcterms for specific dates.  The 
problems with that are:

1) There's no "subjective" date--at least not in the list in this 
proposal.
2) There's no "updated" date (vs. "modified"...or is dcterms:modified 
the date we've been calling "updated"?  I could look it up, but either 
way, one of the two isn't there).

The question to me feels like, are we going to be satisfied with 
something a LITTLE more specific than we've seen in RSS, or do we dare 
brave the tempestuous waters of hammering out a set of more specific 
dates?  A majority or people who participated in the Date Survey 
expressed an interest in three particular dates and one non-specific 
one, two of which aren't available in this proposal.  But getting 
consensus on a proposal that DOES provide each of those looks like it 
could be difficult.

I personally don't see the difficulty in having the four dates many of 
us expressed interest in.  Of course, there are others here who have 
more experience with this stuff than me.  But do any of us have 
experience with a syndication format that has more than one date 
construct?  If not, then whether that experience bears directly on this 
issue is at least a valid question.

I don't think I'm going to invest any further effort into campaigning 
for any particular proposal.  You have my opinion.