Re: a methodical approach to defining what date elements we need

[Graham <dtcd@xxxxxxx>]

On 13 Jul 2004, at 6:09 pm, Robert Sayre wrote:

> > Consider that a typical aggregator polls for data.  If you replace an
> > entry twice, and the aggregator missed the first one, then it has an
> > incomplete history to reconcile.
>
> But if he just tweaks a date field each update, the consumer won't 
> even know
> it missed anything.

I think you misunderstand. An aggregator downloads and caches entry A. 
While the user is offline, A is superceded by B and then B is 
superceded by C. The user goes back online and downloads C, which says 
it supercedes B, which the aggregator has never seen. The aggregator 
therefore has no way of knowing and/or conveying to the user that C is 
a later version of A. This is hardly an edge case or a contrived 
scenario.

Compare this with having atom:id be static for all versions of the same 
entry, and the problem never comes up. For the supercedes approach to 
match this robustness, you must either:
a) Include the ids of all previous revisions in every entry (which 
won't scale)
b) Include the id of the original entry in all revisions (which, if you 
swap some element names, is exactly the same as keeping the id static)

If you want to add version ids to atom, I'd be happy for you. Just make 
sure atom:id never changes.

Graham

Attachment: smime.p7s
Description: S/MIME cryptographic signature