For the overwhelming majority of Atom clients, there's nothing easier
than ignoring an extension element they don't understand and not
having to worry about phantom atom:entry elements that represent
deleted content.... it doesn't take any effort at all to ignore an
atom:entry that doesn't exist ;-) ...
1. Simple example A
<feed>
<at:deleted-entry ref="abc" when="..." />
<entry>
<id>xyz</id>
...
</entry>
</feed>
2. Simple example B
<feed>
<entry at:deleted="true">
<id>abc</id>
</entry>
<entry>
<id>xyz</id>
</entry>
</feed>
Given these two choices, ordinary clients that do not know anything
about tombstones will, correctly, only see one entry in Example A...
but will see two entries in Example B.. one that doesn't really exist
and whose title, author, updated, alternate link and summary/content
won't necessarily actually exist or provide any useful information to
the client whatsoever.
For clients that support tombstones, looking for at:deleted-entry vs
atom:entry/@deleted is actually fairly trivial... Using
atom:entry/@deleted however still leads to an unnatural mapping of
atom:entry for the most common tombstone cases because the values for
atom:title, alternate links, atom:summary or atom:content just might
not exist. An implementation only needs to worry about extension
elements in at:deleted-entry when they have specific use cases that
call for them. Not really all that complicated :-D
On Mon, May 24, 2010 at 4:51 PM, Sam Johnston <[email protected]> wrote:
> 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 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]
>>
>
>
--
- James Snell
http://www.snellspace.com
[email protected]
