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