Comments on: Sorting and Filtering in Atom – CardAtom http://robubu.com/?p=10 the weblog of Rob Yates Sat, 14 Aug 2010 17:34:10 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Puzzlepieces – OpenSearch Update (June 11, 2006) http://robubu.com/?p=10&cpage=1#comment-19982 Puzzlepieces – OpenSearch Update (June 11, 2006) Fri, 14 Sep 2007 13:02:18 +0000 http://robubu.com/?p=10#comment-19982 [...] into it, as I unofficially advise my university on how to create an API for their people search. Others have been looking at this [...] [...] into it, as I unofficially advise my university on how to create an API for their people search. Others have been looking at this [...]

]]> By: Basil http://robubu.com/?p=10&cpage=1#comment-2897 Basil Thu, 28 Sep 2006 23:11:58 +0000 http://robubu.com/?p=10#comment-2897 Hi. I've been trying to write a generic OpenSearch RSS client in Java using Rome and the plugin modules for OpenSearch. I found some examples on the Rome wiki at java.net, but they're very terse and don't really explain what's going on. Everything compiles nicely, but I can't seem to be able to execute the actual search. Sorry if I'm in the wrong forum, but if you guys know anything about the Rome Java API's for OpenSearch, could you please point me to some good documentation? Any help is much appreciated. Thanks, Basil Hi. I’ve been trying to write a generic OpenSearch RSS client in Java using Rome and the plugin modules for OpenSearch. I found some examples on the Rome wiki at java.net, but they’re very terse and don’t really explain what’s going on. Everything compiles nicely, but I can’t seem to be able to execute the actual search. Sorry if I’m in the wrong forum, but if you guys know anything about the Rome Java API’s for OpenSearch, could you please point me to some good documentation? Any help is much appreciated. Thanks,

Basil

]]> By: Rob Yates http://robubu.com/?p=10&cpage=1#comment-2819 Rob Yates Sun, 03 Sep 2006 22:56:45 +0000 http://robubu.com/?p=10#comment-2819 Arthur, so you are correct that some of this could and probably should be done in the introspection document, especially the opensearch description. The problem we are working through at the moment is how to indicate the possible sort orders to the client ahead of time, so that they don't have to first get the results in last modified order and then re-ask for them in the order they actually want. The best we can think of at the moment is to have an opensearch field that is the sort order and its possible values have to be known by the client or embedded in some other xml element in the introspection document. If anyone has any suggestions, we are all ears. Arthur, so you are correct that some of this could and probably should be done in the introspection document, especially the opensearch description. The problem we are working through at the moment is how to indicate the possible sort orders to the client ahead of time, so that they don’t have to first get the results in last modified order and then re-ask for them in the order they actually want.

The best we can think of at the moment is to have an opensearch field that is the sort order and its possible values have to be known by the client or embedded in some other xml element in the introspection document. If anyone has any suggestions, we are all ears.

]]> By: Arthur Davidson Ficke http://robubu.com/?p=10&cpage=1#comment-2810 Arthur Davidson Ficke Thu, 31 Aug 2006 17:41:12 +0000 http://robubu.com/?p=10#comment-2810 Why not put the OpenSearch description into the collection declaration in the Atom introspection document? E.g.: Collection search Returns entries for this. Why not put the OpenSearch description into the collection declaration in the Atom introspection document? E.g.:

Collection search
Returns entries for this.

]]> By: Puzzlepieces – OpenSearch Update (June 11, 2006) http://robubu.com/?p=10&cpage=1#comment-169 Puzzlepieces – OpenSearch Update (June 11, 2006) Mon, 12 Jun 2006 03:46:17 +0000 http://robubu.com/?p=10#comment-169 [...] Perhaps more interesting than any of this is moving forward on adding structured data into OpenSearch, and DeWitt’s draft OpenSearch and Microformats is a great step in that direction. Personally I like data to be in XML more directly (rather than embedding it within atom:content, for example), but hopefully that approach can work in tandem, still using microformats. I’ll be looking into it, as I unofficially advise my university on how to create an API for their people search. Others have been looking at this too. [...] [...] Perhaps more interesting than any of this is moving forward on adding structured data into OpenSearch, and DeWitt’s draft OpenSearch and Microformats is a great step in that direction. Personally I like data to be in XML more directly (rather than embedding it within atom:content, for example), but hopefully that approach can work in tandem, still using microformats. I’ll be looking into it, as I unofficially advise my university on how to create an API for their people search. Others have been looking at this too. [...]

]]> By: Rob Yates http://robubu.com/?p=10&cpage=1#comment-146 Rob Yates Fri, 09 Jun 2006 14:43:33 +0000 http://robubu.com/?p=10#comment-146 DeWitt, the microformats stuff looks interesting, although I wonder if you would still choose the namespaces defined in the microformats specification if there was already a standard xml namespace for xCard and xCal. Henry, the idea is that clients would parse all the Links in the feed looking for one that has a "rel" attribute set to a specific value. When they find a value that matches "http://purl.org/CardAtom/sort/byFamilyName/asc", for example, then they know that the url in the corresponding href points to an alternate view of the current collection in the corresponding sort order. I agree that there will probably be lots of them and that the three that I have mentioned so far are not enough. The mandated sort order per the atom publishing protocol only applies to the order that is located at the collection url. Nothing in the standard prevents other sort orders on different urls being made available by the server. I think that it is a big advantage to have the server define templates that the client then uses to construct the url to hit. Without this the only way I can think of achieving the same end result is to have predifined url suffixes which places undesirable restrictions on the urls that a given implementation uses. DeWitt,
the microformats stuff looks interesting, although I wonder if you would still choose the namespaces defined in the microformats specification if there was already a standard xml namespace for xCard and xCal.

