</listitem>
<listitem>
<para>
- The parser converts CQL to
- <ulink url="&url.xcql;">XCQL</ulink>.
+ The parser converts CQL to XCQL.
XCQL is an XML representation of CQL.
XCQL is part of the SRU specification. However, since SRU
supports CQL only, we don't expect XCQL to be widely used.
If conversion failed, <function>cql_transform_buf</function>
returns a non-zero SRU error code; otherwise zero is returned
(conversion successful). The meanings of the numeric error
- codes are listed in the SRU specifications at
- <ulink url="&url.sru.diagnostics.list;"/>
+ codes are listed in the SRU specification somewhere (no
+ direct link anymore).
</para>
<para>
If conversion fails, more information can be obtained by calling
#define YAZ_MARC_XCHANGE 5
#define YAZ_MARC_CHECK 6
#define YAZ_MARC_TURBOMARC 7
+ #define YAZ_MARC_JSON 8
/* supply iconv handle for character set conversion .. */
void yaz_marc_iconv(yaz_marc_t mt, yaz_iconv_t cd);
</listitem>
</varlistentry>
+ <varlistentry>
+ <term>YAZ_MARC_JSON</term>
+ <listitem>
+ <para>
+ <ulink url="&url.marc_in_json;">MARC-in_JSON</ulink> format.
+ </para>
+ </listitem>
+ </varlistentry>
+
</variablelist>
</para>
<para>
<listitem>
<para>
Format of input. Supported values are
- <literal>marc</literal> (for ISO2709); and <literal>xml</literal>
- for MARCXML/MarcXchange.
+ <literal>marc</literal> (for ISO2709), <literal>xml</literal>
+ (MARCXML/MarcXchange) and <literal>json</literal>
+ (<ulink url="&url.marc_in_json;">MARC-in_JSON</ulink>).
</para>
</listitem>
</varlistentry>
<listitem>
<para>
Format of output. Supported values are
- <literal>line</literal> (MARC line format);
- <literal>marcxml</literal> (for MARCXML),
- <literal>marc</literal> (ISO2709),
- <literal>marcxhcange</literal> (for MarcXchange).
+ <literal>line</literal> (MARC line format);
+ <literal>marcxml</literal> (for MARCXML),
+ <literal>marc</literal> (ISO2709),
+ <literal>marcxhcange</literal> (for MarcXchange),
+ or <literal>json</literal>
+ (<ulink url="&url.marc_in_json;">MARC-in_JSON </ulink>).
</para>
</listitem>
</varlistentry>
</para>
</sect2>
</sect1>
+ <sect1 id="sorting"><title>Sorting</title>
+ <para>
+ This chapter describes sorting and how it is supported in YAZ.
+ Sorting applies to a result-set.
+ The <ulink url="http://www.loc.gov/z3950/agency/markup/05.html#3.2.7">
+ Z39.50 sorting facility
+ </ulink>
+ takes one or more input result-sets
+ and one result-set as output. The most simple case is that
+ the input-set is the same as the output-set.
+ </para>
+ <para>
+ Z39.50 sorting has a separate APDU (service) that is, thus, performed
+ following a search (two phases).
+ </para>
+ <para>
+ In SRU/Solr, however, the model is different. Here, sorting is specified
+ during the the search operation. Note, however, that SRU might
+ perform sort as separate search, by referring to an existing result-set
+ in the query (result-set reference).
+ </para>
+ <sect2><title>Using the Z39.50 sort service</title>
+ <para>
+ yaz-client and the ZOOM API supports the Z39.50 sort facility. In any
+ case the sort sequence or sort critiera is using a string notation.
+ This notation is a one-line notation suitable for being manually
+ entered or generated and allows for easy logging (one liner).
+ For the ZOOM API, the sort is specified in the call to ZOOM_query_sortby
+ function. For yaz-client the sort is performed and specified using
+ the sort and sort+ commands. For description of the sort criteria notation
+ refer to the <link linkend="sortspec">sort command</link> in the
+ yaz-client manual.
+ </para>
+ <para>
+ The ZOOM API might choose one of several sort strategies for
+ sorting. Refer to <xref linkend="zoom-sort-strategy"/>.
+ </para>
+ </sect2>
+ <sect2><title>Type-7 sort</title>
+ <para>
+ Type-7 sort is an extension to the Bib-1 based RPN query where the
+ sort specification is embedded as an Attribute-Plus-Term.
+ </para>
+ <para>
+ The objectives for introducing Type-7 sorting is that it allows
+ a client to perform sorting even if it does not implement/support
+ Z39.50 sort. Virtually all Z39.50 client software supports
+ RPN queries. It also may improve performance because the sort
+ critieria is specified along with the search query.
+ </para>
+ <para>
+ The sort is triggered by the presence of type 7 and the value of type 7
+ specifies the
+ <ulink url="http://www.loc.gov/z3950/agency/asn1.html#SortKeySpec">
+ sortRelation
+ </ulink>
+ The value for type 7 is 1 for ascending and 2 for descending.
+ For the
+ <ulink url="http://www.loc.gov/z3950/agency/asn1.html#SortElement">
+ sortElement
+ </ulink>
+ only the generic part is handled. If generic sortKey is of type
+ sortField, then attribute type 1 is present and the value is
+ sortField (InternationalString). If generic sortKey is of type
+ sortAttributes, then the attributes in list is used . generic sortKey
+ of type elementSpec is not supported.
+ </para>
+ <para>
+ The term in the sorting Attribute-Plus-Term combo should hold
+ an integer. The value is 0 for primary sorting criteria, 1 for second
+ criteria, etc.
+ </para>
+ </sect2>
+ </sect1>
+ <sect1 id="facets"><title>Facets</title>
+ <para>
+ YAZ supports facets for in Solr, SRU 2.0 and Z39.50 protocols.
+ </para>
+ <para>
+ Like Type-1/RPN, YAZ supports a string notation for specifying
+ facets. For the API this is performed by
+ <function>yaz_pqf_parse_facet_list</function>.
+ </para>
+ <para>
+ For ZOOM C the facets are given by option "facets"
+ For yaz-client it is used for the facets command.
+ </para>
+ <para>
+ The grammar of this specification is as follows:
+ <literallayout>
+ facet-spec ::= facet-list
+
+ facet-list ::= facet-list ',' attr-spec | attr-spec
+
+ attr-spec ::= attr-spec '@attr' string | '@attr' string
+
+ </literallayout>
+ The notation is inspired by PQF. The string following '@attr'
+ may not include blanks and is of the form
+ <replaceable>type</replaceable><literal>=</literal><replaceable>value</replaceable>,
+ where <replaceable>type</replaceable> is an integer and
+ <replaceable>value</replaceable> is a string or an integer.
+ </para>
+ <para>
+ The Facets specification is not Bib-1. The following types apply:
+ </para>
+ <table id="facet.attributes">
+ <title>Facet attributes</title>
+ <tgroup cols="2">
+ <colspec colwidth="2*" colname="type"></colspec>
+ <colspec colwidth="9*" colname="description"></colspec>
+ <thead>
+ <row>
+ <entry>Type</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>1</entry>
+ <entry>
+ Field-name. This is often a string, eg "Author", "Year", etc.
+ </entry>
+ </row>
+
+ <row>
+ <entry>2</entry>
+ <entry>
+ Sort order. Value should be an integer.
+ Value 0: count descending (frequency). Value 1: alpha ascending.
+ </entry>
+ </row>
+
+ <row>
+ <entry>3</entry>
+ <entry>
+ Number of terms requested.
+ </entry>
+ </row>
+
+ <row>
+ <entry>4</entry>
+ <entry>
+ Start offset.
+ </entry>
+ </row>
+
+ </tbody>
+ </tgroup>
+ </table>
+ </sect1>
</chapter>
<!-- Keep this comment at the end of the file
projects / yaz-moved-to-github.git / blobdiff