Subject: Explicit deletion of feed items?

From: "Arve Bersvendsen" <[email-masked]>
Date: Tue, 09 Nov 2004 12:16:08 +0100

I recently checked out my comment feeds in Bloglines, and noticed one  
problem:

The spam I take so much care to delete from my feeds remain visible in  
BlogLines, and probably at a heap of other sources. Instead of forcing  
aggregator services to implement spam filters, I'd rather just be able to  
tell them myself by indicating that an entry is revoked.

How could we do this?

<entry:revoked>2004-12-31T12:00:00Z</entry:revoked> ?

-- 
Arve Bersvendsen

http://www.bersvendsen.com/   /   http://www.virtuelvis.com/

---

From: Lance Lavandowska <[email-masked]>
Date: Tue, 9 Nov 2004 10:00:53 -0600

> <entry:revoked>2004-12-31T12:00:00Z</entry:revoked> ?

Are you suggesting this as a Service item?  Timestamp seems pretty
arbitraty.  Since each Entry has an ID wouldn't it be best to use
that?

Or are you suggesting that this is a timestamp property of the Entry
whereby clients could observe an item has been removed?  The issue of
removing published items has come up before with little resolution.

Lance

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Tue, 09 Nov 2004 17:20:02 +0100

> removing published items has come up before with little resolution.

Yes, I am suggesting "republishing" the entry with explicit information  
saying, "hey, look at me, I was revoked at this instant in time", as I  
believe this is the approach that'd require the least amount of change in  
existing tools, and thus can be implemented with the least amount of fuzz.

It could also provide us with a mechanism for stating why the entry was  
revoked/deleted.

<summary>
   ... { deleted, reason } ...
</summary>

where an extension namespace/vocabulary could be developed to allow for  
clients to use different strategies wrt what to actually do about the  
revocation - for instance: "Delete spam only".
-- 
Arve Bersvendsen

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 11 Nov 2004 16:27:25 +0100

On Tue, 09 Nov 2004 12:16:08 +0100, Arve Bersvendsen <[email-masked]>  
wrote:

> aggregator services to implement spam filters, I'd rather just be able  
> to tell them myself by indicating that an entry is revoked.
>
> How could we do this?
>

Other than the exact syntax (we probably shouldn't have an 'entry'  
namespace), I think this is a good idea. I think it belongs more in the  
protocol than the format, though.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Antone Roundy <[email-masked]>
Date: Thu, 11 Nov 2004 09:19:46 -0700

A short proposal.  The spec text makes it clear that "deleting" an 
entry might not remove it from the public record, so we won't be 
creating any illusions.  The reasons for not putting the deletion 
notice inside <entry>...which perhaps should be added to the 
rationale...are:

1) <entry> has required elements which would only serve to bloat a feed 
if included for deleted entries.
2) Deletion notices need not consume space in the "sliding window" on 
existing entries.
3) Separating deletions out of entries makes it possible to easily 
maintain a sliding window on deletions separate from the sliding window 
on existing entries (for example, the feed could contain the 15 most 
recent non-deleted entries, and the 15 most recent deletions.)

Rationale

Some systems cache and continue to display entries after they disappear 
from the "sliding window" into a feed. There is no way to tell the 
difference between an entry disappearing from the sliding window and an 
entry being deleted. In some circumstances, such as when deleting blog 
spam, it is highly desirable to have the entries deleted from external 
caches. This proposal specifies a light-weight method of explicitly 
indicating deletion of entries.

Proposal

Add the following as a child element of <feed> (not in <head>):

"atom:deletion" Element

The "atom:deletion" element indicates that an entry which previously 
appeared in the feed has been deleted. The content of atom:deletion is 
the atom:id of the deleted entry. atom:feed elements MAY contain zero 
or more atom:deletion elements. Publishing application MAY decline to 
publish atom:deletion elements. Consuming applications which cache 
entries MAY delete the indicated entries from their caches. If they do 
not, they SHOULD indicate to their consumers that the entry has been 
deleted by the publisher. Consuming applications MUST ignore 
atom:deletion elements whose content indicates the atom:id of an entry 
from a feed other than the containing feed.

