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: An Atom syntax based transformation service
Here's what I'd expect: # Post (X)HTML or Atom (entries or feeds) directly POST /service HTTP/1.1 Host: ... Content-Type: application/xhtml+xml Content-Length: ... # Response with 200 OK and transformed content HTTP/1.1 200 OK Date: ... Content-Type: application/xhtml+xml Content-Length: ... Or, if the content is URL addressable.. # Get with a querystring GET /service?url={url of content} HTTP/1.1 Host: ... # Response with 200 OK and transformed content HTTP/1.1 200 OK Date: ... Content-Type: application/xhtml+xml Content-Length: Obviously the GET approach is optimum. - James John Panzer wrote: I have a use case where I think the Atom syntax works well, but it's not an APP scenario. I want to provide a web service which renders arbitrary (X)HTML content 'safe' for rendering on web pages. This would basically mean applying an element/attribute whitelist filter and also transforming content into XHTML. It might also provide optional rules for dealing with titles (e.g., transforming into a plain text approximation) that would be useful for clients. The motivation here is to allow things like third party comments in web pages without allowing cross-site scripting attacks or just bad markup that might destroy the page. The reasoning for providing a web service is that this kind of thing is only an approximation and requires constant maintenance and updates as new attacks appear. My first thought is to simply provide a custom endpoint which accepts POSTs of Atom Entries (or even Atom Feeds) and returns the transformed Atom content with an appropriate HTTP return status. (What success return status would be most appropriate for this type of transformation service?) This part just seems too easy -- is there anything else I'm missing? Thanks, John
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
Feed License Draft
Just an editorial clean up of the draft. No significant technical changes. This draft should now be considered complete. I've stumbled across a number of feeds in the wild using the extension and know of at least one blog vendor and one feed reader with plans to implement. http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-05.txt - James
Feed Rank Extension
Editorial and minor technical updates. Should still be considered primarily experimental but stable. There will be no further updates unless necessary for interop or implementation. I know of at least one vendor with plans to implement. http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-index-05.txt - James
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