comments on draft-snell-atompub-tombstones-11

Alistair Miles <alimanfoo@googlemail.com> Wed, 20 October 2010 11:27 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=cjb1EnECFxYIUq37OkzRSrcYuQtlyNMcx9N+MUmd14mIqYx/QQ5PJVFFrQ88BHQ3pK HJ8vMteI0zSm38zf12rkcyYogLvWNgssYdYV8+mIt9S3w+HgDpQ31KdeupHdk1FHR/OW PBsu04ITIrncqCrVQFEP9p46HcuUCFB/TCMdI=
Date: Wed, 20 Oct 2010 12:22:57 +0100
From: Alistair Miles <alimanfoo@googlemail.com>
To: atom-syntax@imc.org
Cc: ian.wright@well.ox.ac.uk
Subject: comments on draft-snell-atompub-tombstones-11
Message-ID: <20101020112256.GB3249@aliman-desktop>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk

Hi all,

We're looking at implementing tombstones as part of work on scientific
data repositories at the University of Oxford. We have a couple of
comments/questions on the most recent draft [1] and would be grateful to
hear suggestions/recommendations from others.

(1) For a collection where tombstones are enabled, if I delete a member,
then issue a subsequent GET to the member URI, what should the (a) status
code and (b) response body be?

E.g., would it be best practice to respond with a 410 Gone and send the
<at:deleted-entry> as the response body?

(2) We have a situation where some media resources need to be deleted from
a collection. We want to be able to present a list of media resources in
the collection to the user, providing at least the title and author of each
media resource and the datetime published, and showing whether the resource
is available or has been deleted - this means that users will be able to
recognise which resources have been deleted.

An atom feed containing both atom:entry and at:deleted-entry elements
seems like a good way of representing the data, but as I understand it, the
content model for at:deleted-entry allows only atom:link, atom:source and
(non-atom-ns) extension elements.

Why not loosen the content model for at:deleted-entry to allow atom:title,
atom:summary, atom:author, atom:published ... i.e., all potentially useful
metadata elements from the now-deleted atom:entry. It is then up to the
implementation to decide which of these it will include/reveal in the deleted
entry. (An implementation might even choose to make it configurable on a
per-collection basis, e.g., where some collections have more sensitive data
than others.)

As it is, it looks like we would have to invent our own extension element
to contain these other atom elements, but it would be a shame if others have
the same requirement and we all end up inventing our own extension.

Best wishes,

Alistair

[1] http://tools.ietf.org/html/draft-snell-atompub-tombstones-11

-- 
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: alimanfoo@gmail.com
Tel: +44 (0)1865 287669

comments on draft-snell-atompub-tombstones-11 Alistair Miles