Subject: Re: atom:created same as atom:modified?

From: Antone Roundy <[email-masked]>
Date: Tue, 20 Jul 2004 13:23:16 -0600

On Tue, 20 Jul 2004 16:45:24 +0200, <[email-masked]> wrote:
> My suggestion is making all of created, issued and modified MUST 
> dates. Make them objective dates, and provide an optional subjective, 
> freeform
> "displaydate" element.
>
I'd have to say that requiring three dates in each entry, and possibly 
ending up with four, feels a little heavy.  As I've already mentioned, 
I don't think created is going to be useful to many people.  And in 
many cases, issued and modified are likely to be identical.  We could 
at least specify that if one of those two is omitted, that it may be 
assumed to be the same as the other--which to require and which to 
allow to omit doesn't matter much to me, so I'll defer to anyone who 
has a reason for preferring one of the other.

> Since CMSes have to be changed anyway to provide (meaningful) Atom 
> support, I suggest that these applications,  set created to be the 
> earliest
> of any "issued" or "modified" date when updating their database 
> schemes.
>
While that should be encouraged, I'd still advocate not requiring any 
objective dates.  I think there are just too many potential methods of 
generating feeds from a variety of data sources to be able to expect 
that generating objective dates for them to be feasible.  The more 
feeds there are where those dates really aren't "objective", the less 
value there will be in claiming that they are objective dates.

---

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

On Tue, 20 Jul 2004 13:23:16 -0600, Antone Roundy <[email-masked]>  
wrote:

> As I've already mentioned, I don't think created is going to be useful
> to many people.

Probably true, unless it differs much from 'Issued'. I've written some  
about this here:

<url: http://www.virtuelvis.com/quark/archives/188.html>

> And in many cases, issued and modified are likely to be identical.

How's that? I can understand it if the last change is saved at the same  
instance the entry is published to the web, but if these two actions are  
done seperately, the dates will be different. Also, viewing current  
practice as the wholy grail of date handling is imho not the way to go, as  
the current date handling couldn't be any simpler than it is.

> We could at least specify that if one of those two is omitted, that it
> may be assumed to be the same as the other--which to require and which
> to allow to omit doesn't matter much to me, so I'll defer to anyone who

 From a publisher's point of view, 'issued' is the far most important one.  
 From an aggregator writer's point of view, I assume 'modified' to be the  
most important one. To get these two viewpoints to agree is like making  
friends of zebra's and aligators. Not that they hate or eat each other;  
they just have so different needs that it isn't reconcilable.

> objective dates.

-1.

> I think there are just too many potential methods of generating feeds
> from a variety of data sources to be able to expect that generating
> objective dates for them to be feasible.

Exceptions are of course okay, but the norm should be that 'issued',  
'modified' and 'created' is objective, or at least as objective as  
possible. There's really no reason for them not to be, as all publishing  
systems has actions corresponding to the dates:

   * A resource can't be put out on the web without being published.
   * A resource can't be published without being created.
   * A resource is most often modified several times both before and
     after issuance.

> The more feeds there are where those dates really aren't "objective",
> the less value there will be in claiming that they are objective dates.

True. That's why the specification needs to be clear on the issue, and why  
the tools should start supporting this and changing their internal data  
models now. As I've said before, this isn't a large change. It is at most  
a couple of lines of code per date, and the old entries which doesn't have  
these dates just set the missing dates to the exisiting one.

Having bad dates on old entries and good dates on new ones is better than  
having bad dates on both old and new.

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