Subject: atom:updated - not now() values?

From: Eric Scheid <[email-masked]>
Date: Mon, 14 Aug 2006 04:04:23 +1000

When updating an entry, is it acceptable to insert a value other than Now()
into atom:updated?

For example: Corporate Communications prep a release and they stamp it with
a release date of Monday 4 PM ... but I don't see this release update until
I get into the office at 2 PM Tuesday, and thus I quickly enter it into the
CMS and set the atom:updated value to Monday 4 PM.

e.

---

From: Tim Bray <[email-masked]>
Date: Sun, 13 Aug 2006 12:22:08 -0700

> When updating an entry, is it acceptable to insert a value other than Now()

Clearly, since updated is defined as the time the publisher thinks it 
was significantly updated.  Of course, the server could over-write the 
updated value if it chose. -Tim

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 13 Aug 2006 20:26:13 +0100

> When updating an entry, is it acceptable to insert a value other than Now()

Yes. Reasons below.

> CMS and set the atom:updated value to Monday 4 PM.

That's the kind of scenario that's begging for a business rule. I don't 
see anything in Atom that disallows those kind of policies.

1: the above scenario has run into the difference between document 
management, content management and publication. Atom doesn't distinguish 
between those.

2: an asshole reading of atom:updated says it should bind to the Atom 
Entry . A moron reading says it could bind to the thing the Entry is 
trying to describe (a press release, or news about a press release, 
or...). Atom isn't precise enough in it's denotation to say one way or 
another.

3: Literally, the spec doesn't say you must enter a Now() value. It also 
doesn't say whose Now() value you should enter.

I think policy you would apply would be primarily driven by what you 
think atom:updated points at, ie, the first point to close out above is 
2. It does not help that Atom says little about Entry life cycles, for 
example, how Entries get onto servers in the first place, which is the 
issue your scenario has to deal with. Btw, I think the scenario 
describes a highly plausible state of affairs.

cheers
Bill