James M Snell wrote:
> Brian Smith wrote:
> > 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.
The case I care about is where I have deleted an entry from an AtomPub
collection and then un-delete it, so atom:updated shouldn't be updated,
but app:edited should be updated (atom:updated < deleted-entry/@when <
app:edited).
Why not have at:deleted-entry contain app:edited and/or atom:updated
instead of @when? Then say that timestamps should be compared using the
same date construct (compare only app:edited to app:edited, and
atom:updated to atom:updated). AtomPub collections would use app:edited
and most other collections would use atom:updated, just like they do
with atom:entry already today.
> > Like I mentioned in previous discussions, at:by and
> > at:comment should be removed.
> 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 think there is more chance of succeeding if the specification is kept
as narrowly-focused as possible.
> 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.
That is fine with me. But, how about wrapping the at:deleted-entry
elements in a wrapper element:
<at:deleted-entries>
<at:deleted-entry .../>
<at:deleted-entry .../>
<at:deleted-entry .../>
</at:deleted-entries>
This would allow a feed to indicate that it supports this feature, even
when no entries have been deleted:
<at:deleted-entries/>
Knowing that the collection provides these tombstones would all clients
to skip crawling the collection to look for deleted entries.
Regards,
Brian
