[reposted without so many typos and grammatical errors - reply to either]
As I was the last person to mention atom:modified, I'll refer to my proposal as an example in this reply. > 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. The rationale for PaceDateModified2 was to enable multiple revisions of entries to exist in the same Atom Feed Document. This usage doesn't require trust relationships to be set up. Cross-feed duplicate detection is a useful feature that requires a web of trust to work reliably. Atom doesn't provide this natively, but future companion specifications could provide a framework, just as DomainKeys and other specifications are trying to do for SMTP. Hopefully Atom deployments will be a bit more agile than SMTP, so this wouldn't be such a slow process. > 2. There's endless room for argument as to what constitutes an update: The text of PaceDateModified2 is looser than most of the previous proposals that were made, it is actually rather similar to the mandatory atom:modified element in Atom 0.3. It is updated when information in the entry (not the physical atom:entry element), which is reflected in the document is changed. Given that definition, I think that whether atom:modified needs to be updated can reasonably answered: > change in the stylesheet for background colors No: On the web you don't update the Last-Modified date for a web page when a linked style-sheet has changed, nor would you update atom:modified when documents linked to an Atom entry change. It is implicit in any specifications which uses URIs to reference related documents, that the representations are subject to change over time. HTTP's extensive cache-control mechanisms deal with this. > change from a unicode combined char to single + combining > diacritic, No. > change from UTF-8 to UTF-16 encoding No. > change in paragraph 27 of an article that doesn't show up in a > summaries-only feed, No. > 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. Re-fetch? If they know that the atom:modified date has changed, then they already have the entry don't they? Do you mean that they want to discourage clients from re-fetching linked images etc? HTTP cache control mechanisms are the way to do this. Most aggregators defer image retrieval to a browser widget, so whether the document has changed or not will have no effect on whether the linked documents are refetched for these implementations. The Atom police wouldn't be able to stop people from ignoring the specification and faking atom:modified to a fixed value, but the effect for the subscriber would be similar to if a server operator faked Last-Modified to a fixed value in HTTP. The wide deployment of Atom 0.3 suggests that support for atom:modified wouldn't be an unsurmountable burden for implementations, but anyway, there is another alternative: I proposed PaceDateModified2 to address the issue that feeds containing multiple revisions of an entry would not be able to distinguish which revision is the latest. (Remember the entries are unordered). Some sort of atom:revision-count element would work too. Its value could even be defaulted to 0 in its absence for minimal intrusiveness. I think that atom:modified is a better option though, because it has uses beyond revision sorting within a document, and it is probably easiest for implementations to implement given the widespread support for a similar element shown in BlogToolDateSurvey. -- Dave
