Re: Tombstones and Link Extensions

[Alistair Miles <[e-mail]>]

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]