The by and comment elements are largely speculative right now. Now sure
if they'll stay in there or not.
And yes, it would likely be a good idea for Atom processors to ignore
deleted-entry elements whose date is older than the entries updated
date. Also, just because an entry was deleted once, doesn't mean it
can't show back up again later... it should just be treated as a new
entry if it does.
One question: what's a reasonable length of time to keep the
deleted-entry elements in a feed? We don't really want to keep those
things around forever.
James Holderness wrote:
James M Snell wrote:
Still in experimental stages. Cleaned up a bit and removed the
archived-entry element. Comments requested... particularly from
potential client implementors...
http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-01.txt
I'm glad you've brought this up - I was just thinking about it last
night. Technically it looks great to me. I'm only interested in simply
deleting any tombstones I receive, so all I really need is the "id"
attribute. I understand the need for the "by" and "comments" elements -
just saying I'm unlikely to notice any problems with them.
As for the date, I'm unsure whether an Atom processor should be ignoring
tombstones that are dated older than the current updated date on an
element. If so, is that something worth mentioning in the spec?
Other editorial nits: In the introduction, "explicitly" is used twice in
the same sentence and you have a split infinitive - suggest nuking the
first usage. Near the end of section 3, you use the expression "deletion
operation". I don't know if it's just me, but that sounds wrong. Maybe
"delete operation", just "deletion", or even "removal of the entry"
(which is what you use later in section 5).
Regards
James
