Don't you have the same problem with atom:modified? What if the publisher does not update the atom:modified entry?
I suppose that if you are making an archive of an atom entries and believe
that the author has made a mistake with the atom:updated field, you can
of course try to correct the mistake artificially in your own feed by
increasing the time precision. So if the original entries both claim to
have been updated at 12:45 you could have one of them be modified at 12:45:30
and the other at 12:45:31.
Just a thought.
Henry Story
On 12 May 2005, at 01:40, David Powell wrote:
I'm in favour of allowing duplicate ids. This only seems to be a partial solution though:
"Their atom:updated timestamps SHOULD be different"
But what if they are not? What if I want to represent an archive of a feed - maybe mine, maybe someone else's - but the atom:updated dates are the same in two or more entries? I thought it was up to the publisher to decide whether to rev atom:updated.
I was always concerned that the existence of atom:updated without atom:modified would cause the meaning of atom:updated as an alert to be diluted to being equivalent to atom:modified. This proposal would encourage that. It would mean, if you don't update atom:updated, then your entry instances are second class.
The restriction forces services that proxy, or re-aggregate feeds to drop entries on the floor, just because the user has chosen not to update atom:updated.
atom:updated encourages aggregators to make loud noises when they see a change; anything that encourages atom:updated to be changed just for the sake of it is going to be very annoying to users and make atom:updated useless as an alert flag.
I'm in favour of duplicate ids, but unfortunately, the only way I can see them working is if we have atom:modified. I hate to bring this up, especially now, but it would solve some problems, and it is cheap to implement:
Is anyone still opposed to atom:modified?
-- Dave
