Re: Tombstones and Link Extensions

[Bob Wyman <[e-mail]>]

Alistair Miles <[e-mail]> 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 <[e-mail]>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: [e-mail]
> Tel: [phone]
>
>