James et al, I have to admit that this all sounds rather complicated. I'm already having stiff resistance to adoption of Atom in other standards because of [unfounded] perceived complexity and would rather not give the critics justification.
>From what I understand of the requirements I tend to agree with Bob in that atom:entry should contain a "deleted" attribute or entry, possibly specifying the deletion time. As tombstones are almost always the exception rather than the rule I don't see "deleted" placeholder text being a huge problem and it allows publishers some flexibility in leaving some/all of the content in place in an interoperable fashion (e.g. avoiding the need to extend deleted-entry with atom:entry or its children). In any case I'm not the first to suggest<http://www.imc.org/atom-syntax/mail-archive/msg20057.html>that you can always exclude the tombstones by default and enabling them with a query parameter. I do think this draft runs the risk of being widely implemented, and in its current form will add non-negligible complexity to most client and server code bases; in contrast ignoring entries with a "deleted" attribute/element is a trivial change. If it's well justified and there's a strong consensus then fine, but implementors of draft specifications know what they're getting themselves into so I don't see this as a strong case to keep the status quo. Sam Google On Tue, May 25, 2010 at 1:12 AM, James Snell <[email protected]> wrote: > > One additional comment, because of the extension model allowed by the > tombstone, it would also be possible for a publisher to include the > complete atom:entry as a child of the at:deleted-entry to address the > scenarios that Bob has brought up... e.g. > > <at:deleted-entry> > ... > <atom:entry> > ... > </atom:entry> > ... > </at:deleted-entry> > > - James > > On Mon, May 24, 2010 at 3:51 PM, James Snell <[email protected]> wrote: > > Yes, I wanted to be careful about dictating any kind of behavior if > > the keys ended up being different because there are legitimate reasons > > why they would be (e.g. if an editor deletes an entry created be a > > different author). Applications just need to be aware of the potential > > risks involved. Ironically, the greater risk is deletion with a > > compromised key. > > > > On Mon, May 24, 2010 at 3:43 PM, John Panzer <[email protected]> wrote: > >> Note that Salmon (http://salmon-protocol.org) also needs standalone > (signed) > >> deleted entry documents. Its security model allows for changing of > keysm -- > >> e.g., if the original was compromised -- as long as both keys are bound > to > >> the same author/uri. > >> > >> On Wed, May 19, 2010 at 8:36 PM, Bob Wyman <[email protected]> wrote: > >>> > >>> James Snell <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > 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 > >>>> [email protected] > >>> > >> > >> > > > > > > > > -- > > - James Snell > > http://www.snellspace.com > > [email protected] > > > > > > -- > - James Snell > http://www.snellspace.com > [email protected] > >
