Brian Smith wrote:
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.
Yes, I'm planning to change that in the next rev. I wanted to make sure
the new spec title was ok first.
* 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.
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.
* 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.
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.
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 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?
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.
+1. That was actually on my list of todos but I missed it in this rev.
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.
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).
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."
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
Regards,
Brian
