On 21/5/05 9:40 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote: > 1. The datestamp is inserted by the provider. Thus it could be a lie; > this is the Internet, remember. You, the consumer, either trust the > publisher or you don't. If you don't, you will ignore the datestamp > and check the content. If you do, you will believe the datestamp. > Thus, "modified" buys you nothing.
I don't believe trust is a matter of "you do or you don't". I trust some people to do some things, but don't trust them on other matters. The more subjective something is, the less I might trust someone. The more objective/automated, the easier it is to trust. Will there be bad actors that will subjectively fiddle with atom:modified? There are always bad actors... however, if they betray their skullduggery nature by fiddling with something as objective as atom:modified why then would I even begin to trust what they say in atom:content? > 2. There's endless room for argument as to what constitutes an update: > change in the stylesheet for background colors, change from a unicode > combined char to single + combining diacritic, change in paragraph 27 > of an article that doesn't show up in a summaries-only feed, change > from UTF-8 to UTF-16 encoding, there were more examples too, some of > them scary-subtle. I still say we need to define/clarify the difference between an "entry" and atom:entry. That might help. > 3. Several publishers on the list asserted that they needed the right > to make trivial spelling-correction-level changes without having a > zillion literal-minded feed-reading clients re-fetch the material, and > that they would simply refuse to update an atom:modified date if they > didn't feel like it. The spec is also silent on whether a publisher must produce a new serialisation of <atom:entry> every time there is a change in the back-end resources. The spec does imply that if you do, then atom:modified would be updated ... but if a tree falls on a mime in the
