Re: Atom Tombstones Draft
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. Just treat them like any other entry. If they fall out the bottom of the feed window that's ok, but if the server implements next/previous links to history feeds, then the tombstone could still be found in the archives. […] 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 -- Thomas Broyer
Re: Atom Tombstones Draft
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 logical place to put 'em. I'm not so sure that putting at:by in pub:control gives us anything useful tho. Will have to stew on that one. - James
Re: Atom Tombstones Draft
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-- atom:updated2005-01-27T12:12:12Z/atom:updated--required-- atom:authoratom:nameJames/atom:name/atom:author--optional-- atom:summarycomment spam/atom:summary--optional-- /at:deleted-entry In a feed, these would appear mixed in with atom:entry elements: feed ... entry.../entry entry.../entry at:deleted-entry idtag:example.org,2006:someentry/id updated2006-01-27T12:12:12Z/updated /at:deleted-entry entry.../entry ... /feed Is this better? - James James Holderness wrote: 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 out the bottom of the feed window that's ok, but if the server implements next/previous links to history feeds, then the tombstone could still be found in the archives. Anything else is just guessing. You really can't tell how regularly a user might update from your feed. Now if you don't support history then it's just tough luck - the fact that they've missed out on entries is more of a problem than missing out on deletions. However, if you do support history, it would be a shame not to support tombstones in that history as well. Anyway, that's my preference. Not necessarily a SHOULD recommendation - just my personal opinion. Regards James
Re: Atom Tombstones Draft
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 spam/atom:summary--optional-- /at:deleted-entry […] Is this better? No, because it's not clear whether atom:author and atom:summary were the one of the deleted entry or relative to the deletion. at:deleted-entry atom:idtag:example.org,2006:someentry/atom:id atom:updated2005-01-27T12:12:12Z/atom:updated at:byatom:nameJames/atom:name/at:by at:commentcomment spam/at:comment /at:deleted-entry Some will probably have the same question about the atom:updated: is it the date when the entry was deleted or the atom:updated value before deletion? Some will probably ask whether then atom:id is the one of the at:deleted-entry… 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 specific to the APP) !-- before deletion, in APP context -- atom:entry atom:title…/atom:title atom:idtag:example.org,2006:someentry/atom:id atom:summary…/atom:summary atom:updated2006-01-25T10:10:10Z/atom:updated atom:link rel=edit href=… / /atom:entry !-- after deletion -- atom:entry atom:title…/atom:title atom:idtag:example.org,2006:someentry/atom:id atom:summary…/atom:summary !-- the atom:updated is the date of the deletion, as it's unlikely that the entry will change after that -- atom:updated2006-01-27T12:12:12Z/atom:updated del:deleted del:byatom:nameThomas/atom:name/del:by del:commentcomment spam/del:comment /del:deleted !-- the [EMAIL PROTECTED]edit] has disappeared -- /atom:entry The only drawback –a priori– of this solution is that it means updating the atom:updated value of the atom:entry, which will bring the entry to the attention of the user if the reader doesn't support the del:* extension… not really what was intended isn't it? (however, it's arguable: should a deletion be silent? how about adding a del:when in the del:deleted? the atom:updated would then continue to serve its role: whether to bring the entry to the user's attention) Just thinking out loud… -- Thomas Broyer
Re: Atom Tombstones Draft
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 specific to the APP) I knew this would come up ;-) !-- before deletion, in APP context -- atom:entry atom:title…/atom:title atom:idtag:example.org,2006:someentry/atom:id atom:summary…/atom:summary atom:updated2006-01-25T10:10:10Z/atom:updated atom:link rel=edit href=… / /atom:entry The challenge with this is that after the item is deleted, it's quite likely that you won't have enough data still hanging around to meet the minimum content requirements of an atom entry. Also, given that readers that don't understand the tombstone extension are required to ignore it, all they'd likely end up seeing is just another Atom entry, potentially with empty content, an empty title, no author, a link that doesn't point anywhere, etc. If I subscribe to the feed after entries have been deleted, I'll end up with a bunch of meaningless, contentless entries. That sucks. The only drawback –a priori– of this solution is that it means updating the atom:updated value of the atom:entry, which will bring the entry to the attention of the user if the reader doesn't support the del:* extension… not really what was intended isn't it? (however, heh... note to self: read the whole note before starting the response. ;-) it's arguable: should a deletion be silent? how about adding a del:when in the del:deleted? the atom:updated would then continue to serve its role: whether to bring the entry to the user's attention) Personally I'd prefer that the atom:entry would just go away completely... and replaced with a deleted-entry. That way, they'd be invisible to dumb clients and smart clients could just do the right thing. Everything else makes sense (e.g. keeping by, when and comment in the tombstone namespace). The id element would always be the id of the entry that was deleted. 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 - James
Re: Atom Tombstones Draft
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 for me to parse. More compact too. I don't know which is technically more correct, but if you can't decide one way or the other and you're looking for votes, you now know my preference. Regards James
Re: Atom Tombstones Draft
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 difficulty. Either way, your preference is noted. Let's see how others weigh in on it and see how it goes. James Holderness wrote: 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 for me to parse. More compact too. I don't know which is technically more correct, but if you can't decide one way or the other and you're looking for votes, you now know my preference. Regards James
Atom Tombstones Draft
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
Re: Atom Tombstones Draft
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 - I was just thinking about it last night. Technically it looks great to me. I'm only interested in simply deleting any tombstones I receive, so all I really need is the id attribute. I understand the need for the by and comments elements - just saying I'm unlikely to notice any problems with them. As for the date, I'm unsure whether an Atom processor should be ignoring tombstones that are dated older than the current updated date on an element. If so, is that something worth mentioning in the spec? Other editorial nits: In the introduction, explicitly is used twice in the same sentence and you have a split infinitive - suggest nuking the first usage. Near the end of section 3, you use the expression deletion operation. I don't know if it's just me, but that sounds wrong. Maybe delete operation, just deletion, or even removal of the entry (which is what you use later in section 5). Regards James
Re: Atom Tombstones Draft
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 once, doesn't mean it can't show back up again later... it should just be treated as a new entry if it does. 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. James Holderness wrote: 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 - I was just thinking about it last night. Technically it looks great to me. I'm only interested in simply deleting any tombstones I receive, so all I really need is the id attribute. I understand the need for the by and comments elements - just saying I'm unlikely to notice any problems with them. As for the date, I'm unsure whether an Atom processor should be ignoring tombstones that are dated older than the current updated date on an element. If so, is that something worth mentioning in the spec? Other editorial nits: In the introduction, explicitly is used twice in the same sentence and you have a split infinitive - suggest nuking the first usage. Near the end of section 3, you use the expression deletion operation. I don't know if it's just me, but that sounds wrong. Maybe delete operation, just deletion, or even removal of the entry (which is what you use later in section 5). Regards James
Re: Atom Tombstones Draft
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 out the bottom of the feed window that's ok, but if the server implements next/previous links to history feeds, then the tombstone could still be found in the archives. Anything else is just guessing. You really can't tell how regularly a user might update from your feed. Now if you don't support history then it's just tough luck - the fact that they've missed out on entries is more of a problem than missing out on deletions. However, if you do support history, it would be a shame not to support tombstones in that history as well. Anyway, that's my preference. Not necessarily a SHOULD recommendation - just my personal opinion. Regards James