---

From: Lance Lavandowska <[email-masked]>
Date: Thu, 11 Nov 2004 10:40:25 -0600

I thought the whole point was to indicate to feed readers that a
particular entry was revoked/removed/deleted/whatever.  Hence this
discussion should stay in 'syntax' unless I misunderstand the scope of
'protocol'.

Lance

---

From: Danny Ayers <[email-masked]>
Date: Thu, 11 Nov 2004 17:50:29 +0100

The Pace looks good, but just a thought - back in the
PaceOptionalAlternateLink discussion, Sam asked:

>   Is there a use case for syndication where the content is neither
> included nor referenced?

Empty content and summary could be used to signify that an entry was
no more. I honestly don't know if this would be a good idea, usually
it seems to be better to be as explicit as possible about such things.
But it would mean one less element to contend with.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: James Aylett <[email-masked]>
Date: Thu, 11 Nov 2004 17:27:19 +0000

> But it would mean one less element to contend with.

Please, let's make it explicit. Even if there's no good use for empty
content and summary, it's better to leave it as weird than try to make
it do work.

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  [email-masked]                               uncertaintydivision.org

---

From: Robert Sayre <[email-masked]>
Date: Thu, 11 Nov 2004 12:41:07 -0500

> content and summary, it's better to leave it as weird than try to make

What is meant by deleted?

Here's the thread from last time discussed this:
http://www.imc.org/atom-syntax/mail-archive/msg08585.html

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Thu, 11 Nov 2004 11:08:25 -0700

From that message:
> A delete event fits within the rubric of a full versioning publishing
> process, and sits alongside other events like retracted, superceded,
> withdrawn, etc.

Do we need to get into those details?  Perhaps it would be sufficient 
to do it like this in the core:

	<deleted>
		<id>urn:blah/blah/blah</id>
	</deleted>

so that people who care about additional information could do something 
like this:

	<deleted>
		<id>urn:blah/blah/blah</id>
		<foo:reason code="superceded">This entry has been superceded by one 
based on better intelligence.</foo:reason>
	</deleted>

or

	<deleted entry="urn:blah/blah/blah" />

and

	<deleted entry="urn:blah/blah/blah">
		<foo:reason code="superceded">This entry has been superceded by one 
based on better intelligence.</foo:reason>
	</deleted>

My uninformed opinion is that most implementations would be 
sufficiently served by knowing simply that the publisher has deleted a 
particular entry, and that keeping it as lightweight as possible would 
be preferable.

---

From: Walter Underwood <[email-masked]>
Date: Thu, 11 Nov 2004 10:23:06 -0800

--On Thursday, November 11, 2004 5:50 PM +0100 Danny Ayers <[email-masked]> wrote:
> no more. 

Let's not do that, even though it would sorta work.

In our HTTP spidering, we do see documents with no content,
but we have different log messages for "200, no title or summary"
and "404". Documents like this would be binaries served as text/plain
or PDFs which are scanned images with no metadata. Quite common,
really, and entries representing those would be empty, too.

We are sure to see software problems where entries are generated
with no content, and I'd really like to flag those as what they
are instead of mistakenly deleting lots of stuff.

Should we add a requirement that there must be content in at 
least one of the entry fields? I think that would be a good
idea. Otherwise, clients are required to store null entries.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Danny Ayers <[email-masked]>
Date: Thu, 11 Nov 2004 22:47:27 +0100

> idea. Otherwise, clients are required to store null entries.

Yep, that makes sense - nulls are probably unmanageable, so absence of
content (probably including "") should be treated as an error
condition. A resource with a deleted attribute of "true" on the other
hand (with any content, probably including "") should be ok. The
human-level semantics would be in the same spirit as atom:updated,
i.e. the publisher says to remove any representations of this resource
from sight (URIs are for ever, not just for Christmas).

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Graham <[email-masked]>
Date: Thu, 11 Nov 2004 22:46:21 +0000

> from sight (URIs are for ever, not just for Christmas).

