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
