Subject: Feedback on Tombstones -04

From: Mark Nottingham <[email-masked]>
Date: Sat, 19 Apr 2008 12:42:26 -0700

James,

Overall, I would very much like to see this progress -- either on the  
standards track or as informational -- ASAP, as I believe it to be  
useful, mature (with the nits below noted) and have immediate needs  
for it (albeit in internal projects, but we'd prefer not to create  
something proprietary, or to adopt still-not-stable technology).

1) "If the at:deleted-entry element does not contain a when element,  
the at: deleted-entry sharing the same atom:id as an entry MUST be  
ignored." This is too strict; if a feed has an explicit ordering  
(e.g., a marker giving semantics to lexical ordering), an  
implementation may determine which has precedence by that ordering.

2) "Atom Feed Documents MAY contain any number of at:deleted-entry  
elements, but MUST NOT contain more than one with the same ref  
attribute value." ... but later ... "An Atom feed MAY contain  
atom:entry elements and at:deleted-entry elements sharing the same  
atom:id value." The MUST NOT is too strict; it makes coincidence of  
deletions a serialisation problem (notice that it's specified in terms  
of feed documents, not feeds).

3) Are extensions elements and attributes allowed?

4) I'm still not entirely comfortable with the trash link relation;
  a) it seems to conflate the semantics of "this moved somewhere else"  
and where it moved to (i.e., the trash). There are other reasons why  
something might be moved to another feed, and
  b) the relationship with deleted-entry is still a bit fuzzy, from a  
user standpoint. Does the presence of a trash feed mean that a client  
should go to the effort of subscribing to it and removing entries that  
appear in it?

Why not, for example, allow deleted-entry to specify where an entry  
has moved to (allowing a default to be set as a link relation,  
perhaps), and let *that* feed define whether or not it's a trash bin?

5) AIUI User Experience folks say that in some cultures references to  
images of death are inappropriate; it may be good to find a more  
neutral name for the spec (I don't have a problem with it; just  
occurred to me).

Cheers,

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

---

From: James M Snell <[email-masked]>
Date: Mon, 21 Apr 2008 08:00:50 -0700

Mark Nottingham wrote:
> useful, mature (with the nits below noted) and have immediate needs for 
> it (albeit in internal projects, but we'd prefer not to create something 
> proprietary, or to adopt still-not-stable technology).
> 

Experimental would likely be a good choice for this.

> 1) "If the at:deleted-entry element does not contain a when element, the 
> at: deleted-entry sharing the same atom:id as an entry MUST be ignored." 
> This is too strict; if a feed has an explicit ordering (e.g., a marker 
> giving semantics to lexical ordering), an implementation may determine 
> which has precedence by that ordering.
> 

Hmm.. I think it would make more sense to just require the when 
attribute.  You could still apply the lexical ordering stuff but there 
would be no ambiguity introduced in cases that don't use lexical ordering.

> elements, but MUST NOT contain more than one with the same ref attribute 
> value." ... but later ... "An Atom feed MAY contain atom:entry elements 
> and at:deleted-entry elements sharing the same atom:id value." The MUST 
> NOT is too strict; it makes coincidence of deletions a serialisation 
> problem (notice that it's specified in terms of feed documents, not feeds).
> 

Ok. I can change that to read "MUST NOT contain more than one with the 
same combination of ref and when attribute values".

> 3) Are extensions elements and attributes allowed?

Yes. I will make this more explicit.

> Why not, for example, allow deleted-entry to specify where an entry has 
> moved to (allowing a default to be set as a link relation, perhaps), and 
> let *that* feed define whether or not it's a trash bin?
> 

Hmmm... will have to give this some more thought.

