Thomas Broyer wrote:
But now that you're having something looking more and more like an
atom:entry, how about just adding an at:deleted to an atom:entry? and
integrating the at:by and at:comment inside the pub:control in a more
generic way to provide edit comments? (issue: pub:control is specific
to the APP)
I knew this would come up ;-)
<!-- before deletion, in APP context -->
<atom:entry>
<atom:title>…</atom:title>
<atom:id>tag:example.org,2006:someentry</atom:id>
<atom:summary>…</atom:summary>
<atom:updated>2006-01-25T10:10:10Z</atom:updated>
<atom:link rel="edit" href="…" />
</atom:entry>
The challenge with this is that after the item is deleted, it's quite
likely that you won't have enough data still hanging around to meet the
minimum content requirements of an atom entry. Also, given that readers
that don't understand the tombstone extension are required to ignore it,
all they'd likely end up seeing is just another Atom entry, potentially
with empty content, an empty title, no author, a link that doesn't point
anywhere, etc. If I subscribe to the feed after entries have been
deleted, I'll end up with a bunch of meaningless, contentless entries.
That sucks.
The only drawback –a priori– of this solution is that it means
updating the atom:updated value of the atom:entry, which will bring
the entry to the attention of the user if the reader doesn't support
the del:* extension… not really what was intended isn't it? (however,
heh... note to self: read the whole note before starting the response. ;-)
it's arguable: should a deletion be silent? how about adding a
del:when in the del:deleted? the atom:updated would then continue to
serve its role: whether to bring the entry to the user's attention)
Personally I'd prefer that the atom:entry would just go away
completely... and replaced with a deleted-entry. That way, they'd be
invisible to dumb clients and smart clients could just do the right thing.
Everything else makes sense (e.g. keeping by, when and comment in the
tombstone namespace). The id element would always be the id of the
entry that was deleted.
Which leaves us with...
<del:deleted-entry>
<atom:id>...</atom:id>
<del:when>...</del:when>
<del:by>...</del:by>
<del:comment>...</del:comment>
</del:deleted-entry>
- James
