Monday, September 12, 2005, 5:55:20 PM, James M Snell wrote:
> I've updated the draft that defines an extension that can be used to > indicate that the order of entries within a Feed should be considered > significant. How will this interact with the sliding-window/feed-history interpretation of feeds? The natural order assigned by this extension seems incompatible with the implied date order that would be implied by two feed documents, polled over some period of time. What should be the order of a merged feed history such as this: Poll 1: feed(e1, e2, e3) Poll 2: feed(e3, e1, e5) - where, perhaps, 3 and 1 have been updated. How do you combine entries sorted by their natural order, with the time-ordered feed history? How will this interact with entry documents, eg over pubsub. What about Atom Protocol - I can't imagine how I would publish a feed with a given natural order. For something like the BBC feeds, some sort of arbitrary "score" field might be more interoperable with both entry documents, Atom protocol, and feed history. I'm probably on my own, but I expected Atom's statement that "This specification assigns no significance to the order of atom:entry elements within the feed" was non-negotiable and couldn't be changed by extensions. This seems more like potential Atom 1.1 material to me - it doesn't seem to layer on top of the Atom framework so much as slightly rewrite part of it. Eg - An Atom library or server that doesn't know about this extension is free to not preserve the entry order, and yet to retain the <fi:ordered /> element, even though this will have corrupted the data. I think that as implemented, this extension wouldn't be safe to deploy without must-understand extensions, which Atom 1.0 doesn't support. Ordered feeds are a useful problem though. Indexes or scores on entries might work better with entry documents, the protocol, and with the Atom extension framework, but it still isn't clear how they would interact with the sliding window. A couple more minor points: I'm not sure whether the descending/ascending attribute is necessary? Given that the extension just presents a natural order (by some unnamed ordering), why would anyone go to the trouble of presenting the entries in reversed order, and then label them as descending; why not just present them in ascending order to begin with? Would it be useful for the extension to allow the natural ordering to be named? - so if the ordering is by "Importance", or "Order of real-life events", or something else, then it could labelled with a URI and/or label, so that people don't have to guess the significance of the natural order. -- Dave
