On 7/5/06, Eric Scheid <[EMAIL PROTECTED]> wrote:
On 6/7/06 7:08 AM, "James M Snell" <[EMAIL PROTECTED]> wrote: > Whether or not to change atom:updated on an update request is > implementation specific and can only reasonably be determined by the > server. A server could choose to use the atom:updated value provided by > the client, but is not required to do so. -1. "can only reasonably be determined by the server"??? Servers, generally speaking, are not imbued with artificial intelligence. Determining whether something is a "significant" update requires understanding who the audience is, whether various laws have relevant jurisdiction, and understanding the motives and agenda of the content producer.
One notion of intelligence would be to ignore attempts to change updated w/out any material change in the contents of the entry. The definition of "material" seems possible in various domains: for a blog, it _might_ means if the PUT doesn't change the content or summary of the entry. Adding author info, rights changes, categories, or link relations wouldn't be considered "material". I provide the above only by way of an example. I don't want to get into the discussion of what *is* a "material" change, I doubt there is a single definition that fits all potential APP domains (or one that this group could agree upon :). Honestly, the case I'm *most* worried about clients that keep bumping their updated value just to keep their entry at the top of (or reoccurring in) syndicated views of the collection ordered by updated... i.e. a form of syndication spamming. Any spec-language that keeps the server from preventing such types of abuse is a strong -1 in my book, making the MAY in James' PACE necessary. It's naive to think APP clients will always play nicely with others. -- Kyle
