On 5 May 2005, at 19:23, Graham wrote:
On 5 May 2005, at 5:38 pm, Eric Scheid wrote:Many wiki's offer options in displaying their change log with either most
recent changes only, or all changes. Both models are commonly supported
because some people want to see notifications of all changes, while others
just want to see the most recent change. That is part of wiki culture, all
the way back to ward's wiki.
OK that makes sense. I still think it's the wrong way to model a change log as a feed.
Cool. Rational argument does sometimes work :-)
My other two criticisms still stand:
What was wrong with the arguments I gave?
"atom:updated is used by the publisher to show what they consider a significant change. The user, on the other hand, probably 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 think this is relatively simple. If the publisher publishes a feed document with two entries containing the same id and the same atom:updated timestamp then he is claiming that there are no significant changes between them. In fact the same is true if he publishes those two entries in two different feed documents. So there really is no problem here that is particular to PaceAllowDuplicateIDs.
If the feed reader wants reliability he can't get more reliability by making the spec tighter
than the feed producer is able to give. If the feed producer is unreliable, then nothing in the
spec can change that.
The feed producer must understand that by creating feeds where the above described situation is
true will lead to erratic behavior. If there is a significant difference between those entries
then he had better change the time stamp. Otherwise his unreliable behavior will create unreliable
effects. Nothing new here.
"Finally, at pubsub, what happens when they download an entry from one feed, then the user edits it, but doesn't modify atom:updated, then they download the new entry from a second feed associated with the site? Different content, identical atom:ids, identical atom:updated => Invalid feed. They're not in any better position than they were before. This doesn't even solve the problem it's meant to."
I imagine this is simple, but I will leave the full details for Bob to answer. My guess is that
if Bob comes across the above situation, then he will be confronted by a situation where he has
according to the publisher two entries that are not significantly different. He can therefore choose
between them randomly, and just add one of them. The publisher after all thinks that there are
no significant differences between them. If the initial publisher thought that there were significant differences between these entries, then he should have given them different time
stamps.
Basically, atom:updated doesn't properly differentiate versions, and the way atom:updated is being used by the proposal doesn't gel with the actual spec of the element.
I think the above argument shows that there is in fact nothing wrong with atom:updated.
We just have to think in terms of interoperability and not in terms of Platonic forms.
Henry Story http://bblfish.net/blog/
