On May 20, 2005, at 6:06 PM, Graham wrote:
I don't see why, if you wanted that kind of archive, you couldn't
use atom:updated for every little change in the archived version
but atom:updated only for the ones you cared about in the
published version. In which case the archived version would be a
superset of the published version. I see nothing wrong with that.
-Tim
That's exactly my problem. You're having to hack the dates to make
it work. Would you encourage hacking in other ways?
I'm not hacking at all. In this scenario, for archiving purposes I
consider all changes no matter how small significant, and thus
preserve them all with different values of atom:updated. For
publication to the web, I have a different criterion as to what is
significant. I fail to see any problem in the archive being a
superset of the feed.
Say I'm aggregating feeds into a search results feed, and I get the
same entry twice (with the same atom:id and atom:updated), from
different sources. Would it be acceptable to me to adjust the
atom:updated by one second and put both in the results, to show the
end user the entry was available from two places?
There may be a reason to trust one of the sources more than the
other. If so, choose that. If not, apply the a policy such as
discarding any entries whose ID you've seen unless the atom:updated
is later than what you've seen so far. -Tim
