In an ideal world, yes. However, many aggregators I've seen will
highlight or otherwise draw attention to entries that have changed,
using various metrics for 'change' -- including, I suspect, the
introduction of new child elements. YMMV, of course.
Has anyone done a survey of how aggregators behave under different
conditions like this?
Cheers,
On 06/12/2007, at 5:58 PM, Steven Lees wrote:
The "spam-shows-up-more-than-once" idea is not correct, regardless
of which tombstone mechanism you use. Even if you hand tombstoned
entries to a non-tombstone client, the entry only shows up once.
If, as we're recommending, you only give tombstones to clients that
ask for them, then there's no entry at all.
Example: we have a feed with two entries. There are two feed reader
clients, neither of which know about tombstones. Client A
requests the
feed and sees both entries.
<snip>
Client A gets the feed and still sees two entries, one of which is
marked as being updated.
Client B comes along and requests the feed and see two entries,
both of
which are new to it but one of which doesn't actually exist. Why
should
Client B have to see that entry at all? If the entry was deleted, it
shouldn't be in the feed.
Agreed. But with the <x:deleted> element, you're still passing
unnecessary info to the client. If you go and delete ALL of the
entries from the feed, then the client receives a feed with nothing
but tombstones, which it didn't want in the first place. In that
case, asking the client to opt-in seems like a pretty good idea.
Now use the separate tombstone element,
<feed>
...
<x:deleted>
<id>tag:example.org,2007:1</id>
</x:deleted>
<entry>
<id>tag:example.org,2007:2</id>
...
</entry>
</feed>
Client A continues to operate as it always has when an entry that was
once in the feed suddenly isn't and Client B never has to see the
deleted entry at all. That makes a whole lot more sense to me.
Now, Steven indicates that their implementation will not include the
tombstone by default. Clients that want tombstones would have to ask
for
them explicitly. While that would solve the problem, using the
tombstone element would avoid the need to have that kind of
negotiation
mechanism at all.
Again, the mechanism seems pretty simple to me, and it has the
benefit of not passing any tombstones to a client that won't
understand them anyway.
Steven
--
Mark Nottingham http://www.mnot.net/
