Peter Keane wrote:
> [snip]
> 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
I disagree. Feeds already contain several sets of things... entries,
authors, contributors, links, and categories. Adding a new set of
things is not a "huge" change by any stretch of the imagination.
> 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
Tombstones are not resources. An entry in a trash folder may be a
resource, but a tombstone is just a flag that indicates that a
particular entry is no longer part of a logical collection.
> 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.
>
The key challenge with these kinds of views is that there are existing
applications and use cases out there that simply do not share this point
of view.
- James
> --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/
>>>
>>>
>>
>
