"FUD" is pretty strong language. I'll provide some context for my opinions.
The year before OpenSearch came out, I'd designed and implemented a SOAP distributed search protocol to go across Ultraseek and Verity K2, so I was pretty familiar with heterogeneous search protocols, especially those that had to work for all the extra features that people depend on. You can see an example here: http://search.ultraseek.com/webservices/ I do *not* recommend using SOAP for protocols. That was a horrific experience. Every one of the things I mentioned is something that weakens the format and would have been fixed with review. OpenSearch was released as a 1.0, with no prior review. 1.1 remains in Draft 3. It doesn't look like it has moved forward in two years. Either you implement 1.0 or pretend 1.1 Draft 3 is a finished spec: http://www.opensearch.org/Specifications/OpenSearch/Changelog I tried to look this stuff up in the current spec, but it didn't display in FireFox 3.0b1, so I checked some of it against the 1.0 spec. The template parameter you point to appears to be about language filtering and implicitly about linguistic processing. It would be much better to separate query processing and results filtering as the STARTS project did and as we did in the original Ultraseek distributed search and the SOAP web service. I really recommend looking at STARTS if you are interested in any kind of distributed search. It is fundamental work, and the workshop was a group of active implementers. Heck, Doug Cutting was there. http://infolab.stanford.edu/~gravano/workshop_participants.html wunder On 11/26/07 6:28 PM, "Ed Summers" <[EMAIL PROTECTED]> wrote: > On Nov 26, 2007 5:35 PM, Walter Underwood <[EMAIL PROTECTED]> wrote: >> GData is really pretty useful. OpenSearch was just sloppy. Some element >> names were capitalized, some weren't. A bunch of stuff specific to A9's >> UI was mixed in. They insisted on using RSS in addition to Atom for a new >> application. They supported many encoding types, something that belongs >> in the presentation layer, not the protocol. [Ever tested a product that >> supported 150 encodings? I have.] Then they left out any way to specify >> the natural language used to process the query. They used two different >> formats for the parameters to a POST and a GET even though HTML has used >> a single format forever (the <FORM> element). > > Apart from supporting RSS and Atom this doesn't sound much like the > most recent version of the spec I've looked at [1]. But of course you > are entitled to your opinion about the "sloppiness". I totally agree > about the merits of putting standard documents like OpenSearch through > a process like IETF. I just think putting down efforts like > OpenSearch with verbage bordering on FUD doesn't do anyone much good. > > //Ed > > [1] > http://www.opensearch.org/Specifications/OpenSearch/1.1#The_.22language.22_par > ameter
