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