RE: Changing atom:id

["Brian Smith" <brian@xxxxxxxxxxxxxx>]

Eric Scheid wrote:
> On 30/9/07 3:48 PM, "Brian Smith" <brian@xxxxxxxxxxxxxx> wrote:
> 
> > But, that only applies to POST, not PUT. Servers should be 
> compliant 
> > with *both* RFC4287 and AtomPub, so they should never 
> change atom:id, 
> > even on POST.
> 
> ah, but at which point in time is an atom entry created, and 
> until it actually exists as an atom entry does it matter if 
> the bits shift and morph?

Okay, I think I understand what you are saying. Please correct me if I
am wrong again.

A resource is anything identified by an URI. An atom entry always
contains an atom:id element, which contains a URI that identifies it.
Thus, an atom entry is a resource.

The AtomPub specification says "POST is used to create a new,
dynamically-named, Resource." So, POSTing to an AtomPub collection
creates a new atom entry; that is, POSTing to an AtomPub collection does
NOT copy the client-supplied entry into the collection. The new atom
entry is distinct from the atom entry that was in the POST request body.
Therefore, the atom:id of the new entry in the collection MUST NOT be
the same as the atom:id used in the POST request body, because RFC4287
does not allow two distinct entries to have the same atom:id, and
because a single URI cannot identify more than one resource.

Thanks,
Brian