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/
