Subject: Atom Tombstones Draft

From: James M Snell <[email-masked]>
Date: Thu, 26 Jan 2006 13:44:07 -0800

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

- James

---

From: "James Holderness" <[email-masked]>
Date: Fri, 27 Jan 2006 00:34:55 -0000

James M Snell wrote:
> archived-entry element.  Comments requested... particularly from potential 
> client implementors...
>

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

---

From: James M Snell <[email-masked]>
Date: Thu, 26 Jan 2006 17:10:15 -0800

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:
> 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.
> 
> 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 
> "delete operation", just "deletion", or even "removal of the entry" 
> (which is what you use later in section 5).
> 
> Regards
> James
> 
>

---

From: "James Holderness" <[email-masked]>
Date: Fri, 27 Jan 2006 01:25:40 -0000

James M Snell wrote:
> 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.

Actually I think I probably would recommend keeping them forever. Just treat 
them like any other entry. If they fall out the bottom of the feed window 
that's ok, but if the server implements next/previous links to history 
feeds, then the tombstone could still be found in the archives.

Anything else is just guessing. You really can't tell how regularly a user 
might update from your feed. Now if you don't support history then it's just 
tough luck - the fact that they've missed out on entries is more of a 
problem than missing out on deletions. However, if you do support history, 
it would be a shame not to support tombstones in that history as well.

Anyway, that's my preference. Not necessarily a SHOULD recommendation - just 
my personal opinion.

Regards
James

---

From: Thomas Broyer <[email-masked]>
Date: Fri, 27 Jan 2006 09:19:12 +0100

> feeds, then the tombstone could still be found in the archives.

[…]

> Anyway, that's my preference. Not necessarily a SHOULD recommendation - just

+1

Maybe at:by and at:comment could be used in pub:control in the APP as well

--
Thomas Broyer

---

From: James M Snell <[email-masked]>
Date: Fri, 27 Jan 2006 00:49:33 -0800

> Maybe at:by and at:comment could be used in pub:control in the APP as well

Hmmh... hadn't thought of that.  Edit comments are common and 
pub:control would be the logical place to put 'em.  I'm not so sure that 
putting at:by in pub:control gives us anything useful tho.  Will have to 
stew on that one.

- James

---

From: James M Snell <[email-masked]>
Date: Fri, 27 Jan 2006 12:30:19 -0800

Ok, so this makes sense and I've received other input that the id and 
when attributes should be elements instead.  Given this, perhaps the 
deleted-entry should look something like this instead:

<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>

In a feed, these would appear mixed in with atom:entry elements:

<feed>
   ...
   <entry>...</entry>
   <entry>...</entry>
   <at:deleted-entry>
     <id>tag:example.org,2006:someentry</id>
     <updated>2006-01-27T12:12:12Z</updated>
   </at:deleted-entry>
   <entry>...</entry>
   ...
</feed>

Is this better?

- James

James Holderness wrote:
> Actually I think I probably would recommend keeping them forever. Just 
> treat them like any other entry. If they fall out the bottom of the feed 
> window that's ok, but if the server implements next/previous links to 
> history feeds, then the tombstone could still be found in the archives.
> 
> Anything else is just guessing. You really can't tell how regularly a 
> user might update from your feed. Now if you don't support history then 
> it's just tough luck - the fact that they've missed out on entries is 
> more of a problem than missing out on deletions. However, if you do 
> support history, it would be a shame not to support tombstones in that 
> history as well.
> 
> Anyway, that's my preference. Not necessarily a SHOULD recommendation - 
> just my personal opinion.
> 
> Regards
> James
> 
>

---

From: Thomas Broyer <[email-masked]>
Date: Fri, 27 Jan 2006 23:53:12 +0100

[…]

> 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 link[@rel="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

---

From: James M Snell <[email-masked]>
Date: Fri, 27 Jan 2006 19:28:42 -0800

> generic way to provide edit comments? (issue: pub:control is specific

I knew this would come up ;-)

>     <atom:link rel="edit" href="…" />

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 del:* extension… not really what was intended isn't it? (however,

heh... note to self: read the whole note before starting the response.  ;-)

> 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

---

From: "James Holderness" <[email-masked]>
Date: Sat, 28 Jan 2006 04:11:22 -0000

>   <del:comment>...</del:comment>

I think I've probably mentioned this before, but FWIW I preferred the id and 
date as attributes since that's easier for me to parse. More compact too. I 
don't know which is technically more correct, but if you can't decide one 
way or the other and you're looking for votes, you now know my preference.

Regards
James

---

From: James M Snell <[email-masked]>
Date: Fri, 27 Jan 2006 20:23:30 -0800

I tend to prefer attributes also, but the elements are structurally and 
stylistically more in tune with Atom.  And given the by and comment 
elements (which I know you don't particularly have a need for), having 
id and when as elements doesn't add any significant level of additional 
parsing difficulty.  Either way, your preference is noted.  Let's see 
how others weigh in on it and see how it goes.

James Holderness wrote:
> I think I've probably mentioned this before, but FWIW I preferred the id 
> and date as attributes since that's easier for me to parse. More compact 
> too. I don't know which is technically more correct, but if you can't 
> decide one way or the other and you're looking for votes, you now know 
> my preference.
> 
> Regards
> James
> 
>