On 20/2/05 1:47 PM, "Graham" <[EMAIL PROTECTED]> wrote: > 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. > atom:modified also helps in distinguishing multiple instances found in separate feed documents.
You oppose atom:modified, and yet you insist on kludging a hack for identifying which of two entries is the most recent. A hack which isn't even mentioned in the spec, so gawd help software developers all arriving at the same hacky solution to the problem. You opposed it because you couldn't foresee any use case for it, and now you have a use case for it but you say that that use case should be banned because you opposed atom:modified. I forget: is this the circular reasoning logical fallacy, or the begging the question fallacy? >> 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. Where are these special semantics codified into a specification? Also, define "oldest". Is this the one with the oldest atom:updated, even though you earlier (and rightly) dissed that because it was "that the author considered significant". Or is oldest defined by atom:published, which as you might recall is an *optional* element for atom:entry. Also, define "number" in "entry number". Entries are not numbered, they have id's, and while it's often easy to use an incrementing serial that is not always the case. > Anyway, rel="prev" doesn't exist last time I checked. This does: @rel="http://www.example.org/atom/link-rels#prev";, and that's a valid value for the @rel attribute. There is also no language in the spec that prevents someone registering "prev" in the Registry of Link Relations. <http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section .9.1> So you might as well assume it does exist. >> 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? > Na�ve or smart? I subscribe to one feed which is the top headlines for that site, and I also subscribe to all headlines for one category at that site. The "na�ve" thing to do there would be to not conflate entries with identical id's. Another use case: I subscribe to a feed from the publisher's website, but later he sets up a link at feedburner.com or similar. The na�ve thing would be to assume that all the entries from feedburner.com are completely different from those retrieved from example.com, despite having the same id's. > There are far more problems with that before you start worrying about what is > the latest entry. > You forget: I determine what entries I subscribe to, as you do for yourself. If a bad actor starts screwing with id's then I can also unsubscribe. So, leaving aside hand waving scare-mongering statements like "far more problems", just what problems are there Graham? >> "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. > Glad you agree with me there. We wouldn't need to pick randomly if we had atom:modified. >> 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. > A gross sophistry on your part. If you don't want to argue the merits and prefer ad hominem attacks, then there really isn't much point continuing. >> [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. Nonsense. That's like arguing that http agents should only support those mime-types which were already defined oh so many years ago. No software currently exists that can possibly be expecting "application/foo", but that doesn't mean "application/foo" is an illegal mime-type. e.
