The problem with "firming up the requirements" is that RFC4287 states
that atom:updated is only changed when the "publisher" determines the
change to be "significant". However, the terms "publisher" and
"significant" are not defined. Is the "publisher" the client or the
server in the context of APP? What constitutes a "significant" change in
APP? Should all changes be considered "significant"?
- James
Lisa Dusseault wrote:
> That would have to be pretty clearly stated as a warning in the spec,
> because otherwise, my experience is that clients will come to rely on
> some accidental behavior of a value like "atom:updated" rather than
> really be flexible. Is there no chance of firming up the requirements
> how servers update the value?
>
> lisa
>
> On Jul 5, 2006, at 8:45 AM, James M Snell wrote:
>
>>
>> Ultimately, the server is responsible for applying whatever heuristic it
>> wants to determine when to update atom:updated. Some servers will
>> update atom:updated for every update; others will take whatever the
>> client gives it; others may actually differentiate between various kinds
>> of updates. There's no "should" to it. Different servers will handle it
>> differently based on their specific requirements.
>>
>> - James
>>
>> Thomas Broyer wrote:
>>>
>>> 2006/7/5, Eric Scheid <[EMAIL PROTECTED]>:
>>>>
>>>> On 5/7/06 5:09 PM, "Thomas Broyer" <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> But in most cases particularly if it does not check for "minor
>>>>> updates" , yes, the server will (should?) update the atom:updated
>>>>> value.
>>>>
>>>> no. atom:updated is set by the publisher to indicate the date/time of
>>>> last
>>>> significant change. If they don't change atom:updated then the server
>>>> shouldn't assume any change = significant change.
>>>
>>> What if the server does not allow editing the metadata ("media link
>>> entry"; PROPPATCH in the WebDAV world) but allows updating the content
>>> ("media resource")?
>>>
>>
>
>
