Brian Smith wrote:
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).:
I chose the original syntax because for me it's an order of magnitude easier to implement. And since I doubt I'm going to see any server support for this either way, I might as well go with whatever is easiest.
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.
If you're undeleting something, just remove the tombstone from the feed and add the entry back.
This new syntax also makes it possible to specify a <source> of the tombstone, which is needed when dealing with aggregated feeds,
I was thinking about that too. I don't see how you can possibly trust a tombstone in an aggregate feed. Still, there's nothing stopping you including a source element (or whatever other metadata) in the original syntax.
<x:deleted-entry id="xxx">
<atom:source>
...
</atom:source>
</x:deleted>
Regards
James