MXG and OpenSearch

I have finally had a chance to read the MXG spec more closely, and I had a chance to read Thom Hickey’s post comparing OpenSearch and MXG in more depth, and I think the matrix needs a small update. That being that OpenSearch 1.1 supports specifying the number of records in the request.

So the matrix would now look like this:

OS 1.1 MXG L1 MXG L2 MXG L3 SRU
Request Record Starting Point
Request Number of Records
Request Record Schema .
Defined Query Grammar . . .
Specify sort Order . . . .
Specify Ranking Order . . . .
Diagnostic Messages .
XML Response
Record Count In Response
Records In Known Schema

What is unfortunate is that neither protocols support sort order specification or sort order ranking. I would suggest that it would be relatively simple to support date and relevance, and I would also suggest that using the Google search syntax would be a good idea.

Where OpenSearch really wins I think is in its XML format, namely RSS, which is widedly supported and well understood, making this a very simple protocol to implement and support.

Advertisements

2 Responses to MXG and OpenSearch

  1. My initial reactions to MXG are over here http://faganm.com/blog/tag/mxg

    I don’t entirely agree that OpenSearch doesn’t “have” all those things, as OpenSearch is designed to be a core spec, with everything else in extensions, and many existing vocabs work perfectly well as OpenSearch extensions, not to mention in-progress ones.

    As to sorting, I certainly agree that it needs this. I wanted to spend some time on this, but only got into it at the end of my internship at A9 and it kind of fell by the wayside. Back then somebody pointed me to http://zing.z3950.org/cql/sorting.html , but that’s as far as I got beyond some vague ideas.

  2. That is a very good point and a distinction needs to be drawn between what is specifically supported by the protocol and what can be built around it. While OpenSearch does “not have” a number of things, like sort or search syntax for example, nothing precludes from supporting them if both ends agree on how to support them. OpenSearch is very flexible from this point of view.

    Sort is important since more search engines are supporting relevance and date sorting, and the Google search syntax is becoming a de facto standard in search engines (with each search engine supporting additions of one sort or another.) Perhaps we need an OpenSearch 1.2?

    I still think that OpenSearch is the better protocol, because it is simple to implement (RSS), can be extended easily, has been tested in a production environment (A9) and is widely supported.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: