On 20 Feb 2005, at 1:27 am, Eric Scheid wrote:
hmmm ... looking back in the archives I see you were opposed to
atom:modified, you couldn't see any use case where you would want the entry
instances to clearly indicate which is more recent. Hashes won't help you
here.
Yes, if you want multiple versions you need atom:modified. I oppose both.
A paradigm that fails completely once a reader starts traversing @rel="prev"
Not if the url in the prev is properly thought through; ie instead of asking for "page 2" the uri query asks for "entried before n", where n is the oldest entry number in the page before.
Anyway, rel="prev" doesn't exist last time I checked.
or they have a planet aggregator in their subscriptions which has fallen behind due to ping lags.
Are there really aggregators naïve enough to take an entry with the same id from one feed and paste over the last retrieved entry from another? There are far more problems with that before you start worrying about what is the latest entry.
"the newest version" is something which should be publisher controlled, not
left to the variable circumstances of protocol happenstance and
idiosyncratic personal subscription lists.
or "picking randomly", as you suggested not 2 emails ago.
OK, lets look at feed readers that don't then [etc]
This is where Eric dictates how other people's feed readers should work to fit the flaws in his preferred proposition.
[1] do you know of any publishing software which currently emits feeds with
multiple instances of entries? I can't think of any.
None. That's why it should be explicitly barred, since no software is expecting it.
Graham
