Subject: Updated Tombstones Draft, Take 2

From: James M Snell <[email-masked]>
Date: Fri, 04 Jan 2008 17:25:37 -0800

Ok, another rev based on the feedback:

http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-04.txt

1. Until we can get the How-to-extend-the-Atom-NS question resolved,
    I've moved the deleted-entry element back into it's own namespace

2. To address the concerns James Holderness had about using attributes
    vs. elements, I have moved the two most important pieces of
    information in the tombstone (the entry id and timestamp) into
    attributes.  For instance,

    <at:deleted-entry ref="..." when="..." />

    The by and comment are still elements.

    <at:deleted-entry ref="..." when="...">
      <at:by>
        <name>James</name>
      </at:by>
      <at:comment type="text">
        comment spam
      </at:comment>
    </at:deleted-entry>

3. The language in the draft is rather tortured, but I've made a first
    attempt at more thoroughly explaining the trash link, including
    a statement that while multiple trash links can be provided, the
    relationship between them is undefined.

As always, comments welcome and requested.

- James

---

From: Eric Scheid <[email-masked]>
Date: Sat, 05 Jan 2008 18:16:38 +1100

> As always, comments welcome and requested.

is it intended that tombstones and such could or should be used for the use
case of moving an entry out of one feed/collection and into another (eg.
correcting a mis-categorisation)?

e.

---

From: James M Snell <[email-masked]>
Date: Fri, 04 Jan 2008 23:38:11 -0800

A tombstone communicates nothing more than the fact an entry was removed 
from the feed.  Whether that entry exists in some other form or in some 
other feed is a separate issue.  The tombstone does not provide a way of 
indicating where the entry may have moved to, only that it's gone.

- James

---

From: "Teo Hui Ming" <[email-masked]>
Date: Sat, 5 Jan 2008 20:17:55 +0800

Hi James,

quoted from draft-snell-atompub-tombstones-04:

>Linked "trash" resources are orthogonal to the at:deleted-entry
element and are intended to provide servers with a way of allowing
clients to recover deleted entries.

Is there a consensus on recovery mechanism that can (or should it?) be
included in tombstones extension?

>For instance, the entries in a feed may be managed by two
separate authors, one of whom may delete an entry that
the other author wishes to later recover.  If a trash feed
is provided, the second author can look for a copy of the
deleted entry there.

In this example, does it imply that a trash feed should contain full
representation copy of entries, so that the second author can simply
retrieve the copy and POST it back to the original collection feed?

-- 
Teo Hui Ming

---

From: "James Holderness" <[email-masked]>
Date: Sat, 5 Jan 2008 13:53:22 -0000

James M Snell wrote:
>    attributes.

Thank you. That is perfect for my needs. I've updated our implementation to 
match the current draft.

Regards
James

---

From: James M Snell <[email-masked]>
Date: Sat, 05 Jan 2008 13:52:20 -0800

> included in tombstones extension?

Not currently.  Recovery is going to mean different things to different 
applications.  For some, the entry will still be in the database and all 
that is needed is essentially either a move operation or flipping a bit 
from deleted to not-deleted.  For others, the data will have been 
removed from the datastore completely and the client needs to completely 
recreate the entry.  For now, I imagine that it would be best to leave 
the recovery mechanism undefined and let applications get a bit more 
experience with it before we start nailing down any kind of standard or 
best practice procedure.

> retrieve the copy and POST it back to the original collection feed?

Quite possibly. I've left this intentionally vague. Suggestions welcome :-)

- James

---

From: "Brian Smith" <[email-masked]>
Date: Sun, 6 Jan 2008 12:19:42 -0800

>     The by and comment are still elements.

I honestly don't understand what was so hard about the element-based encoding. I've implemented a parser for the element-based syntax using SAX--basically the most tedious parsing mechanism there is--and it was not inconvenient in the least.

"by", "comment," and "when" are not specific to deletion--they apply to entry creation and entry editing as well. If we can get by without these properties for POST and PUT, then we don't need them for DELETE either. K.I.S.S.

In place of "when", atom:updated and/or app:edited should be used. Deleting an entry is definitely a "significant" change (atom:updated) and it is definitely an edit (app:edited). This will also make it easier to see how the tombstones are to be sorted/paged in feeds that are sorted by one of these dates. The draft also needs to specify how the tombstones are interpolated with entries.

- Brian

---

From: "Brian Smith" <[email-masked]>
Date: Sun, 6 Jan 2008 12:25:23 -0800

