Sunday, May 22, 2005, 3:36:05 AM, Tim Bray wrote:
> Summary: David Powell fails to materially address any of the three > fatal flaws I pointed out in the notion of atom:modified. I remain > firmly at -1. Tim, thanks for taking the time to make specific points discuss this in detail, despite your opposition to it. This is productive route to progressing the debate towards the rejection or approval of these proposals. >>> 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. > This entirely fails to address my basic point: that if you trust the > publisher's judgment as to what's significant, then atom:updated is > good enough. If you don't atom:modified doesn't help. I've addressed this in "Re: updated and modified yet again". The value of atom:updated is specified as author's opinion. I trust that it is your opinion, but I'd like the option of forming my own. For users reading your feed, your opinion is likely to be accurate; for archivers reading your feed, it is not. It depends on the purpose on the purpose of the processor - Here is an example: Your publishing provider provides a feature which allows you to download an archive of the entries that you posted. Would you expect the archive to contain all of the instances of entries that you posted and were visible for t seconds/days/weeks/years on the Internet - or would you expect the archive to discard the instances with the same atom:updated value? My expectation of an archive, is that it would record everything that had been posted and had been live on the Internet at any point in time. >>> 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: > I entirely disagree, based on years of experience in publishing > applications, and there was disagreement with your judgment on these > cases posted to the list within 3 hours. The notion that any two > organizations can agree on what objectively constitutes an update is > unsupported by the evidence. Roger's cases? Like I said, either option would have satisfied PaceDateModified2, and either option would have satisfied its goal as a temporal ordering of entry instances. >>> 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? > No. Lots of entries are summary-only, not full-content. In my case, > I do some of both, and in the long entries that are summary-only, I > regularly make minor changes to the trailing part of long entries and > decline to refresh the feed or the atom:updated date, specifically > because I do not went each of the ten thousand or so newsreaders who > fetch my feed to go and re-get the entry because I fixed a typo in > paragraph 11. Ok - sorry I didn't interpret your argument accurately. You are concerned with aggregators accessing alt links every time an atom:modified date is updated. atom:modified, I'll say it again, provides a temporal ordering of entry instances. Software that uses it to flash "THIS ENTRY HAS CHANGED" messages at users, is not serving the user well, as the atom:updated value provides a more accurate means of doing this, for this set of processors - ie humans reading a feed. Software could adopt an equally paranoid behaviour by hashing the entry contents and using changes in it to communicate that an entry has changed. Neither method would serve the user well. -- Dave
