I'll certainly defer to the judgement to folks who have a better
understanding of the nuances of Atom, but my perspective is that of a
librarian/programmer interesting in Atom in the broadest and most
non-blogging-oriented domains (as an aside I think the strength of the
spec comes from a set of well-understood uses cases in a particular domain
-- I just want to see how effective it might be outside of that domain).
Feed-level elements are of two types: metadata about the feed, and items
in a "set" of things. Throwing a new type in the mix is really a huge
change -- if it's about the feed, OK (but clearly a tombstone is an entity
of it's own and not metadata about the feed), otherwise you are creating a
second "set" and there goes the beauty of Atom (and up goes the cognitive
load -- at least at the conceptual level). Perhaps it comes down to: are
tombstones a significant resource (I say yes)? And if so, they need to
have a URI. Also, a new type seems to create a tighter coupling with the
client than is ideal -- why must I (the client or client implementor) need
to think about a new type? I'd much prefer an atom:category element that
flagged an entry as "deleted" with an expectation that it'd hang around
for some period of time (soft-delete) and at some indeterminate point fall
off the feed (hard-deleted) if/when the feed publisher so chooses. It
just seems more natural to deal with a deleted entry like that -- a new
type seems to me to presuppose an understanding of the possible use cases
which is simply impossible at this point.
--peter keane
On Tue, 1 Jan 2008, James M Snell wrote:
+1. I've asked several times why using atom:entry would be better than
x:deleted and I have yet to see a clear, coherent argument.
- James
Mark Nottingham wrote:
I still don't understand the pushback that people have against a new
feed-level element not "smelling right." Atom explicitly allows
extensions there.
Cheers,
On 02/01/2008, at 1:52 PM, Peter Keane wrote:
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
--
Mark Nottingham http://www.mnot.net/
