Well, there is a definite reason why I allow at:deleted-entry to contain extension elements.. one could easily do something like:
<at:deleted-entry ...> ... <atom:title>the entry title</atom:title> <atom:content type="text">the entry content</atom:content> ... </at:deleted-entry> Because of the extension model, at:deleted-entry can contain all of the atom:entry children, the exact semantics, however, is undefined by the base tombstone spec. A content-based application could define the necessary semantics and things would just work. On Mon, May 24, 2010 at 1:16 PM, Bob Wyman <[email protected]> wrote: > It might be good to include the reason for *not* reusing atom:entry in > non-normative text. I imagine that many folk will ask this question. > I realize that achieving perfection is sometimes not possible... > Nonetheless, I'd like to point out again that if deleted-entry doesn't > support all the fields that entry does, then it becomes impossible to > support a variety of applications that rely on content-based rather than > topic-based routing. > bob wyman > > On Mon, May 24, 2010 at 3:55 PM, James Snell <[email protected]> wrote: >> >> The fundamental argument for at:deleted-entry is that Atom processors >> that do not understand Tombstones would see anything along the lines >> of <entry at:deleted="true">...</entry> or whatever as any other >> entry. Further, many systems that currently do not support the notion >> of a soft-delete typically do not keep around enough metadata about >> the deleted entry to meet the minimum content requirements of an >> atom:entry. The title, the content, etc would likely either have to be >> blanked out or set to something like "DELETED", etc. The challenge >> with this is that any given feed could contain any number of >> tombstones and entries mixed together... users of non-tombstone aware >> clients could potentially see a bunch of useless "DELETED" entries >> that serve no purpose whatsoever. With the at:deleted-entry approach, >> unaware clients will have a better user experience and aware clients >> can still do the right thing. With the entry/@deleted approach, >> unaware clients get suboptimal results. With either approach, >> processors that want to be aware of tombstones have to do the same >> amount of work to implement support. >> >> On Mon, May 24, 2010 at 12:32 PM, Peter Keane <[email protected]> >> wrote: >> > >> > A bit farther into that thread: >> > >> > http://www.imc.org/atom-syntax/mail-archive/msg20111.html >> > >> > --peter >> > >> > On Mon, May 24, 2010 at 2:28 PM, Peter Keane <[email protected]> >> > wrote: >> >> Hi All- >> >> >> >> For what it is worth, there was a fairly in-depth conversation about >> >> tombstones back in Dec 2007. James Snell (and others) put forth >> >> strong arguments against it just being another atom:entry (I was among >> >> those, at the time, advocating for atom:entry, but I have come around >> >> to the lighter option mainly for practical (not aesthetic) reasons). >> >> >> >> The thread begins here, and may be worth perusing (follow links to >> >> follow-ups): >> >> >> >> http://www.imc.org/atom-syntax/mail-archive/msg20050.html >> >> >> >> --Peter >> >> >> >> >> >> On Mon, May 24, 2010 at 2:08 PM, Bob Wyman <[email protected]> wrote: >> >>> Erik, >> >>> I don't think we would have to go as far as changing the semantics of >> >>> any >> >>> standard atom elements. Rather, what I'm suggesting is that "delete" >> >>> is >> >>> really just a bit of an extension to what the existing replace means. >> >>> In >> >>> other words, if you understand the "delete" flag, however, it is >> >>> encoded, >> >>> you would do a delete, if not, then you would simply do a replace as >> >>> per the >> >>> existing spec. This would be properly backwards-compatible. >> >>> I would, of course, regret breaking any early-adopter code. However, I >> >>> suggest that there is a much larger population of long-ago-adopters >> >>> who >> >>> wrote Atom code potentially years ago and would, if deleted-entry >> >>> became >> >>> accepted, have to consider rewriting or at least modifying their code. >> >>> One >> >>> of the risks of being an early adopter is that things may change, >> >>> however, >> >>> people who wrote code to the published spec should be granted the >> >>> right to >> >>> expect that things will be more stable. >> >>> The only downside I can see in extending the existing entry is that >> >>> the >> >>> resulting tombstones would be a bit less bit-efficient than desirable. >> >>> (i.e. >> >>> they would, in most cases, probably end up having empty required >> >>> elements -- >> >>> such as atom:title.) >> >>> bob wyman >> >>> On Mon, May 24, 2010 at 2:28 PM, Erik Wilde <[email protected]> wrote: >> >>>> >> >>>> hello. >> >>>> >> >>>> Bob Wyman wrote: >> >>>>> >> >>>>> The Tombstone draft is coming along nicely, however, I can't help >> >>>>> wondering... Since it appears that a deleted-entry is so much like a >> >>>>> normal >> >>>>> entry, why isn't it just an extended atom:entry with some additional >> >>>>> element >> >>>>> or attribute flagging it as deleted? >> >>>> >> >>>> i think this is a great approach of looking at what "deletion" means, >> >>>> in a >> >>>> way it's just another "update". however, there probably are two major >> >>>> problems with this approach: >> >>>> >> >>>> - it is not backwards-compatible with prior versions of the draft, >> >>>> and it >> >>>> seems that the draft already has seen some adoption. if the goal is >> >>>> to not >> >>>> break these early implementations, then moving from deleted-entry to >> >>>> entry >> >>>> is not an option, i am afraid. >> >>>> >> >>>> - atom disallows extensions to change the semantics of any standard >> >>>> atom >> >>>> elements. whether additional metadata changing the semantics of an >> >>>> "updated" >> >>>> entry to a "deleted" entry is such a change in semantics is a >> >>>> question of >> >>>> perspective. one could say that "deleted" is different from >> >>>> "updated", or >> >>>> one could say that it's just a special case. >> >>>> http://tools.ietf.org/html/rfc4287#section-4.2.15 just says that 'The >> >>>> "atom:updated" element is a Date construct indicating the most recent >> >>>> instant in time when an entry or feed was modified in a way the >> >>>> publisher >> >>>> considers significant', which i think could be seen as covering the >> >>>> case of >> >>>> deletion of an entry as well. >> >>>> >> >>>> personally, i think that having an entry/@deleted would be quite a >> >>>> bit >> >>>> more elegant and consistent than having a deleted-entry (there is no >> >>>> updated-entry, after all...), but that still does not solve the >> >>>> problem of >> >>>> breaking early adopters' code. but for me, the most important thing >> >>>> is to >> >>>> have something in feeds that covers the CRUD's D, so i am very glad >> >>>> to see >> >>>> the tombstone draft moving along again, whatever it will end up >> >>>> defining. >> >>>> >> >>>> cheers, >> >>>> >> >>>> erik wilde tel:+1-510-6432253 - fax:+1-510-6425814 >> >>>> [email protected] - http://dret.net/netdret >> >>>> UC Berkeley - School of Information (ISchool) >> >>>> >> >>> >> >>> >> >> >> > >> > >> >> >> >> -- >> - James Snell >> http://www.snellspace.com >> [email protected] > > -- - James Snell http://www.snellspace.com [email protected]
