My key challenge with allowing the client to control the value of
atom:updated is multiuser environments. If User A updates Entry 1 with
a date of 2005-12-12T12:00:00Z then user B comes along and set a date of
2005-12-11T12:00:00Z, we've got a problem. The server should control
atom:updated.
Thomas Broyer wrote:
Tim Bray wrote:
<co-chair-mode>Uh, right, I stand corrected. PaceInsignificantUpdate
is still in the queue; I wrote that Pace because I heard a bunch of
people saying "gotta have this" so I'd jumped ahead mentally and
assumed it accepted.</co-chair-mode>
<thinking-out-loud-mode>It does seem painfully obvious, based on the
language in the atom-format draft, that the protocol must include
*some* way to indicate whether an update is significant or not. The
mechanics don't seem that interesting.</thinking-out-loud-mode>
I'd really prefer clients to just "update" the atom:updated value.
They SHOULD (MUST?) include a Date: HTTP header, and server
implementations wanting to e.g. avoid setting atom:updated to a
date-time earlier than the atom:updated value you'd GET could answer
with a 409 (Conflict) status code.
Something similar could be used to mark an entry as published or not
(draft). As long as an entry doesn't have an atom:published, it should
be considered unpublished (draft). Once you set an atom:published,
servers MAY ignore subsequent changes to the atom:published value (or
use a 409 Conflict or 422 Unprocessable Entity [1]). Servers that
don't support "draft" entries could enforce atom:published using a 400
Bad Request or 422 Unprocessable Entity.
[1] http://www.webdav.org/specs/rfc2518.html#STATUS_422
