Re: PaceAllowDuplicateIDs

[Graham <dtcd@xxxxxxx>]

On 5 May 2005, at 11:36 am, Henry Story wrote:

> > Tim, model this as a blog first. Is it:
> > a) One entry that's being updated?
> > b) Hourly new postings with the latest price?
>
> Given that the ids are the same it is now clear that we have  
> situation a)

I said "first", before we decide what ids we should use. If created  
as a blog, Tim's stock quotes would make most sense (to me) posted as  
hourly new entries. Ergo, they should each have different ids. Again,  
atom:id is not a category system.

> Either the change they made is "significant" or it is not. If it is  
> a significant change then
> by not changing the atom:updated field the user will have done  
> something other than what he thought
> he was doing. For by not changing the date he is allowing receiving  
> software to decide by themselves
> whether they wish to keep or drop the change. If it is not a  
> significant change, then the receiving
> software won't be doing anything problematic by either dropping the  
> later version received or keeping it.

atom:updated is used by the publisher to show what they consider a  
significant change. The user, on the other hand, wants to see the  
latest version, reliably, even if the publisher disagrees that the  
change was significant. This is the core problem with Tim's proposal.  
There is no way to create an aggregator that works in the way the  
user expects.

I am lying down in the road here, as Tim would say.

> Well that seems like a very complicated way of solving a problem  
> where allowing entries with duplicate ids in a feed document from  
> the start would be much simpler. If you are going to
> allow <archive> feeds to keep duplicates then why not just allow   
> <feeds> and be done with it?

Because feeds are feeds and archives are archives? They have  
different audiences and different uses and different requirements.

Graham