* Becker, Matthew R <[EMAIL PROTECTED]> [2007-05-24 13:55]:
> My original message referred to a standard ordering. By that I was
> referring to APP Draft 14, section 10 "The Entries in the returned Atom
> Feed SHOULD be ordered by their "atom:updated" property, with the most
> recently updated Entries coming first in the document order."
That has changed in -draft-15:
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. The app:edited
value is not equivalent to the HTTP Last-Modified: header and
cannot be used to determine the freshness of cached
responses.
> Assuming I've interpreted the APP draft correctly, we should be
> sending paged feeds where the entries are ordered by
> atom:updated.
That is the correct interpretation of -draft-14, yes. Again,
though, it is moot, because of the -draft-15 changes.
> However we have certain clients that would like to see the feed
> entries ordered differently (app:edited for example).
If you also need feed ordering by something other than
`app:edited`, then you can’t do that in the collection feed.
There is, however, nothing to stop you from linking other, non-
collection feeds (ie. with a different `rel` value) from the
service document. You’d just need to specify in an extension how
clients can know the ordering of these feeds so they can request
the one they’d like.
> If this were sorted client side, the client would have to
> request every page in the feed and sort the large number of
> entries. If the client could request the feed sorted properly
> to begin with, then the client could stop paging when
> app:edited reached the timestamp of the last request.
That is exactly the rationale that was put forward for the change
in §10.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
