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
[email protected] - http://dret.net/netdret
UC Berkeley - School of Information (ISchool)
