> Bottom line: we should avoid over-overloading atom:entry. Regardless of > the specific solution required, some invention is required and clients > will have to take specific actions to support tombstones, so we are not > saving anyone any work by reusing atom:entry for this and we run the > risk of confusing clients. The x:deleted tombstone element avoids that > risk entirely, which for me, makes it the superior solution.
The x:deleted proposal is overloading atom:feed more inapropriately than the sx:deleted proposal overloads atom:entry. Atom is a great syntax for communicating a single stream of entries belonging to a feed. It is not a suitable syntax for communicating *two* streams of entries and tombstones belonging to a feed. It is the wrong shape. Feed metadata elements aren't a good place to embed a stream of tombstones. Intermediaries such as feedburner, yahoo pipes, and the windows feed platform do not support agregating <x:deleted> feed metadata elements as they do entries. The practical life-cycle and semantics of a top-level feed element aren't appropriate for communicating a change in state of an entry. I think giving up on the feed/entry model is a premature optimization. If there are practical difficulties with combining tombstones and normal entries in a feed, then Joe's proposal of using separate feeds sounds like a better idea. -- Dave
