Re: AD Evaluation -- updated?

[Eric Scheid <eric.scheid@xxxxxxxxxxxxxxx>]

On 18/10/06 9:40 AM, "James M Snell" <jasnell@xxxxxxxxx> wrote:

>> - Can the client change the "updated" value to be some time in the
>> future? Some time long ago?  Or are there only two non-error changes --
>> "now" or "the previous value"?  MUST the server accept the value if it's
>> the same as the previous value?  Or can there be servers that always
>> ignore "updated" values from clients? (and if so, is it important for
>> the client to know that the server does this)
> 
> Generally No, but it's up to the server.  For the most part, servers
> should and will manage the value of atom:updated themselves.

huh?

atom:updated is meant to be publisher controlled metadata, not a server
controlled element. The server has no business making subjective assertions
as to whether the change is "significant" or not.

Clients should be able to specify atom:updated, and they should also be able
to specify it as being in the past or the future.

We could also define a new app:control element: <app:update>yes</app:update>
which would signal to the server to insert it's current time value into the
atom:updated element.

>> [snip]
>> The spec says "The value of atom:updated is only changed when the change
>> to a member resource is considered significant. "  The use of passive
>> voice obscures who does what here.  When the client doesn't suggest a
>> value for "atom:updated", does the server provide one, and if so, how
>> does the server know what is "significant"?   I thought it would always
>> be the client suggesting values, but Tim says that the server controls
>> atom:updated which could imply that the client doesn't even need to
>> suggest values.  See above about whether the server MUST accept certain
>> values for "updated", or more likely, MUST NOT accept suggested values
>> for "updated" when they're clearly wrong (e.g. this entry was last
>> updated on October 16, 1906).
>> 
> 
> My assumption: Tim is correct.  The server controls atom:updated. While
> the client is required to provide a valid atom:updated element, the
> server can (and in most cases will) ignore that value.

My assumption: ultimately, the server can ignore the client in any way it
damn well wants, including replacing atom:content with total gibberish and
randomly deleting entries. Other than that, atom:updated is much more useful
as a client controlled thing.

e.