David,
Excellent comments.
David Powell wrote:
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?
Natural ordering and time-ordering are, by the very nature, opposing
views -- unless of course, the natural ordering and time-ordering just
happen to coincide with one another (by chance or design) .
Using the terminology from Mark Nottingham's Feed History extension,
naturally ordered feeds are likely to also be non-incremental feeds.
For instance, my NetFlix.com Queue Feed is clearly intended to be an
ordered, non-incremental feed. The feed presents it's entire state.
There is no history. The ordering of the items in the feed is
significant.
I believe that it is safe to assert that ordered feeds should be
presumed to be non-incremental. I will hold off on making that a
normative assertion, however, due simply because there is no evidence
that natural ordering *can't* be preserved across multiple feeds.
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.
This is definitely something I've been thinking about -- that is, how to
use the Atom protocol to edit an ordered collection. Without the
introduction of a specific metadata field within the entry itself, the
only potential option is a pub:control parameter that specifies the
ordering index for the entry. At this time I simply do not yet know if
that is the right approach. I'll need to experiment a bit more.
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.
As far as feed processing is concerned I agree that the ordering of
atom:entry elements is not significant, even if the feed does contain
<fi:ordered />. The ordered extension is a flag that helps applications
interpret the intention of the feed. For example, there is a clear
distinction of intent between my weblogs feed and my NetFlix Queue
feed. While both can be treated the same under the covers, having some
sort of clue as to how the two should be presented to the user is helpful.
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.
Agreed that this is a valid issue. Let me stew over this one.
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.
Nor is it clear how it could work in aggregation scenarios. e.g. what
happens if the entry contains an index and is aggregated into a feed
that has another entry with a conflicting index?
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?
Agreed. I actually had the same thought the other day and had a "Boy,
that was silly" head-slap moment.
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.
Interesting thought. Correct me if I'm wrong, but this would look
something like:
<ordered>http://www.example.com/ordered/by/priority</ordered>
With each entry having something like a corresponding priority element
(just an example)
<x:priority>70</x:priority>
Or
<ordered>http://www.example.com/ordered/by/position</ordered>
Or ... whatever else
The bottom line would be that the URI value of the ordered element would
indicate the ordering that should be applied to the elements. As a side
thought, this may solve the problem with ordering across sliding window
feeds in at least some cases.
Very good thoughts.
- James