James M Snell wrote:
> > Is there a consensus on recovery mechanism that can (or 
> > should it?) be included in tombstones extension?
> > 
> 
> Not currently.  Recovery is going to mean different things to 
> different applications.  For some, the entry will still be in 
> the database and all that is needed is essentially either a 
> move operation or flipping a bit from deleted to not-deleted. 
>  For others, the data will have been removed from the 
> datastore completely and the client needs to completely 
> recreate the entry.  For now, I imagine that it would be best 
> to leave the recovery mechanism undefined and let 
> applications get a bit more experience with it before we 
> start nailing down any kind of standard or best practice procedure.

I disagree. If there is no recovery mechanism, then what value does standardizing the "trash" link relation have? 

As you already pointed out, the trash mechanism is orthonogonal to the tombstone mechanism. It should be specified seperately, along with the recovery mechanism that makes it useful.

> > In this example, does it imply that a trash feed should 
> > contain full representation copy of entries, so that the second author 
> > can simply retrieve the copy and POST it back to the original
> > collection feed?
> 

It seems to me that WebDAV MOVE would be a better alternative for moving things between a trash collection and a normal collection (both ways). This would let the user choose whether he wants to delete an entry (DELETE) or just move it into the trash (MOVE).

- Brian

---

From: "Tatsuya Noyori" <[email-masked]>
Date: Tue, 8 Jan 2008 23:54:17 +0900

Hello,

I have two requests to the tombstones.

Request No. 1. analogy syntax:

I like Atom syntax. And I think analogy is important. So I hope that
the tombstones is similar in syntax to Atom syndication format. The
syntax is as follows:

<feed xmlns="http://www.w3.org/2005/Atom"
    xmlns:at="http://purl.org/atompub/tombstones/1.0">
  ...
  <!-- Minimal deleted-entry -->
  <at:deleted-entry>
    <at:id>tag:example.org,2005:/entries/2<at:id>
    <at:deleted>2005-11-29T12:11:12Z<at:deleted>
  </at:deleted-entry>
  ...
  <!-- Extended deleted-entry -->
  <at:deleted-entry>
    <at:id>tag:example.org,2005:/entries/2<at:id>
    <at:deleted>2005-11-29T12:11:12Z<at:deleted>
    <at:by>
      <at:name>John Doe</at:name>
      <at:email>[email-masked]</at:email>
    </at:by>
  </at:deleted-entry>
</feed>

Request No. 2. sync to Media Entry:

I hope Sync covers Media Entry, such as image files or pdf files. And
I think Media Entry needs Atom Feed like the following.

<entry>
  <title>Test.gif</title>
  <link rel="media"
href="http://localhost:8080/roller/Tokyo/resource/images/Test.gif"/>
  <id>http://localhost:8080/roller/roller-services/app/Tokyo/resource/images/Test.gif</id>
  <published>2007-11-02T05:20:58Z</published>
  <updated>2007-11-02T05:20:58Z</updated>
  <content type="xhtml">
    <div xmlns="http://www.w3.org/1999/xhtml">
      <a href="http://localhost:8080/roller/Tokyo/resource/images/Test.gif"/>
    </div>
  </content>
</entry>

And I think Atom Feed of Media Entry needs the following tombstones.

<feed xmlns="http://www.w3.org/2005/Atom"
    xmlns:at="http://purl.org/atompub/tombstones/1.0">
  ...
  <!-- Minimal deleted-entry -->
  <at:deleted-entry>
    <at:id>http://localhost:8080/roller/roller-services/app/Tokyo/resource/images/Test.gif<at:id>
    <at:deleted>2005-11-29T12:11:12Z<at:deleted>
  </at:deleted-entry>
  ...
  <!-- Extended deleted-entry -->
  <at:deleted-entry>
    <at:link rel="media-trash"
href="http://localhost:8080/roller/Tokyo/resource/images/Test.gif"/>
    <at:id>http://localhost:8080/roller/roller-services/app/Tokyo/resource/images/Test.gif<at:id>
    <at:deleted>2005-11-29T12:11:12Z<at:deleted>
    <at:by>
      <at:name>John Doe</at:name>
      <at:email>[email-masked]</at:email>
    </at:by>
  </at:deleted-entry>
</feed>

-- 
Tatsuya Noyori (^o^)/

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 8 Jan 2008 10:19:32 -0800

Tatsuya Noyori wrote:
> I like Atom syntax. And I think analogy is important. So I 
> hope that the tombstones is similar in syntax to Atom 
> syndication format.

