Re: Tombstones Update

[Bob Wyman <bob@xxxxxxxx>]

James Snell <jasnell@xxxxxxxxx> wrote:

> As for standalone deleted entry documents...

> the key question is
> whether they are compelling.

An example... "Atom over XMPP" calls for publishing streams of Atom Entry Documents over XMPP. Because there was no mechanism defined for deleting in Atom itself, "Atom over XMPP" ended up defining a "retract" message for that purpose. It would be more natural to use a tombstone. 

But, the general question is: Atom format permits my application to publish only Entry Documents. However, if I do that, and if a delete-entry can only exist as an element of a Feed Document, how do I tell anyone about a deleted-entry? Would I need to modify my protocol to support Feed Documents simply as a means to transport deleted-entries? Doesn't seem right.

bob wyman

On Wed, May 19, 2010 at 11:17 PM, James Snell <jasnell@xxxxxxxxx> wrote:

Heh, Bob... you and I seriously need to get into the same room with a
whiteboard sometime.. lol..

Ok, first about your previous comment about atom:source... yes, the
intention is for it to be identical to the use within atom:entry so I
will tighten that up in the spec...

As for standalone deleted entry documents... I definitely can think of
a few generally interesting potential use cases... the key question is
whether they are compelling.

- James

On Wed, May 19, 2010 at 7:58 PM, Bob Wyman <bob@xxxxxxxx> wrote:
> In Atom, both Entry Documents and Feed Documents are "top-level" objects. An
> entry may be contained within a Feed Document, but it need not be. This is
> an important characteristic of Atom and one that distinguishes it from
> previous, legacy syndication formats. This attribute of Atom makes it
> particularly well suited for use in applications that rely on combining
> entries from multiple sources as well as applications that provide real-time
> delivery of data.
> However, the deleted-entry that you define in the tombstone draft is defined
> as only existing within Feed Documents. This represents a significant and
> unfortunate departure from the base Atom RFC.
> I would strongly encourage you to ensure that deleted-entry is symmetrical
> with atom:entry and that it is available in all contexts (i.e. both within
> and without a Feed Document) that an Atom entry is. Just as we can have
> Entry Documents, we should be able to have Deleted-entry Documents.
> bob wyman
> On Wed, May 19, 2010 at 2:10 AM, James Snell <jasnell@xxxxxxxxx> wrote:
>>
>> Another backwards compatible update... explicitly allowing for an
>> optional atom:source element as a child of at:deleted-entry.
>>
>> http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-08.txt
>>
>> - James
>>
>
>

--
- James Snell
 http://www.snellspace.com
 jasnell@xxxxxxxxx