Re: Atom Tombstones Draft

2006-01-27 Thread Thomas Broyer

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

2006-01-27 Thread James M Snell



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

2006-01-27 Thread James M Snell


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

2006-01-27 Thread James M Snell


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-01-27 Thread Thomas Broyer

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

2006-01-27 Thread James M Snell


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

2006-01-27 Thread James M Snell


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

2006-01-27 Thread James M Snell




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

2006-01-27 Thread James Holderness


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

2006-01-27 Thread James M Snell


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