I agree.

> I hope Sync covers Media Entry, such as image files or pdf 
> files. And I think Media Entry needs Atom Feed like the following.
> 
> <entry>
>   <title>Test.gif</title>
>   <link rel="media"
>       <a 

As a RFC 5023 media link entry, it would look like this:

  <entry>
    <title>Test.gif</title>
    <link rel="media"

<id>http://localhost:8080/roller/roller-services/app/Tokyo/resource/imag
es/Test.gif</id>
    <published>2007-11-02T05:20:58Z</published>
    <updated>2007-11-02T05:20:58Z</updated>
    <content
src='http://localhost:8080/roller/Tokyo/resource/images/Test.gif'/>
  </entry>

>       <at:email>[email-masked]</at:email>

An AtomPub client that depends on anything more than that <atom:id>
element being present in a tombstone is going to be non-portable. For
that reason, I recommend against putting additional information in the
tombstone. 

Anyway, it is better to specify the trash/soft delete/undelete mechanism
seperately from the tombstone mechanism.

- Brian

---

From: "James Holderness" <[email-masked]>
Date: Tue, 8 Jan 2008 17:32:00 -0000

>> hope that the tombstones is similar in syntax to Atom

Do either of you have a technical reason for your preference? Efficiency, 
interoperability, ease of implementation - anything like that? Or is this 
just an aesthetic issue for you?

Regards
James

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 8 Jan 2008 12:34:36 -0800

James Holderness wrote:
> hope that 
> >> the tombstones is similar in syntax to Atom syndication format.
> >
> > I agree.
> 
> Do either of you have a technical reason for your preference? 
> Efficiency, interoperability, ease of implementation - 
> anything like that? Or is this just an aesthetic issue for you?

The main benefit is that the syntax and semantics can be completely
delegated to RFC 4287 with minimal verbage. Even if you haven't read the
tombstone spec, when you see an <atom:id> element, its syntax and
semantics (especially the comparison rules and lack of a guarentee of
dereferencability) are immediately clear.

At the very least, I expect that the syntax of the timestamp to be
consistent with RFC 4287 and RFC 5023, which means using "date
construct" elements. It the timestamp is going to be an element then why
not make the ID an element as well?

RFC 5023 did a good job of reusing the RFC 4287 syntax whenever
possible. I thnk that is a practice that should be followed by other
extensions to RFC 4287. At the very least, such a policy will reduce the
need to discuss syntax and allow more time to discuss semantics. 

http://www.informatik.uni-kiel.de/%7emh/curry/listarchive/0017.html

- Brian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 9 Jan 2008 08:46:39 +1100

>> hope that the tombstones is similar in syntax to Atom

+1

Having a different syntactic style forces people to re-learn it,  
acting as a barrier to entry and giving them another chance to mess it  
up. When someone has gone to the trouble of knowing where to put an ID  
in an Atom entry, for example, it seems strange to make them re-learn  
where to put it in a tombstone.

I'm not lie-down-in-the-road about it, just seems like the sensible  
way to do things to me.

--
Mark Nottingham     http://www.mnot.net/

---

From: "James Holderness" <[email-masked]>
Date: Tue, 8 Jan 2008 22:59:13 -0000

Mark Nottingham wrote:
> Having a different syntactic style forces people to re-learn it,  acting 
> as a barrier to entry and giving them another chance to mess it  up. When 
> someone has gone to the trouble of knowing where to put an ID  in an Atom 
> entry, for example, it seems strange to make them re-learn  where to put 
> it in a tombstone.

And yet the syntax that Tatsuya Noyori suggested,  Brian agreed with, and 
you +1ed, didn't actually use an atom:id - the id was in the tombstone 
namespace. Getting that confused, seems to me a far more likely problem.

I'll admit that the issue could be argued either way, but I still think the 
benefits of using attributes outweigh any advantage that might be gained by 
having a partially shared syntax with RFC4287.

Regards
James

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 9 Jan 2008 11:14:18 +1100

On 09/01/2008, at 9:59 AM, James Holderness wrote:

> And yet the syntax that Tatsuya Noyori suggested,  Brian agreed  
> with, and you +1ed, didn't actually use an atom:id - the id was in  
> the tombstone namespace. Getting that confused, seems to me a far  
> more likely problem.

Good point.

My preference would be to put it all in the Atom namespace, as  
elements. If that's controversial (either because it's using atom:id  
et al out of context, or because of the namespace issue), attributes  
are the path of least resistance.

Cheers,