openSearch

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

I would like the strawman document to include an annex that describes how
the protocol is to be used for openSearch requests and responses.  I really
do think it is important that the initial public submission address
openSearch concretely.  Hopefully that will get peoples attention. And after
all, this will be a "strawman", which means it can be "shot down". Even if
we don't get it right in the strawman, it will alert people that we are
serious about this.

Correspondingly, this means making a few modifications to the protocol.

1.  add a parameter that says what schema the response comes back in.
Possible values: (1) SR2.0 (default) (2) atom1.0  (3) rss2.0  (4) html (?) .
Adding this parameter does not cause incompatibility because it can be
omitted (defaults to SRU2.0)

The issue of "alternative response schema" was debated on the SRU list (in
fact, in this very context) and although there are some who are fiercely
opposed (well, "some" is overstating; make that "one") the overwhelming
consensus ("overwhelming" may also be a bit strong; perhaps "all but one";
there were about four opinions offered) was "do it".

2. The operation and version parameters in SRU could cause problems for
openSearch because they are mandatory in SRU.   (None of the other
parameters cause problems, that is they all can be rationalized in one
manner or another, I think.)   If these two remain mandatory, this causes
some complexity. I don't suggest that either be relaxed to optional because
we have had agonizing debate over both and concluded firmly that both need
to be mandatory; there is no need to stir that up again unless someone wants
to try to counter the argument for making them mandatory.  If a request
including the operation parameter is sent to an openSearch server it
probably will be ignored, so perhaps there isn't a problem for the operation
parameter.  With the version parameter, you can make the same argument, but
I think this is more risky.  It might also be ignored, but it doesn't seen
to make sense to say "version=2.0" in a request to an openSearch server,
where the openSearch version is 1.1.  Moreover, it is not completely
unlikely that openSearch will adopt a version parameter in the future.   One
possibility:  rename the version parameter -  call it sr-version. But then
you lose compatibility with earlier versions.  We're probably going to lose
some compatibility anyway (though we hope to minimize that loss) so you
could rationalize doing this on that basis.  Please give it some thought.

For discussion tomorrow morning.

--Ray