Alistair Miles <[email protected]> wrote: > we have a need to include some metadata elements > from the original atom entry within the deleted entry +1 In a variety of content-based message routing applications it is actually very important that the record of a deletion carry with it as much as possible of the data which is being deleted. The reason is that content-based streaming systems do message routing based on the content of an entry rather than simply on its source elements. (They implement "Track" not just "Follow.") For such a system to be able to route a deletion to a destination that might have previously received the item being deleted, one of two approaches must be used:
- The simplest approach is to include in the deleted entry the same content that would have been used to route the entry prior to its deletion. This makes it possible to simply route deleted-entries by using the same code as is used for routing normal entries. - A more complex and robust method requires that the router maintains a persistent record of all routing decisions, keyed by atom:id. Deleted entries are then routed based on this record of previous routing decisions. This can be, however, excessively expensive in some contexts. If using this approach, one must also deal with issues such as the maximum age of useful routing data. (When, if ever, can you delete routing logs?) The second method (i.e. recording all routing decisions) is probably the most robust since it can also be used to handle cases of updates to entries which produce a new entry instance that would have not been routed in the same way as the original. However, it should be noted that few systems implement such complexity. Given the considerations above, I would support (as I have in the past) the suggestion that deleted entries be permitted to optionally carry much if not all of the same content as the entries which are being deleted. It should probably be made clear somewhere, that developers SHOULD NOT expect that all publishers of deleted entries will, in fact, include this content. Developers should only build code that relies on content-full deleted-entries in cases where application profiles extending the base specification assure that such content is provided. But, note that while carrying this content should be optional, it isn't possible unless permitted. I support the *optional* provision of additional content in the deleted entries. bob wyman On Wed, Nov 10, 2010 at 6:35 AM, Alistair Miles <[email protected]>wrote: > > Hi James, > > On Tue, Nov 09, 2010 at 12:48:04PM -0800, James Snell wrote: > > Ok, so the Atom Tombstones [1] draft, at this point, is definitely > complete. > > I decided to wait a while before advancing it to see if any further > comments > > would come in. I know there are some implementations already and no major > > issues have come up so I'm ready to push that forward to get an RFC # for > > it. > > In [1] I mentioned that we have a need to include some metadata elements > from > the original atom entry within the deleted entry, in particular atom:title, > atom:author and atom:publised, but that this is prohibited by the content > model for the at:deleted-entry element, so we invented an extension element > in our own namespace for this (see [2]). > > If no-one else has this requirement then fine, but I would have thought > there > would be quite a few situations where an application would want to present > a list of deleted entries to a user and show more than just @ref @when and > at:by - pretty much every situation in which a person wants to look at a > list of deleted entries. > > I would much rather avoid a custom extension element and instead make the > content-model for at:deleted-entry more permissive, e.g.: > > deletedEntry = element at:deleted-entry { > atomCommonAttributes, > attribute ref { atomUri }, > attribute when { atomDateConstruct }, > ( element at:by { atomPersonConstruct }? > & element at:comment { atomTextConstruct }? > & atomAuthor* > & atomCategory* > & atomContent? > & atomContributor* > & atomId? > & atomLink* > & atomPublished? > & atomRights? > & atomSource? > & atomSummary? > & atomTitle? > & extensionElement*) > } > > An implementation would then be free to include as little or as many of > these > additional elements within a deleted entry as required. A client consuming > a feed with deleted entries could choose to render this information if > present. > > Again, if no-one else sees this as an issue then fine, but I do think there > is a potential interoperability issue here that should be at least > commented > on prior to RFC. > > Apologies if I've missed anything relevant in previous discussions. > > Cheers > > Alistair > > [1] http://www.imc.org/atom-syntax/mail-archive/msg21574.html > [2] > http://code.google.com/p/atombeat/wiki/TombstonesDesign#Configuring_Ghosts > > -- > Alistair Miles > Head of Epidemiological Informatics > Centre for Genomics and Global Health <http://cggh.org> > The Wellcome Trust Centre for Human Genetics > Roosevelt Drive > Oxford > OX3 7BN > United Kingdom > Web: http://purl.org/net/aliman > Email: [email protected] > Tel: +44 (0)1865 287669 > >
