Ok I was getting ready to say that the definition of deleted-entry already allows for it but I went back to double check and it's a good thing I did. I notice that it says "extensionElement*" instead of "anyElement*". In rfc4287, extensionElement explicitly omits atom:* elements. I will change that to anyElement so that additional atom:* metadata elements can be included.
On Wed, Nov 10, 2010 at 7:53 AM, Bob Wyman <[email protected]> wrote: > 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 >> >> >
