atom:id as variable assignment

[Robert Sayre <mint@xxxxxxxxxxxxxxx>]

I've made an effort to document the various models for atom:id I've seen 
on the list.

1.) Immutable
2.) Immutable/Composable (all entries are append-only collections)
3.) Mutable (current practice)
4.) Mutable w/ collection membership

I'm in favor of 3 & 4, and I've attempted to show that they don't 
preclude versioning capabilities.

------------------------------------------------------------------------

1.) atom:id as identifier for immutable Atom Entries.
Changes to the atom:entry require generation of a new identifier.

    myid =  <entry>foo</entry>
    [update the  entry]
    myid2 = <entry>bar</entry>

The problem with this approach is that consumers are likely to receive 
mostly duplicated content under different ids, something no one is 
interested in.

2.) A variation on identifiers and immutable values composes atom:id as 
a sort of A-list. Some proposals along these lines use composable URI 
parts (e.g. NewsML IDs). Others have proposed using atom:id in 
combination with a Date element.

The first part of the atom:id can be considered the "entry collection", 
consisting of the states the entry has held. As the state is changed, a 
value is appended to the collection. The second part of the id is the 
"key" that identifies a specific incarnation of the entry. Each member 
of the collection is immutable.

    my[id] =  <entry>foo</entry>
    my = { id:foo }
    my[id2] = <entry>bar</entry>
    my = { id:foo, id2:bar }

Thus, an entry would always be a collection type, even though most 
entries would consist only one member (and perhaps an implicit null key 
or index). One can imagine a scenario where an author decides to include 
full-content in his/her feed and also to retroactively apply this 
change. This would require versioned storage and transform all entries 
into multi-member collections. Is this a burden we wish to mandate? Note 
that the burden is social as well as technical, since it requires 
authors to highlight edits in a machine readable manner.  Existing 
practice has placed the burden of versioned storage on consumers.

3.) Atom ID as identifier for a mutable variable.
The identifier may be mapped to a changed atom:entry (the value is 
mutable/assignable). This closely matches current practice.

    myid = <entry>foo</entry>
    [update the entry]
    myid = <entry>bar</entry>

The issue here is that no method of indicating a change has been agreed 
upon. There have been proposals suggesting a timestamp for this purpose. 
From a consumer's perspective, there exists the possibility of lost 
updates, since a timestamp may be updated more than once during a given 
polling interval.

4.) Allow atom:entry values to remain mutable, but allow the presence of 
link relations to indicate grouping.

A possibility here would be a link relation (extension or core) that 
signals the location of the old content of the entry. That is, the 
atom:id served in the feed always points to the newest value of the 
entry. Historical values may be retrieved or identified by other URIs.

    myid = <entry>foo</entry>
    [update the entry]
    myid = <entry>bar
           <iChangedThis AndPutTheOldVersionsHere="..." />
           </entry>

This is probably the best way forward, since it's compatible with all 
existing clients, while preserving the possibility of versioned updates 
for those publishers or clients that require this capability. This link 
could point to a retrievable resource with versioning capabilities, such 
as WebDAV/DeltaV.

Robert Sayre