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]
