A short proposal. The spec text makes it clear that "deleting" an entry might not remove it from the public record, so we won't be creating any illusions. The reasons for not putting the deletion notice inside <entry>...which perhaps should be added to the rationale...are:
1) <entry> has required elements which would only serve to bloat a feed if included for deleted entries.
2) Deletion notices need not consume space in the "sliding window" on existing entries.
3) Separating deletions out of entries makes it possible to easily maintain a sliding window on deletions separate from the sliding window on existing entries (for example, the feed could contain the 15 most recent non-deleted entries, and the 15 most recent deletions.)
Rationale
Some systems cache and continue to display entries after they disappear from the "sliding window" into a feed. There is no way to tell the difference between an entry disappearing from the sliding window and an entry being deleted. In some circumstances, such as when deleting blog spam, it is highly desirable to have the entries deleted from external caches. This proposal specifies a light-weight method of explicitly indicating deletion of entries.
Proposal
Add the following as a child element of <feed> (not in <head>):
"atom:deletion" Element
The "atom:deletion" element indicates that an entry which previously appeared in the feed has been deleted. The content of atom:deletion is the atom:id of the deleted entry. atom:feed elements MAY contain zero or more atom:deletion elements. Publishing application MAY decline to publish atom:deletion elements. Consuming applications which cache entries MAY delete the indicated entries from their caches. If they do not, they SHOULD indicate to their consumers that the entry has been deleted by the publisher. Consuming applications MUST ignore atom:deletion elements whose content indicates the atom:id of an entry from a feed other than the containing feed.
