Subject: Tombstones and Link Extensions

From: James Snell <[email-masked]>
Date: Tue, 9 Nov 2010 12:48:04 -0800

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.

For the Link Extensions Draft [2], I've just pushed an updated version that
removes the media attribute. The use of media queries within Atom is still
extremely experimental and hypothetical. The rest is pretty solid and should
move forward. As far as I'm concerned, the Link Extensions Draft is complete
and I'm ready to push that forward to get an RFC # for it.

I have also just pushed an update for the Atom Link Inline draft [3]. This
makes a number of important changes and simplifies the extension
significantly. Feedback is requested.

[1] http://www.ietf.org/id/draft-snell-atompub-tombstones-11.txt
[2] http://www.ietf.org/id/draft-snell-atompub-link-extensions-08.txt
[3] http://www.ietf.org/id/draft-snell-atompub-inline-01.txt

- James

---

From: Alistair Miles <[email-masked]>
Date: Wed, 10 Nov 2010 11:35:37 +0000

Hi James,

> issues have come up so I'm ready to push that forward to get an RFC # for

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-masked]
Tel: +44 (0)1865 287669

---

From: Bob Wyman <[email-masked]>
Date: Wed, 10 Nov 2010 10:53:03 -0500

Alistair Miles <[email-masked]> 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-masked]>wrote:

> [2]
> http://code.google.com/p/atombeat/wiki/TombstonesDesign#Configuring_Ghosts
>
> --
> Alistair Miles

---

From: James Snell <[email-masked]>
Date: Wed, 10 Nov 2010 07:56:06 -0800

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.

---

From: Alistair Miles <[email-masked]>
Date: Thu, 11 Nov 2010 12:24:23 +0000

Hi James,

> that to anyElement so that additional atom:* metadata elements can be

I don't know relaxng very well, but I'm wondering if rather than using
anyElement you want to do something like atExtensionElement analogous
to the definition of extensionElement in RFC4287, e.g.,:

atSimpleExtensionElement =
   element * - at:* {
      text
   }

# Structured Extension

atStructuredExtensionElement =
   element * - at:* {
      (attribute * { text }+,
         (text|anyElement)*)
    | (attribute * { text }*,
       (text?, anyElement+, (text|anyElement)*))
   }

# Other Extensibility

atExtensionElement =
   atSimpleExtensionElement | atStructuredExtensionElement

...i.e., be explicit about not allowing extensions within the at: namespace.

Cheers

Alistair

>> 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
>> 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.
>> I support the optional provision of additional content in the deleted
>> entries.
>> bob wyman