Atom evolved out of RSS and as such basically is a well-designed version of RSS. AtomPub adds to that a well-defined protocol for interacting with a server that manages collections of (potentially updateable) Atom entries. RSS was designed for news feeds, which are regarded as time-ordered series of news items. Atom has the same bias, which makes sense.
However, i am wondering how well Atom works (and how well Atom implementations work) in an environment where the entries are not time-ordered. there is quite a bit of time bias in Atom:
- Atom (RFC 4287):
atom:entry elements MUST contain exactly one atom:updated element.
- AtomPub (RFC 5032):
The Entries in the returned Atom Feed SHOULD be ordered by their
app:editedproperty, with the most recently edited Entries coming first in the document order.
so it is not even allowed to have untimed entries in an Atom feed, and an Atom feed is expected to be ordered by time. so there definitely is some bias that one cannot escape, but what would it take to implement a timeless AtomPub server?
if a collection of atom entries has no time stamps (or at least the time stamps are not considered to be useful as the primary sort key), then there are two possibilities:
- there may be some other implicit primary sort key, which is used for publishing the feed. this would conflict with AtomPub's
SHOULD, but that is allowed.
- if there is no implicit key, then the GET request has to specify some query that is used for retrieval and ranking.
this raises the interesting question whether a feed can be regarded as a queriable collection, rather than an ordered sequence. i don't think anything in Atom or AtomPub disallows this (as long as the atom entries have the required
atom:edited element), but it certainly is not the usual way how Atom is used.
in a very limited sense, one part of the Atom landscape already does this: feed paging and archiving (RFC 5005) specifies how to navigate paged feeds, and in an example uses
as a link to the second page of a feed. this is a
query, but a very primitive one.
the interesting question is: how far can you go? it would be conceivable to allow arbitrarily complex query strings in the URI, but due to limitations of URIs, there is only so much you can embed into a URI. assume you have a collection of pictures and want to query that by picture, using a sample picture and getting as a result the ranked list of similar pictures. this does not work as a URI query string. but AtomPub tells us that listing collection members always uses GET, which means we cannot POST the image. we could do this by using GET to transmit the sample picture, but is it allowed for an HTTP GET to have a message body? actually, this question is kind of undecided, nothing in HTTP explicitly prohibits this, but HTTP also never explicitly mentions it.
so, i would be really interested to find out whether the usage of Atom and AtomPub for collections where time is not the primary key is something that is (a) a stupid idea, (b) reasonable but esoteric, or (c) something people are already doing; and if (c) applies, how these collections are queried, in particular in the light of the fact that URI query strings are limited in the data they can carry.