James M Snell wrote: > * 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.
> * Removed the "trash" link relation. This can be handled separately > * Made the when attribute required > * Explicitly allow for extension elements and attributes > * Updated the example These changes are all nice improvements. > * Changed the "Atom processors MUST ignore any at:deleted-entry > 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
