On Mon, May 24, 2010 at 12:32 PM, Peter Keane <
pkeane@xxxxxxxxxxxxxxx> wrote:
>
> A bit farther into that thread:
>
>
http://www.imc.org/atom-syntax/mail-archive/msg20111.html
>
> --peter
>
> On Mon, May 24, 2010 at 2:28 PM, Peter Keane <
pkeane@xxxxxxxxxxxxxxx> wrote:
>> Hi All-
>>
>> For what it is worth, there was a fairly in-depth conversation about
>> tombstones back in Dec 2007. James Snell (and others) put forth
>> strong arguments against it just being another atom:entry (I was among
>> those, at the time, advocating for atom:entry, but I have come around
>> to the lighter option mainly for practical (not aesthetic) reasons).
>>
>> The thread begins here, and may be worth perusing (follow links to follow-ups):
>>
>>
http://www.imc.org/atom-syntax/mail-archive/msg20050.html
>>
>> --Peter
>>
>>
>> On Mon, May 24, 2010 at 2:08 PM, Bob Wyman <
bob@xxxxxxxx> wrote:
>>> Erik,
>>> I don't think we would have to go as far as changing the semantics of any
>>> standard atom elements. Rather, what I'm suggesting is that "delete" is
>>> really just a bit of an extension to what the existing replace means. In
>>> other words, if you understand the "delete" flag, however, it is encoded,
>>> you would do a delete, if not, then you would simply do a replace as per the
>>> existing spec. This would be properly backwards-compatible.
>>> I would, of course, regret breaking any early-adopter code. However, I
>>> suggest that there is a much larger population of long-ago-adopters who
>>> wrote Atom code potentially years ago and would, if deleted-entry became
>>> accepted, have to consider rewriting or at least modifying their code. One
>>> of the risks of being an early adopter is that things may change, however,
>>> people who wrote code to the published spec should be granted the right to
>>> expect that things will be more stable.
>>> The only downside I can see in extending the existing entry is that the
>>> resulting tombstones would be a bit less bit-efficient than desirable. (i.e.
>>> they would, in most cases, probably end up having empty required elements --
>>> such as atom:title.)
>>> bob wyman
>>> On Mon, May 24, 2010 at 2:28 PM, Erik Wilde <
dret@xxxxxxxxxxxx> wrote:
>>>>
>>>> hello.
>>>>
>>>> Bob Wyman wrote:
>>>>>
>>>>> The Tombstone draft is coming along nicely, however, I can't help
>>>>> wondering... Since it appears that a deleted-entry is so much like a normal
>>>>> entry, why isn't it just an extended atom:entry with some additional element
>>>>> or attribute flagging it as deleted?
>>>>
>>>> i think this is a great approach of looking at what "deletion" means, in a
>>>> way it's just another "update". however, there probably are two major
>>>> problems with this approach:
>>>>
>>>> - it is not backwards-compatible with prior versions of the draft, and it
>>>> seems that the draft already has seen some adoption. if the goal is to not
>>>> break these early implementations, then moving from deleted-entry to entry
>>>> is not an option, i am afraid.
>>>>
>>>> - atom disallows extensions to change the semantics of any standard atom
>>>> elements. whether additional metadata changing the semantics of an "updated"
>>>> entry to a "deleted" entry is such a change in semantics is a question of
>>>> perspective. one could say that "deleted" is different from "updated", or
>>>> one could say that it's just a special case.
>>>>
http://tools.ietf.org/html/rfc4287#section-4.2.15 just says that 'The
>>>> "atom:updated" element is a Date construct indicating the most recent
>>>> instant in time when an entry or feed was modified in a way the publisher
>>>> considers significant', which i think could be seen as covering the case of
>>>> deletion of an entry as well.
>>>>
>>>> personally, i think that having an entry/@deleted would be quite a bit
>>>> more elegant and consistent than having a deleted-entry (there is no
>>>> updated-entry, after all...), but that still does not solve the problem of
>>>> breaking early adopters' code. but for me, the most important thing is to
>>>> have something in feeds that covers the CRUD's D, so i am very glad to see
>>>> the tombstone draft moving along again, whatever it will end up defining.
>>>>
>>>> cheers,
>>>>
>>>> erik wilde tel:+1-510-6432253 - fax:+1-510-6425814
>>>>
dret@xxxxxxxxxxxx -
http://dret.net/netdret
>>>> UC Berkeley - School of Information (ISchool)
>>>>
>>>
>>>
>>
>
>