Wednesday, February 1, 2006, 3:20:23 PM, Thomas Broyer wrote:
> [CC'ing atom-syntax] > 2006/2/1, David Powell <[EMAIL PROTECTED]>: >> >> 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. > IIRC, it was to allow a feed listing "revisions" of the same entry: > same id, different "updated" values. I don't have a problem with allowing multiple revisions with the same atom:id in a single document at all; I think that is a good thing. On the contrary, I have a problem with preventing multiple revisions from having the same atom:updated value. It subverts the intent of atom:updated being a subjective element, and it puts the feed compiler in an impossible situation. Nothing prohibits the entry author from producing two different instances with the same atom:updated value, but given this valid situation, the feed compiler is forced to silently lose data. And for what purpose? The restriction is useless anyway. If it is trying to provide a strict ordering of instances within a feed, it fails, because the restriction only applies within a feed document. Two seperate polls of a feed document can still produce two different instances with the same updated value. It also prevents synchronization applications, such as Microsoft's SSE from introducing a more discerning date/revision extension, because nothing is allowed to be more discerning than atom:updated, even though the specification admits that: "not all modifications necessarily result in a changed atom:updated value" -- Dave
