Re: tombstones, I'll just throw in a mention if the OAI-ORE work (Open
Archives Initiative Object Reuse and Exchange -
http://www.openarchives.org/ore/0.1/atom-implementation) which figures to
be very important in archiving/preservation, etc. and serializes a
"Resource Map" (named graphs that represent aggregations of Web Resources)
and serializes them using Atom.
The issue of tombstones will be big and the previous discussion around
"soft-deletes" (deletions that can be resurrected or perhaps used in
various client-determined ways) will be a significant use case. I feel
like Joe Gregorio's suggestion of two feeds
(http://www.mail-archive.com/[email protected]/msg01092.html) feels
like the best solution for this case. (since those deletes really ARE of
type atom:entry -- a new type does not smell quite right).
And why can't atom:category be used to indicate that an entry has been
deleted? (In fact, perhaps a few different categories for the different
kinds of "deleted").
-peter keane
James M Snell wrote:
Bill de hOra wrote:
[snip]
1: If it doesn't have a permalink (or a link at all), it's not on the
web; in all seriousness, why do we care about it?
Whether the thing has a permalink or not is irrelevant. We're talking
about having a mechanism of indicating when an entry is no longer part
of a collection or a feed. It could be that the entry still exists in
some form or other somewhere else, but how do I know that the thing is
no longer part of a specific feed?
It's not in the feed anymore - but first perhaps define "feed".
2: why does it matter, the difference between falling off the bottom and
being deleted?
Define "falling off". If the feed is paged, does "falling off" mean
we'll find the entry on the next or previous page? What if the feed
only shows the 100 most recent items? What should I do with my local
copy of the entry if suddenly the entry no longer appears in the feed?
There is a significant difference between falling off and being deleted.
I didn't say there wasn't, I asked it be explained why the difference matters
in this case, to the extent we need a new type and new markup.
cheers
Bill