Henry,

the idea is that clients would parse all the Links in the feed looking for one that has a “rel” attribute set to a specific value. When they find a value that matches “http://purl.org/CardAtom/sort/byFamilyName/asc”, for example, then they know that the url in the corresponding href points to an alternate view of the current collection in the corresponding sort order. I agree that there will probably be lots of them and that the three that I have mentioned so far are not enough.

The mandated sort order per the atom publishing protocol only applies to the order that is located at the collection url. Nothing in the standard prevents other sort orders on different urls being made available by the server.

I think that it is a big advantage to have the server define templates that the client then uses to construct the url to hit. Without this the only way I can think of achieving the same end result is to have predifined url suffixes which places undesirable restrictions on the urls that a given implementation uses.

]]> By: Henry http://robubu.com/?p=10&cpage=1#comment-145 Henry Fri, 09 Jun 2006 11:34:22 +0000 http://robubu.com/?p=10#comment-145 We can probably talk about this off-line (literally) but a few comments: Sorting: If there's no standard notation I'm not sure how clients are supposed to automatically parse a URL like /sort/byFamilyName/asc into "sort by family name in ascending order." Of lesser concern, I think that you're going to wind up with dozens and dozens of links here. Also, kind of a semantics question - You said this: "The atom publishing protocol mandates the collection order to be by last modified date." Wouldn't the "mandatory sort by last mod time" rule apply to the collection returned by your "sort by" links? Filtering: This seems like an approach that could be generalized to allow client-side construction of URLs (which seems to me to be a big drawback in using ATOM for these sorts of applications). Could we do something similar to let you specify an array of values (for batch delete) or something? >Should there be an introspection document per collection that can somehow be retrieved from the collection url? I don't know if it's actually implemented anywhere, but there's a HTTP method called "HEAD". The HTTP 1.1 spec says that HEAD should return exactly the same information as GET, but without the document body (just the headers). I don't know how this applies to ATOM, but it seems like it would make sense to have an ATOM feed respond to a HEAD request by returning everything except the entries. We can probably talk about this off-line (literally) but a few comments:

Sorting:
If there’s no standard notation I’m not sure how clients are supposed to automatically parse a URL like /sort/byFamilyName/asc into “sort by family name in ascending order.” Of lesser concern, I think that you’re going to wind up with dozens and dozens of links here.

Also, kind of a semantics question – You said this: “The atom publishing protocol mandates the collection order to be by last modified date.”

Wouldn’t the “mandatory sort by last mod time” rule apply to the collection returned by your “sort by” links?

Filtering:
This seems like an approach that could be generalized to allow client-side construction of URLs (which seems to me to be a big drawback in using ATOM for these sorts of applications). Could we do something similar to let you specify an array of values (for batch delete) or something?

>Should there be an introspection document per collection that can somehow be retrieved from the collection url?

I don’t know if it’s actually implemented anywhere, but there’s a HTTP method called “HEAD”. The HTTP 1.1 spec says that HEAD should return exactly the same information as GET, but without the document body (just the headers). I don’t know how this applies to ATOM, but it seems like it would make sense to have an ATOM feed respond to a HEAD request by returning everything except the entries.

]]> By: DeWitt Clinton http://robubu.com/?p=10&cpage=1#comment-144 DeWitt Clinton Fri, 09 Jun 2006 00:36:40 +0000 http://robubu.com/?p=10#comment-144 Rob, Very interesting work here. You will likely be interested in the draft document on OpenSearch and microformats that I have been writing up. http://www.unto.net/wiki/OpenSearch_and_microformats That document isn't quite ready yet, but it is getting close. I'd love to hear what you think. Best, -DeWitt Rob,

Very interesting work here. You will likely be interested in the draft document on OpenSearch and microformats that I have been writing up.

http://www.unto.net/wiki/OpenSearch_and_microformats

That document isn’t quite ready yet, but it is getting close. I’d love to hear what you think.

Best,

-DeWitt

]]>