Wednesday, February 1, 2006, 6:21:12 AM, James M Snell wrote:
> Entries in an Atom feed can share the same atom:id but their > atom:updated values should be different. To be precise, it is "Entries in an Atom Feed Document" not "Entries in an Atom feed". I really really dislike that rule, and don't understand how it was ever accepted, and personally I would be tempted to ignore it. The author of the entry is the person that decides on the entry's atom:id and atom:updated values. The compiler of the feed selects entry instances to appear in the feed document. This rule assumes that the entry author, and feed compiler are the same entity, that the acts are somehow implemented atomically, and that the feed compiler must discard some entry instances [*] that they have been given to satisfy this arbitary rule which doesn't seem to benefit anyone. [* I suppose that the feed compiler could retain those instances for a few weeks until the old instances had dropped out of the feed document, but that is obviously ridiculous. ] The paragraph's implication that atom:id and the subjective atom:updated field together form a composite id to identify an entry instance (but only within a document, not within a rolling feed) is absurd. But, I posted about this at the time, and it ended in a lot of shouting. > Given that, What should a collection do if it receives multiple entries > with the same atom:id and atom:updated values? If these are submitted > one after the other, it is quite likely a duplicate post error. > However, let's say they are posted a day apart from each other? It should be entirely up to the client to decide whether to rev atom:updated. If the server drops the client's request based on this subjective field value, then it is doing the client a disservice. -- Dave
