FWIW, this is the model currently implemented by the Lotus Connections Activities component. The primary reason it works is because Activities uses the notion of a soft-delete; where a deleted entry is moved to a Trash collection and all of it's metadata is preserved. The entry still exists, it's state has just changed. A soft-deleted entry can be undeleted and restored to it's original collection or purged. We have no way of representing a purged entry because the data is completely removed from the database.
If a system is using soft-deletes and the notion of a trash collection, then I would say that this is a fairly good approach, mainly because the atom:entry element are pointing to something that still actually exists. However, if the system is doing a hard-delete and is only preserving the id of items that have been deleted, it does not make any sense to represent those deleted items using the atom:entry element and doing so runs the risk of confusing certain clients into thinking that they're looking at some piece of content that still actually exists on the server. Bottom line: we should avoid over-overloading atom:entry. Regardless of the specific solution required, some invention is required and clients will have to take specific actions to support tombstones, so we are not saving anyone any work by reusing atom:entry for this and we run the risk of confusing clients. The x:deleted tombstone element avoids that risk entirely, which for me, makes it the superior solution. - James Joe Gregorio wrote: > On Dec 6, 2007 7:45 AM, David Powell <[EMAIL PROTECTED]> wrote: >> Quoting James M Snell <[EMAIL PROTECTED]>: >>> 1. Deleted entries (aka Tombstones) are indicated by extension elements >>> contained within the atom:entry element. For clients that do not understand >>> the SSE extensions, these will appear no different than any other entry >>> such clients would have no way of knowing that the entry was deleted. Also, >>> this solution assumes that there is still enough data in the database to >>> reconstruct the deleted entry in the feed. The content, title, tags, etc may >>> all have been removed from the database. >> I disagree. Having clients that don't understand the extensions >> processing them in the same way as updates to the entries seems like a >> massive plus-point for FeedSync to me. > > Agreed that putting the deleted entries in the same feed is problematic. > So why not put them in another feed? A feed dedicated to such > deleted entries, ala a trash/tombstone feed? > > If I have feed that I want to keep track of deleted entries > for I could have a link to a trash/tombstone feed: > > <feed ..> > <link rel="trash" href="http://example.org/trash/feed/";> > <entry> > ... > </entry> > </feed> > > And the feed at http://example.org/trash/feed/ would look like: > > <feed ..> > <entry> > <id></id> > ... > </entry> > .... > </feed> > > Now since atom:id does not change for an entry I need only trawl > through the entries > in the trash feed looking for atom:id's I've seen before. Require > that entries be ordered in reverse order by their app:edited value > and that trash feeds are chained together via link/@rel="next" links ala > AtomPub collections and you're all set. All that functionality > and the only thing you have to do is register a new link > relation of 'trash' or 'tombstone'. [Add the atom:link element with a > relation of "trash" to an AtomPub service document > collection as a way for collections to signal that they > support tombstones.] > > -joe >
