<?xml version="1.0" encoding='utf-8'?>
<service xmlns="http://www.w3.org/2007/app";
xmlns:atom="http://www.w3.org/2005/Atom";>
<workspace>
<atom:title>Main Site</atom:title>
<collection
href="http://example.org/blog/main"; >
<atom:title>My Blog Entries</atom:title>
<atom:link rel="openfilter"
href="http://example.org/blog/openfilter.xml"; />
</collection>
</workspace>
</service>
Any time I think I want this*, it's a general filter for atom:* elements
that can be applied across all the available collections. And it's
usually for read only work (ie plain feeds, not collections).
As for 'orderby', two things. First the filtered URIs don't appear in collections so no problem there. Second if the filtered feeds aren't acting as collections, they're feeds, you can order them any way you want.
The latter reason reminds me that I wish we had a rel type called "collection" for feeds, so there was an hateos way to find to a collection to post to (edit doesn't quite work for me).
Bill* The use-case for this is a contacts API; everyone will want some kind of read access sorted by some datum/field, but the contacts collection itself needs to be read/write and ordered by updated so client syncing doesn't kill the server.
Subbu Allamaraju wrote:
Right. I am not talking about using templates in atom:link in feeds as it won't make sense since those need to true URIs.I agree with John that it would be nice to define an extension for the service document so that clients would know how to filter a collection.Regards, Subbu On Apr 27, 2008, at 10:35 AM, Aristotle Pagaltzis wrote:* Subbu Allamaraju <subbu@xxxxxxxxx> [2008-04-27 18:15]:AtomPub just says that, use GET to a URI to get a view of the collection. The URI could very well be a template containing search terms and other conditions so that the client can fetch a constrained view of the collection.RFC 4287 requires a valid IRI in atom:link/@href. A URI template is purposefully not valid as a URI because it contains curly braces, which are disallowed in URIs. So you cannot put templates in Atom links. This design is good interop practice: you have to provide clients with a way to request the collection feed from a collection URI anyway, so vanilla Atompub clients will work as expected. That means doctoring the collection link is out of the question. But there is no reason you cannot put the URI template in another place in your service document, *in addition* to the plain link you must provide. And since support for the query feature has to be added to clients specifically, anyway, requiring them to add support for a template link extension element as part of that effort is no extra burden. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>