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?
There are a number of "deletion" use cases, some of which already have
support in the base Atom Format specification. For instance, since Atom
defines "replacement," (i.e. publish an entry with the same atom:id as one
previously published but with a later atom:updated date), there is already a
crude method for asking that content be removed from aggregators. However,
this tends to encouraging people to publish entries that have titles of
"Deleted," content of "Deleted." Etc. Not particularly elegant -- but it
works, sort of.
I'm afraid that if deleted-entry is introduced into the system, what we'll
see is that during some arbitrarily long transition period while we wait for
people to modify their software to support deleted-entry, people who really
want to purge the network of some late night blog post will tend to publish
both a "Deleted" replacement entry as well as a deleted-entry... They would
do this since it is potentially going to be a long time (perhaps infinite)
before deleted-entry is widely implemented and just publishing a normal
entry has much the same effect (but not completely) of publishing a
deleted-entry.
If, on the other hand, the definition of entry was extended to permit a
"deleted" flag or attribute, then we'd find that applications would have
implicit support for entry deletion without needing to write any more code.
Certainly, applications that understood what a deletion actually meant and
that understood the extra fields like when, by and comment, would be able to
do interesting things based on that understanding.
I'm also concerned that the utility of the deleted-entry mechanism is
limited to only those systems that rely on "topic-based" filtering -- i.e.
following a specific feed and consuming all of its content. We would need
some entirely different mechanism to support content-based filtering -- i.e.
extracting entries based on their content (presence of words, phrases,
etc.). Deleted-entry can't help a content-based system since unless such
systems maintain cumbersome logs of all atom:ids that are published and who
they were published to. The problem is that since a deleted-entry contains
virtually none of the data contained in the entry deleted, any topic-based
filtering can't figure out who might have previously received a copy of the
now-deleted entry.
Of course, the easiest way to delete things in a content-based system would
be to republish the original entry (with all its content) and mark the entry
as "deleted." This will work in, but not all applications, since in some
applications, one does not wish to republish the data that is being deleted.
However, in at least some applications, where one can trust that consumers
are paying attention to the deleted flag, it is acceptable to republish the
now out-of-date data.
If a deleted-entry is so much like an entry, why can't it just be one? (with
some extra metadata).
bob wyman
Post by James Snellhttp://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-09.txt
Quite a few important updates.
Post by Niklas LindströmOn Wed, May 19, 2010 at 1...
Ok, looks like we've got quite a bit good support for standalone
docs.. I'll add that in.
Post by Niklas LindströmApart from the use cases already mentioned (XMPP, 403
representations), I see potential for usi...
No prob. Thanks for the great feedback and input.
Post by Niklas Lindström* What would the mime-type for deleted-entry documen...
Putting these under the application/atom+xml media type would likely
cause badness. I'm thinking something like
application/atomdeleted+xml.
Post by Niklas Lindström* For good measure, making sure that this doesn't lead to a pattern of
PUT:ing deleted-entry do...
Yeah, this is a concern of mine also. Need to make sure people don't go there.
--
- James Snell
http://www.snellspace.com