Re: Tombstones and Link Extensions

[James Snell <[e-mail]>]

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 <[e-mail]> wrote:

> 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]
>>
>>
>