James Snell <[email protected]> wrote: > As for standalone deleted entry documents... > the key question is > whether they are compelling.
An example... "Atom over XMPP<http://xmpp.org/internet-drafts/draft-saintandre-atompub-notify-07.html>" 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] >
