Re: Opensearch XSLT
On Oct 12, 2007 10:13 AM, Walter Underwood [EMAIL PROTECTED] wrote: OpenSearch was a pretty poor design and is dead now, so I wouldn't expect any new implementations. Google's GData (based on Atom) reuses the few useful OpenSearch elements needed for things like number of hits. Solr's Atom support really should include those. Ok this was a while ago, and my question is way off topic (so feel to ignore). Why is OpenSearch a poor design, and how is it dead if something like GData has used portions of it. It used portions of AtomPub too, do you think AtomPub is dead? //Ed
Re: Opensearch XSLT
Ed, Wunder minght be right. As far as I know, only A9 was pushing OpenSearch. Now that A9 is not *really* around much, I think nobody is pushing it. I don't know of anyone pushing GData either, other than Google, but Google is doing rather (too?) well these days. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message From: Ed Summers [EMAIL PROTECTED] To: solr-user@lucene.apache.org Sent: Monday, November 26, 2007 9:15:54 AM Subject: Re: Opensearch XSLT On Oct 12, 2007 10:13 AM, Walter Underwood [EMAIL PROTECTED] wrote: OpenSearch was a pretty poor design and is dead now, so I wouldn't expect any new implementations. Google's GData (based on Atom) reuses the few useful OpenSearch elements needed for things like number of hits. Solr's Atom support really should include those. Ok this was a while ago, and my question is way off topic (so feel to ignore). Why is OpenSearch a poor design, and how is it dead if something like GData has used portions of it. It used portions of AtomPub too, do you think AtomPub is dead? //Ed
Re: Opensearch XSLT
GData is using a few elements from OpenSearch, but those would be hard to get wrong: start index, results per page, total number of results. I'd be happier if Google had joined the Atom WG instead and worked on the Feed Paging and Archiving standard (http://tools.ietf.org/html/rfc5005), but that is water under the bridge. 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). Then they left out support for existing things, like putting a boolean attribute on the totalResults element to say whether the count is exact. There were lots of other problems that I've forgotten by now. It was pretty clear that there was no serious outside contribution or review. It was an A9 product spec that they published. Great name, but not a very good design. Overall, it was substantially inferior to the STARTS work done at Stanford in 1996: http://infolab.stanford.edu/~gravano/starts_home.html Atom and Atompub are both excellent work. The exact opposite of OpenSearch. Highly reviewed by committed people, working in multiple implementations, useful, and published as real standards (RFCs). For a broad search protocol, I'd start with GData on Atom or Atom+RFC5005. Disclaimer: I was on the Atom working group. wunder On 11/26/07 1:54 PM, Otis Gospodnetic [EMAIL PROTECTED] wrote: Ed, Wunder minght be right. As far as I know, only A9 was pushing OpenSearch. Now that A9 is not *really* around much, I think nobody is pushing it. I don't know of anyone pushing GData either, other than Google, but Google is doing rather (too?) well these days. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message From: Ed Summers [EMAIL PROTECTED] To: solr-user@lucene.apache.org Sent: Monday, November 26, 2007 9:15:54 AM Subject: Re: Opensearch XSLT On Oct 12, 2007 10:13 AM, Walter Underwood [EMAIL PROTECTED] wrote: OpenSearch was a pretty poor design and is dead now, so I wouldn't expect any new implementations. Google's GData (based on Atom) reuses the few useful OpenSearch elements needed for things like number of hits. Solr's Atom support really should include those. Ok this was a while ago, and my question is way off topic (so feel to ignore). Why is OpenSearch a poor design, and how is it dead if something like GData has used portions of it. It used portions of AtomPub too, do you think AtomPub is dead? //Ed
Re: Opensearch XSLT
Doesn't Microsoft push OpenSearch? http://www.microsoft.com/presspass/press/2007/nov07/11-06SearchServer08ExpressPR.mspx Koji Otis Gospodnetic wrote: Ed, Wunder minght be right. As far as I know, only A9 was pushing OpenSearch. Now that A9 is not *really* around much, I think nobody is pushing it. I don't know of anyone pushing GData either, other than Google, but Google is doing rather (too?) well these days. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
Re: Opensearch XSLT
According to the guy in their booth, they support federated searches on engines that support OpenSearch (meaning you can use their federation tool to search content indexed by search engines that have an OpenSearch interface -- e.g., A9) but SearchServer '08 does NOT have an OpenSearch interface to it's native search functionality. You can write one using .NET or have one of their partners develop one for you. Bill On Nov 26, 2007 3:38 PM, Koji Sekiguchi [EMAIL PROTECTED] wrote: Doesn't Microsoft push OpenSearch? http://www.microsoft.com/presspass/press/2007/nov07/11-06SearchServer08ExpressPR.mspx Koji Otis Gospodnetic wrote: Ed, Wunder minght be right. As far as I know, only A9 was pushing OpenSearch. Now that A9 is not *really* around much, I think nobody is pushing it. I don't know of anyone pushing GData either, other than Google, but Google is doing rather (too?) well these days. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
Re: Opensearch XSLT
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_parameter
Re: Opensearch XSLT
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
Re: Opensearch XSLT
Thanks for the additional context and the pointers to STARTS. I realize solr-user is hardly a venue for discussing the details of OpenSearch so I'll refrain from commenting any further. I apologize for the harshness of my FUD comment. //Ed
Re: Opensearch XSLT
There is a request handler in 1.2 for Atom. That might be close. OpenSearch was a pretty poor design and is dead now, so I wouldn't expect any new implementations. Google's GData (based on Atom) reuses the few useful OpenSearch elements needed for things like number of hits. Solr's Atom support really should include those. http://code.google.com/apis/gdata/reference.html wunder On 10/12/07 4:59 AM, Robert Young [EMAIL PROTECTED] wrote: Hi, Does anyone know of an XSLT out there for transforming Solr's default output to Opensearch format? Our current frontend system uses opensearch so we would like to integrate it like this. Cheers Rob
Re: Opensearch XSLT
There is a file ${SOLR_HOME}/conf/xslt/example_rss.xsl which is easily
modified to transform Solr's output to OpenSearch. Works great, though
fixing the date format is a hassle. The supported, searchable Solr date
format is not the OpensSearch standard.
On 10/12/07, Robert Young [EMAIL PROTECTED] wrote:
Hi,
Does anyone know of an XSLT out there for transforming Solr's default
output to Opensearch format? Our current frontend system uses
opensearch so we would like to integrate it like this.
Cheers
Rob
