2006/1/27, James M Snell <[EMAIL PROTECTED]>:
> <at:deleted-entry>
> <atom:id>tag:example.org,2006:someentry</atom:id><--required-->
> <atom:updated>2005-01-27T12:12:12Z</atom:updated><--required-->
> <atom:author><atom:name>James</atom:name></atom:author><--optional-->
> <atom:summary>comment spam</atom:summary><--optional-->
> </at:deleted-entry>
[…]
> Is this better?
No, because it's not clear whether atom:author and atom:summary were
the one of the deleted entry or relative to the deletion.
<at:deleted-entry>
<atom:id>tag:example.org,2006:someentry</atom:id>
<atom:updated>2005-01-27T12:12:12Z</atom:updated>
<at:by><atom:name>James</atom:name></at:by>
<at:comment>comment spam</at:comment>
</at:deleted-entry>
Some will probably have the same question about the atom:updated: is
it the date when the entry was deleted or the atom:updated value
before deletion?
Some will probably ask whether then atom:id is the one of the at:deleted-entry…
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)
<!-- 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>
<!-- after deletion -->
<atom:entry>
<atom:title>…</atom:title>
<atom:id>tag:example.org,2006:someentry</atom:id>
<atom:summary>…</atom:summary>
<!-- the atom:updated is the date of the deletion, as it's unlikely
that the entry will change after that -->
<atom:updated>2006-01-27T12:12:12Z</atom:updated>
<del:deleted>
<del:by><atom:name>Thomas</atom:name></del:by>
<del:comment>comment spam</del:comment>
</del:deleted>
<!-- the [EMAIL PROTECTED]"edit"] has disappeared -->
</atom:entry>
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,
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)
Just thinking out loud…
--
Thomas Broyer
