On Friday, February 4, 2005, at 02:00 PM, Graham wrote:
On 4 Feb 2005, at 8:44 pm, Mark Nottingham wrote:"3.5 Identity Constructs An Identity construct is an element whose content conveys a permanent, universally unique identifier for the construct's parent."I.e., just because it's a "permanent, universally unique identifier" doesn't mean you're not able to use it twice to talk about a single entry;
I disagree, as I've said before. The only literal interpretation is that you can't serve the same entry twice with the same id. We know it doesn't mean that, but the spec just doesn't define in which axis "unique" is meant to apply.
Sure, if you really want to get nit-picky, this sentence when read in isolation says that the XML which is the parent of the ID construct is the only thing that may ever use this identifier. Taking this nit-pick to its extreme, you could say this means that its a violation to use the same ID for the entry on your hard drive and the entry in RAM, or perhaps even a violation to use the same ID for the entry in RAM across refreshes of the RAM, since different electrons are involved--or maybe even across instants in time, depending on the true nature of the space-time continuum. Obviously, at some point, the nit-picking gets ridiculous. We might resolve the nit-pick with language like this (which is a bit over the top):
"An Identity construct is an element whose content conveys an unchanging identifier which MUST be universally unique within Atom Documents to the set of all versions and instantiations of the resource that the construct's parent instantiates."
I personally expect people to understand the existing spec text as intended, especially within the context of what follows. For example:
When an Atom document is relocated, migrated, syndicated, republished, exported or imported, the content of its Identity construct MUST NOT change. Put another way, an Identity construct pertains to all instantiations of a particular Atom entry or feed; revisions retain the same content in their Identity constructs.
This makes it unmistakably clear that we were NOT talking about the ink that formed the specific XML that someone wrote down on their napkin, but "all instantiations" and "revisions".
