connection can be forced to use SRU rather the SRW (the default) by
prefixing the target string with <literal>sru=get,</literal>, like this:
<literal>sru=get,http://sru.miketaylor.org.uk:80/sru.pl</literal>
- </para>
-
+ </para>
+ <para>
+ <ulink url="&url.solr;">SOLR</ulink> protocol support was added to YAZ in version 4.1.0,
+ as a dialect of a SRU protocol, since both are HTTP based protocols.
+ </para>
<para>
The lack of a simple Z39.50 client API for &yaz; has become more
and more apparent over time. So when the first &zoom; specification
<para>
You can prefix the host with a scheme followed by colon. The
default scheme is <literal>tcp</literal> (Z39.50 protocol).
- The scheme <literal>http</literal> selects SRU over HTTP.
+ The scheme <literal>http</literal> selects SRU/get over HTTP by default,
+ but can overridded to use SRU/post, SRW and the SOLR protocol.
</para>
<para>
You can prefix the scheme-qualified host-string with one or more
discover whether the server claims to support the specified
operations.
</entry><entry>none</entry></row>
- <row><entry>
- sru</entry><entry>
- SRU transport type. Must be either <literal>soap</literal>,
+ <row>
+ <entry>sru</entry><entry>
+ SRU/SOLR transport type. Must be either <literal>soap</literal>,
<literal>get</literal>, <literal>post</literal>, or
<literal>solr</literal>.
- </entry><entry>soap</entry></row>
+ </entry><entry>soap</entry></row>
<row><entry>
sru_version</entry><entry>
SRU/SRW version. Should be <literal>1.1</literal>, or
On response the the list contains the terms that the target
could collect.
</entry><entry>none</entry></row>
+ <row><entry>
+ apdulog</entry><entry>
+ If set to a true value such as "1", a log of low-level
+ protocol packets is emitted on standard error stream. This
+ can be very useful for debugging.
+ </entry><entry>0</entry></row>
</tbody>
</tgroup>
</table>
</para>
</sect2>
<sect2 id="zoom.sru.init.behavior">
- <title>SRU Protocol behavior</title>
+ <title>SRU/SOLR Protocol behavior</title>
<para>
- The SRU protocol doesn't feature an Inititialize Request, so
+ The HTTP based protocols (SRU, SRW, SOLR) doesn't feature an Inititialize Request, so
the connection phase merely establishes a TCP/IP connection
with the SOAP service.
</para>
<para>Most of the ZOOM connection options do not
- affect SRU and they are ignored. However, future versions
+ affect SRU/SOLR and they are ignored. However, future versions
of &yaz; might honor <literal>implementationName</literal> and
put that as part of User-Agent header for HTTP requests.
</para>
SRU SearchRetrieveRequest.
</para>
<para>
- Unfortunately, SRU does not define a database setting. Hence,
+ SOLR queries has to be done in SOLR query format.
+ </para>
+ <para>
+ Unfortunately, SRU or SOLR does not define a database setting. Hence,
<literal>databaseName</literal> is unsupported and ignored.
However, the path part in host parameter for functions
<function>ZOOM_connecton_new</function> and
The <parameter>type</parameter> is a string of the format:
</para>
<para>
- <replaceable>form</replaceable>[;charset=<replaceable>from</replaceable>[,<replaceable>to</replaceable>]][;format=<replaceable>v</replaceable>]
+ <replaceable>format</replaceable>[;charset=<replaceable>from</replaceable>[/<replaceable>opacfrom</replaceable>][,<replaceable>to</replaceable>]][;format=<replaceable>v</replaceable>]
</para>
<para>
- where <replaceable>form</replaceable> specifies the format of the
+ where <replaceable>format</replaceable> specifies the format of the
returned record, <replaceable>from</replaceable>
specifies the character set of the record in its original form
(as returned by the server), <replaceable>to</replaceable> specifies
the output (returned)
character set encoding.
- If charset is not given, then no character set conversion takes place.
If <replaceable>to</replaceable> is omitted UTF-8 is assumed.
+ If charset is not given, then no character set conversion takes place.
+ </para>
+
+ <para>OPAC records may be returned in a different
+ set from the bibliographic MARC record. If this is this the case,
+ <replaceable>opacfrom</replaceable> should be set to the character set
+ of the OPAC record part.
</para>
+ <note>
+ <para>
+ Specifying the OPAC record character set requires YAZ 4.1.5 or later.
+ </para>
+ </note>
<para>
The format argument controls whether record data should be XML
pretty-printed (post process operation).
</varlistentry>
<varlistentry><term><literal>xml</literal></term>
<listitem><para>The record is returned in XML if possible.
- SRU and Z39.50 records with transfer syntax XML are
+ SRU, SOLR and Z39.50 records with transfer syntax XML are
returned verbatim. MARC records are returned in
<ulink url="&url.marcxml;">
MARCXML
</para>
</sect2>
<sect2 id="zoom.sru.record.behavior">
- <title>SRU Protocol behavior</title>
+ <title>SRU/SOLR Protocol behavior</title>
<para>
- The ZOOM driver for SRU treats records returned by a SRU server
+ The ZOOM driver for SRU/SOLR treats records returned by a SRU/SOLR server
as if they where Z39.50 records with transfer syntax XML and
no element set name or database name.
</para>
</sect1>
<sect1 id="zoom.facets"><title>Facets</title>
<para>
+ Facets operations is not part of the official ZOOM specification, but is an Index Data extension
+ for YAZ-based Z39.50 targets or <ulink url="&url.solr;">SOLR</ulink> targets.
In case the target can and is requested to return facets, using a result set the ZOOM client
can request one or all facet fields. Using a facet field the client can request the term count and
then interate over the terms.
</para>
<para>
- The Scan interface is supported for both Z39.50 and SRU.
+ The Scan interface is supported for both Z39.50, SRU (and SOLR?).
</para>
<synopsis>