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) >>> >> >> >
