Re: timeless atom

["A. Pagaltzis" <pagaltzis@xxxxxx>]

Hi Erik,

* Erik Wilde <dret@xxxxxxxxxxxx> [2007-12-07 07:45]:
> i am wondering how well Atom works (and how well Atom
> implementations work) in an environment where the entries are
> not time-ordered.

just fine, thanks. :-)

> 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:edited property, 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

The specs are separate for a reason. Why conflate them?

    4.1.1. The "atom:feed" Element

       This specification assigns no significance to the order
       of atom:entry elements within the feed.

You can order *a* feed any which way you want. Not a *collection*
feed, but not all feeds are collection feeds.

Why do you want to avoid timestamping entries? Even if the data
itself is not chronological in any sense, there is certainly a
time at which a collection member was created, last updated
significantly, and last edited. There are always sensible time-
stamps to associate with collection members, so the requirement
to have them does not preclude the use of Atom for anything.

> 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:
>
> 1. 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.

The collection feed must be the way it is specified in RFC 5023
if it is to be useful to editing clients. Just because you are
allowed to break a SHOULD doesn’t mean it’s a good idea. Please
read RFC 2119 – “SHOULD” doesn’t mean “might we suggest that
perhaps you entertain the idea that maybe you could.”

How do you propose that Atompub clients synch their local cache
to the collection efficiently? They need to know which entries
have been edited since they last saw the collection. What sort
key would you propose for the collection that would allow them to
do this efficiently? There aren’t all that many candidates if you
look at it this way, are there? :-)

But this applies only to collection feeds. And there’s nothing
that prevents you from producing multiple feeds from a single
collection. In fact, experience is establishing it as something
of an antipattern to use the collection feed as the public feed
precisely because the collection feed needs to serve a very
specific set of needs whereas publically available feeds are
usually supposed to serve any number of other desires. (Even when
a public feed is time-ordered, people usually want it ordered by
atom:updated rather than app:edited.)

> the interesting question is: how far can you go?

As far as you want. Look at OpenSearch.

Just use some feed other than the collection feed for queries.

> but AtomPub tells us that listing collection members always
> uses GET, which means we cannot POST the image.

Yes, if you POST to the collection URI, the assumption is that
you want to store the image as a media resource in the
collection.

But there’s nothing stopping you from minting another URI for
querying the collection and advertising it in the collection with
`<link rel="image-query" href="..."/>` or something like that.
Clients which understand your query-by-example-image protocol
will know to look for that link.

> 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.

You came with some misconceptions about how one would try to do
this sort of thing with Atom and Atompub; but the facilities to
do it properly are all there.

To some extent it *is* already being done: aside from OpenSearch,
which I mentioned above, I think GData has some non-trivial
querying facilities too.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>