I think the semantic should be that the publisher is giving an 
explanation why an entry is no longer in the feed. I think the opposite 
tag would be even more useful "this entry no longer in the feed because 
it got old".

Anyway, I think this is definitely the kind of problem Atom should be 
solving.

Graham

---

From: Tim Bray <[email-masked]>
Date: Thu, 11 Nov 2004 15:12:18 -0800

On Nov 11, 2004, at 1:47 PM, Danny Ayers wrote:

> Yep, that makes sense

Someone write a Pace.  It only takes a couple of minutes. -Tim

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 13 Nov 2004 01:49:37 +0100

> discussion should stay in 'syntax' unless I misunderstand the scope of

You wrap an action in XML. I think actions belong in the protocol. And  
yes, I think 'published' (or 'issued') and 'modified' are actions as well,  
and have said on several occasions that I think they belong with the  
protocol, not the format.

---

From: Danny Ayers <[email-masked]>
Date: Sat, 13 Nov 2004 11:25:44 +0100

> protocol, not the format.

I see your point, but tend to disagree. "modified" - yes, there would
be a strong case for that being in protocol, if it's aimed right down
at machine-bits level. But "updated" is up with the content as
top-level publisher/reader-oriented information. Similarly "deleted"
(or whatever) in the form it has been proposed isn't really saying
some piece of data has necessarily changed, rather that the publisher
wishes to provide some addtional information about that data (it's no
longer wanted). It's very much up to the client, likely in the UI on
how to respond to that piece of information, as in the case of
"updated".

We could push "deleted" down to the protocol level, and have it
correspond to HTTP DELETE at the other end of the pipe. I could be
wrong, but I don't think that's what is required. I think what's
needed is more "remove from view" than "remove every trace". An
attribute of the content, rather than the total disappearance of the
content (most of the time it probably will be disappeared, but that's
up to the implementation). It also sidesteps any ideas of a resource
no longer existing, rather than just a particular representation.

Cheers,
Danny.
-- 

http://dannyayers.com

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 14 Nov 2004 16:02:10 +0100

On Sat, 13 Nov 2004 11:25:44 +0100, Danny Ayers <[email-masked]>  
wrote:

> at machine-bits level.

Yup.

> But "updated" is up with the content as top-level publisher/reader-
> oriented information.

That's why I don't think 'updated' should be a part of the protocol  
either. It belongs in the format. Most of the format is authorative  
information, but we mix in some non-authorative more objective  
machine-readable stuff that I feel belongs in and for the protocol.

> Similarly "deleted" (or whatever) in the form it has been proposed
> isn't really saying some piece of data has necessarily changed, rather
> that the publisher wishes to provide some addtional information about
> that data (it's no longer wanted).

The action of deletion is done by the author. So is the action of  
modification. Still I feel that this is an action provided through an  
interface that should be provided automatically to subscribers, maybe  
through a <deleted> element.

> It's very much up to the client, likely in the UI on how to respond
> to that piece of information, as in the case of "updated".

'updated' is probably something you'd like to show the user. 'deleted'  
might also be shown, but that goes for 'modified' as well. What you choose  
to show and hide from the user is implementation-specific, but how the  
information is provided should not be.

Authorative dates should be picked explicitly by the user (such as  
'updated'), while 'modified' and 'deleted' are dates that are provided  
through an action by the user; he has either modified or deleted the entry.

> wrong, but I don't think that's what is required.

Support for the HTTP DELETE method is of course not required to be able to  
provide an exact 'deleted' date, but an action corresponding to HTTP's  
DELETE, need to be supported. There has to be a 'delete' link or similar  
in the interface that the user can press. Still, very  
implementation-specific, but deleting an entry is not up for much  
interpretation. Either you delete it or you don't.

Whether the action of 'delete' puts your entry in a recycle bin, in an  
«unpublished» state or whatever, doesn't matter. What matters is the  
action and what you want to tell your subscribers.

> I think what's needed is more "remove from view" than "remove every
> trace".

Yes. I don't disagree with that.