RE: Tombstones

["Brian Smith" <brian@xxxxxxxxxxxxxx>]

James wrote:
> FWIW, I've just added tombstone support to our feed reader 
> based on James's initial tombstone draft. A tombstone entry 
> looks something like this:
> 
>   <deleted-entry
>     id="urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"
>     xmlns="http://purl.org/atompub/tombstones/1.0"; />
> 
> As you say, this is pretty easy to implement. I added it 
> mostly for use with private feeds, but it would cool in the 
> future if there were servers that supported this in comment 
> feeds for deleting spam. If not, well at least it's met my 
> personal needs. Nothing else that's been proposed here comes close.

Ha. I already implemented it too, but I used the updated syntax that
James suggested on his blog (http://www.snellspace.com/wp/?p=818).:

  <x:deleted>
    <id>urn:lsid:ibm.com:oa:123...</id>
    <updated>2007-12-12T12:13:13.123Z</updated>
    <app:edited>2007-12-12T12:13:13.123Z</app:edited>
  </x:deleted>

I think this way makes it clearer how to handle cases where an entry was
added, we saw it, the entry was deleted, we saw a tombstone, and then
the entry was undeleted, and we see the entry again. In order to support
undelete, we need to be able to order tombstones and entries by date.
Many AtomPub implementations are providing undelete or similar
mechanisms and so this needs to be taken into account.

This new syntax also makes it possible to specify a <source> of the
tombstone, which is needed when dealing with aggregated feeds, because
of intentional and unintentional spoofing, aggregated feeds aggregating
other aggregated feeds, and entries being moved from one feed to
another. 

Finally, as James showed, the new syntax also provides a place to stuff
FeedSync(-like) metadata, for when it is needed.

- Brian