On 18/5/05 7:41 PM, "Graham" <[EMAIL PROTECTED]> wrote: >> Not so very long ago you suggested that aggregators look at the content to >> determine if it's changed. If it's good enough for aggregators, it's good >> enough for publishers (actually better than good enough since the publisher >> would be able to do the test before other transformations occur, thus >> eliminating some false positives). >> > But if the publisher does that, atom:modified is going to end up being the > date the atom-generating program is run rather than the date the modification > happened. You may argue that functionally this doesn't matter, and you'd be > right. You'd also be admitting that the absolute date is not important, as > long as the dates are in the right order - aka atom:version.
not quite. I agree "the absolute date of modification" is open to philosophical argument (eg. an author retrieves an entry into their editor, changes some bit, goes off for 5 minutes to answer the phone, comes back and presses the submit button ... what is the true date of modification now?) The absolute or true date of modification isn't the quality I'm interested in though. What I am interested in is having one such timestamp for any given modified content. Not multiple timestamps for the exact same content, which is what atom:version sloppily allows. e.
