[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: openSearch
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]