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
Mark Nottingham wrote:
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/