> images of death are inappropriate; it may be good to find a more neutral 
> name for the spec (I don't have a problem with it; just occurred to me).
> 

Good point.  Will work on this.

- James

---

From: James M Snell <[email-masked]>
Date: Mon, 21 Apr 2008 13:26:09 -0700

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

  * Renamed the spec
  * Removed the "trash" link relation. This can be handled separately
  * Made the when attribute required
  * Changed the "Atom processors MUST ignore any at:deleted-entry
    elements..." to "Atom processors SHOULD ignore any at:deleted-entry
    elements..."
  * Explicitly allow for extension elements and attributes
  * Changed to: "An Atom feed MAY contain any number of at:deleted-entry
    elements, but MUST NOT contain more than one with the same
    combination of ref and when attribute values."
  * Updated the example

- James

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 21 Apr 2008 18:19:23 -0700

>   * Renamed the spec

I think you renamed the spec to avoid the "tombstone" reference.
However, the namespace URI still has "tombstone" in it; it should be
changed as well.

>   * Explicitly allow for extension elements and attributes

These changes are all nice improvements.

>     elements..." to "Atom processors SHOULD ignore any 
>     at:deleted-entry elements..."

Instead of saying what processors should do, I think it is better to
just specify what at:deleted-by means, and let processors do whatever
they want with that information. In other words, this statement should
just be removed. This requirement doesn't fit well with AtomPub because
it is specified in terms of atom:updated; an AtomPub client will want to
compare @when to app:edited, not atom:updated. 

>   * Changed to: "An Atom feed MAY contain any number of 
>     at:deleted-entry elements, but MUST NOT contain more than
>     one with the same combination of ref and when attribute values."

This is an unnecessary restriction that doesn't add any value, and it
could be removed without any ill effect. It would be silly to generate
such duplicates but doing so is benign.

Like I mentioned in previous discussions, at:by and at:comment should be
removed. If it is important to keep track of that information for
deletions, then it would also be just as important to keep track of that
information for creation and editions of entries. In other words, those
things would be better specified by a separate specification that
described their usage within both at:deleted-entry AND atom:entry.

I recommend replacing the definition of the "ref" attribute with the one
from RFC 4685:

   The "ref" attribute specifies the persistent, universally unique
   identifier of the [entry that was removed].  The value MUST
   conform to the same construction and comparison rules as the value of
   the atom:id element, as defined in Section 4.2.6 of [RFC4287].
   Though the IRI might use a dereferenceable scheme, processors MUST
   NOT assume that it can be dereferenced.

It is misleading to call the when attribute an atomDateConstruct in the
RelaxNG schema, because Atom date constructs are elements, not
attributes. Similarly, I'd prefer to see @when be defined as an Atom
date construct (like atom:updated), because then we can more easily use
date-processing code that has already been written for atom:updated and
app:edited, and reuse the same Atom<->JSON mapping rule for it.

Previously, we discussed at length whether at:deleted-entry elements
should be intermixed with atom:entry elements, or before all the
atom:entry elements, and how they should be ordered. I recommend adding
clarification about these issues: "at:deleted-entry elements MAY be
appear anywhere within an atom:feed element; they may appear before,
before, between, and/or after atom:entry elements. The order of
at:deleted-entry elements is not significant."

Regards,
Brian

---

From: James M Snell <[email-masked]>
Date: Mon, 21 Apr 2008 22:39:05 -0700

> However, the namespace URI still has "tombstone" in it; it should be

Yes, I'm planning to change that in the next rev. I wanted to make sure 
the new spec title was ok first.

> compare @when to app:edited, not atom:updated. 

Yeah, I considered this and am definitely open to it.  The main 
challenge is that if an entry with a newer atom:updated or app:edited 
appears in a feed with an at:deleted-entry specifying the same atom:id 
but a later when attribute value could still be viewed as having been 
deleted if a clear precedence is not established.  The correct 
interpretation is that the entry had been deleted but that it was 
brought back.  I'm not certain if we can accomplish that by just 
specifying the definition of at:deleted-entry.

> such duplicates but doing so is benign.

That shouldn't be a problem.  Whether this restriction is there or not 
implementors will still need to write code to detect duplicates so 
there's no impact to removing it.

> described their usage within both at:deleted-entry AND atom:entry.

I would have no problem with adding a kind of generic edit:comment 
element for deletes and updates.  Such notes are frequently found in 
systems such as wikis and would generally be quite useful.  Perhaps this 
specification could define them in the generic way you suggest?

>    NOT assume that it can be dereferenced.

+1.  That was actually on my list of todos but I missed it in this rev.

> app:edited, and reuse the same Atom<->JSON mapping rule for it.

Generally speaking, I agree.  The rationale for using an attribute here 
is to keep the serialization as compact as possible, which I think is 
important (tho others may not).

> at:deleted-entry elements is not significant."

RFC4287 requires that a feed's metadata elements come before the listing 
of entry elements. See section 4.1.1:

    The "atom:feed" element is the document (i.e., top-level) element of
    an Atom Feed Document, acting as a container for metadata and data
    associated with the feed.  Its element children consist of metadata
    elements followed by zero or more atom:entry child elements.

Therefore, the listing of at:deleted-entry elements MUST come before the 
listing of atom:entry elements.  The ordering the at:deleted-entry 
elements is not significant.

- James

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 22 Apr 2008 10:46:58 -0700

James M Snell wrote:
> Brian Smith wrote:
> > Instead of saying what processors should do, I think it
> > is better to just specify what at:deleted-by means, and
> > let processors do whatever they want with that
> > information. In other words, this statement should
> > just be removed. This requirement doesn't fit well with 
> > AtomPub because it is specified in terms of atom:updated;
> > an AtomPub client will want to compare @when to
> > app:edited, not atom:updated. 
> 
> Yeah, I considered this and am definitely open to it.
> The main  challenge is that if an entry with a newer
> atom:updated or app:edited appears in a feed with an
> at:deleted-entry specifying the same atom:id 
> but a later when attribute value could still be
> viewed as having been deleted if a clear precedence
> is not established. The correct interpretation is
> that the entry had been deleted but that it was 
> brought back.  I'm not certain if we can accomplish
> that by just specifying the definition of at:deleted-entry.

The case I care about is where I have deleted an entry from an AtomPub
collection and then un-delete it, so atom:updated shouldn't be updated,
but app:edited should be updated (atom:updated < deleted-entry/@when <
app:edited).

Why not have at:deleted-entry contain app:edited and/or atom:updated
instead of @when? Then say that timestamps should be compared using the
same date construct (compare only app:edited to app:edited, and
atom:updated to atom:updated). AtomPub collections would use app:edited
and most other collections would use atom:updated, just like they do
with atom:entry already today.

> > Like I mentioned in previous discussions, at:by and 
> > at:comment should be removed.

> systems such as wikis and would generally be quite useful.  
> Perhaps this specification could define them in the generic way
> you suggest?

I think there is more chance of succeeding if the specification is kept
as narrowly-focused as possible. 

> Therefore, the listing of at:deleted-entry elements MUST come 
> before the listing of atom:entry elements. 
> The ordering the at:deleted-entry elements is not significant.

That is fine with me. But, how about wrapping the at:deleted-entry
elements in a wrapper element:

<at:deleted-entries>
   <at:deleted-entry .../>
   <at:deleted-entry .../>
   <at:deleted-entry .../>
</at:deleted-entries>

This would allow a feed to indicate that it supports this feature, even
when no entries have been deleted:

    <at:deleted-entries/>

Knowing that the collection provides these tombstones would all clients
to skip crawling the collection to look for deleted entries.

Regards,
Brian

---

From: James M Snell <[email-masked]>
Date: Tue, 22 Apr 2008 14:07:20 -0700

Brian Smith wrote:
> [snip]

That would be entirely possible.  Will stew on that a bit.

> as narrowly-focused as possible. 

Agreed, which is why I originally was focusing on one specific, and
narrow issue.  :-)

> when no entries have been deleted:

I don't really see the value of this.  Either there are at:deleted-entry
elements or not.  If there aren't any, it really doesn't matter if the
feed supports the feature.

- James

---

From: Eric Scheid <[email-masked]>
Date: Wed, 23 Apr 2008 07:15:49 +1000

> with atom:entry already today.

+1 : elegant, simple

> to skip crawling the collection to look for deleted entries.

+1 also

e.