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]
