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).
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.
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).
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.
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?
Hmmm... will have to give this some more thought.
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).
Good point. Will work on this.
- James
Cheers,
--
Mark Nottingham http://www.mnot.net/
