2006/1/27, James Holderness [EMAIL PROTECTED]:
James M Snell wrote:
One question: what's a reasonable length of time to keep the deleted-entry
elements in a feed? We don't really want to keep those things around
forever.
Actually I think I probably would recommend keeping them forever.
Thomas Broyer wrote:
Anyway, that's my preference. Not necessarily a SHOULD recommendation - just
my personal opinion.
+1
Maybe at:by and at:comment could be used in pub:control in the APP as well
Hmmh... hadn't thought of that. Edit comments are common and
pub:control would be the
Ok, so this makes sense and I've received other input that the id and
when attributes should be elements instead. Given this, perhaps the
deleted-entry should look something like this instead:
at:deleted-entry
atom:idtag:example.org,2006:someentry/atom:id--required--
2006/1/27, James M Snell [EMAIL PROTECTED]:
at:deleted-entry
atom:idtag:example.org,2006:someentry/atom:id--required--
atom:updated2005-01-27T12:12:12Z/atom:updated--required--
atom:authoratom:nameJames/atom:name/atom:author--optional--
atom:summarycomment
Thomas Broyer wrote:
But now that you're having something looking more and more like an
atom:entry, how about just adding an at:deleted to an atom:entry? and
integrating the at:by and at:comment inside the pub:control in a more
generic way to provide edit comments? (issue: pub:control is
James M Snell wrote:
Which leaves us with...
del:deleted-entry
atom:id.../atom:id
del:when.../del:when
del:by.../del:by
del:comment.../del:comment
/del:deleted-entry
I think I've probably mentioned this before, but FWIW I preferred the id and
date as attributes since that's easier
I tend to prefer attributes also, but the elements are structurally and
stylistically more in tune with Atom. And given the by and comment
elements (which I know you don't particularly have a need for), having
id and when as elements doesn't add any significant level of additional
parsing
Still in experimental stages. Cleaned up a bit and removed the
archived-entry element. Comments requested... particularly from
potential client implementors...
http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-01.txt
- James
James M Snell wrote:
Still in experimental stages. Cleaned up a bit and removed the
archived-entry element. Comments requested... particularly from potential
client implementors...
http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-01.txt
I'm glad you've brought this up -
The by and comment elements are largely speculative right now. Now sure
if they'll stay in there or not.
And yes, it would likely be a good idea for Atom processors to ignore
deleted-entry elements whose date is older than the entries updated
date. Also, just because an entry was deleted
James M Snell wrote:
One question: what's a reasonable length of time to keep the deleted-entry
elements in a feed? We don't really want to keep those things around
forever.
Actually I think I probably would recommend keeping them forever. Just treat
them like any other entry. If they fall
11 matches
Mail list logo
