Brian Smith wrote:
[snip]
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.
That would be entirely possible. Will stew on that a bit.
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.
Agreed, which is why I originally was focusing on one specific, and
narrow issue. :-)
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:
I don't really see the value of this. Either there are at:deleted-entry
elements or not. If there aren't any, it really doesn't matter if the
feed supports the feature.
- James
<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
