YAZ_{BEGIN,END}_CDECL yaz_init_globals
[yaz-moved-to-github.git] / doc / tools.xml
index ddb6807..7e4096c 100644 (file)
     <synopsis>
      #include &lt;yaz/pquery.h&gt;
 
-     YAZ_PQF_Parser yaz_pqf_create (void);
+     YAZ_PQF_Parser yaz_pqf_create(void);
 
-     void yaz_pqf_destroy (YAZ_PQF_Parser p);
+     void yaz_pqf_destroy(YAZ_PQF_Parser p);
 
-     Z_RPNQuery *yaz_pqf_parse (YAZ_PQF_Parser p, ODR o, const char *qbuf);
+     Z_RPNQuery *yaz_pqf_parse(YAZ_PQF_Parser p, ODR o, const char *qbuf);
 
-     Z_AttributesPlusTerm *yaz_pqf_scan (YAZ_PQF_Parser p, ODR o,
+     Z_AttributesPlusTerm *yaz_pqf_scan(YAZ_PQF_Parser p, ODR o,
                           Odr_oid **attributeSetId, const char *qbuf);
 
-
-     int yaz_pqf_error (YAZ_PQF_Parser p, const char **msg, size_t *off);
+     int yaz_pqf_error(YAZ_PQF_Parser p, const char **msg, size_t *off);
     </synopsis>
     <para>
      A PQF parser is created and destructed by functions
     <synopsis>
      #include &lt;yaz/pquery.h&gt;
 
-     Z_RPNQuery *p_query_rpn (ODR o, oid_proto proto, const char *qbuf);
+     Z_RPNQuery *p_query_rpn(ODR o, oid_proto proto, const char *qbuf);
 
-     Z_AttributesPlusTerm *p_query_scan (ODR o, oid_proto proto,
+     Z_AttributesPlusTerm *p_query_scan(ODR o, oid_proto proto,
                              Odr_oid **attributeSetP, const char *qbuf);
 
-     int p_query_attset (const char *arg);
+     int p_query_attset(const char *arg);
     </synopsis>
     <para>
      The function <function>p_query_rpn()</function> takes as arguments an
 
          <row><entry><literal>s=ag</literal></entry><entry>
            Tokens that appears as phrases (with blank in them) gets
-           structure phrase attached. Tokens that appers as words
-           gets structure phrase attached. Phrases and words are
+           structure phrase attached (4=1). Tokens that appear to be words
+           gets structure word attached (4=2). Phrases and words are
            ANDed. This is a variant of s=al and s=pw, with the main
            difference that words are not split (with operator AND)
            but instead kept in one RPN token. This facility appeared
          <entry><literal>?</literal></entry>
         </row>
         <row>
+         <entry>mask</entry>
+         <entry>Masking character. Requires YAZ 4.2.58 or later</entry>
+         <entry><literal>#</literal></entry>
+        </row>
+        <row>
          <entry>field</entry>
          <entry>Specifies how multiple fields are to be
           combined. There are two modes: <literal>or</literal>:
       To parse a simple string with a FIND query use the function
      </para>
      <screen>
-struct ccl_rpn_node *ccl_find_str (CCL_bibset bibset, const char *str,
-                                   int *error, int *pos);
+struct ccl_rpn_node *ccl_find_str(CCL_bibset bibset, const char *str,
+                                  int *error, int *pos);
      </screen>
      <para>
       which takes the CCL profile (<literal>bibset</literal>) and query
@@ -1016,8 +1020,7 @@ struct ccl_rpn_node *ccl_find_str (CCL_bibset bibset, const char *str,
       </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.
@@ -1093,6 +1096,7 @@ struct cql_node *cql_parser_result(CQL_parser cp);
       <synopsis>
 #define CQL_NODE_ST 1
 #define CQL_NODE_BOOL 2
+#define CQL_NODE_SORT 3
 struct cql_node {
     int which;
     union {
@@ -1110,10 +1114,17 @@ struct cql_node {
             struct cql_node *right;
             struct cql_node *modifiers;
         } boolean;
+        struct {
+            char *index;
+            struct cql_node *next;
+            struct cql_node *modifiers;
+            struct cql_node *search;
+        } sort;
     } u;
 };
       </synopsis>
-      There are two node types: search term (ST) and boolean (BOOL).
+      There are three node types: search term (ST), boolean (BOOL)
+      and sortby (SORT).
       A modifier is treated as a search term too.
      </para>
      <para>
@@ -1158,8 +1169,8 @@ struct cql_node {
      </para>
 
      <para>
-      The boolean node represents both <literal>and</literal>,
-      <literal>or</literal>, not as well as
+      The boolean node represents <literal>and</literal>,
+      <literal>or</literal>, <literal>not</literal> +
       proximity.
       <itemizedlist>
        <listitem>
@@ -1176,6 +1187,10 @@ struct cql_node {
       </itemizedlist>
      </para>
 
+     <para>
+      The sort node represents both the SORTBY clause.
+     </para>
+
     </sect3>
     <sect3 id="cql.to.pqf"><title>CQL to PQF conversion</title>
      <para>
@@ -1219,8 +1234,8 @@ int cql_transform_buf(cql_transform_t ct,
       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
@@ -1558,6 +1573,27 @@ void cql_to_xml_stdio(struct cql_node *cn, FILE *f);
       a file.
      </para>
     </sect3>
+    <sect3 id="rpn.to.cql">
+     <title>PQF to CQL conversion</title>
+     <para>
+      Conversion from PQF to CQL is offered by the two functions shown
+      below. The former uses a generic stream for result. The latter
+      puts result in a WRBUF (string container).
+     <synopsis>
+#include &lt;yaz/rpn2cql.h>
+
+int cql_transform_rpn2cql_stream(cql_transform_t ct,
+                                 void (*pr)(const char *buf, void *client_data),
+                                 void *client_data,
+                                 Z_RPNQuery *q);
+
+int cql_transform_rpn2cql_wrbuf(cql_transform_t ct,
+                                WRBUF w,
+                                Z_RPNQuery *q);
+      </synopsis>
+      The configuration is the same as used in CQL to PQF conversions.
+     </para>
+    </sect3>
    </sect2>
   </sect1>
   <sect1 id="tools.oid"><title>Object Identifiers</title>
@@ -1969,6 +2005,7 @@ void cql_to_xml_stdio(struct cql_node *cn, FILE *f);
     #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);
@@ -2062,6 +2099,15 @@ void cql_to_xml_stdio(struct cql_node *cn, FILE *f);
       </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>
@@ -2292,8 +2338,9 @@ void cql_to_xml_stdio(struct cql_node *cn, FILE *f);
            <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>
@@ -2302,10 +2349,12 @@ void cql_to_xml_stdio(struct cql_node *cn, FILE *f);
            <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>
@@ -2413,6 +2462,56 @@ void cql_to_xml_stdio(struct cql_node *cn, FILE *f);
       </itemizedlist>
      </para>
     </example>
+
+    <example id="tools.retrieval.marcxml">
+     <title>MARCXML backend</title>
+     <para>
+      SRW/SRU and Solr backends returns records in XML.
+      If they return MARCXML or MarcXchange, the retrieval module
+      can convert those into ISO2709 formats, most commonly USMARC
+      (AKA MARC21).
+      In this example, the backend returns MARCXML for schema="marcxml".
+     </para>
+     <programlisting><![CDATA[
+     <retrievalinfo>
+       <retrieval syntax="usmarc">
+         <backend syntax="xml" name="marcxml">
+          <marc inputformat="xml" outputformat="marc"
+                outputcharset="marc-8"/>
+        </backend>
+       </retrieval>
+       <retrieval syntax="xml" name="marcxml"
+                 identifier="info:srw/schema/1/marcxml-v1.1"/>
+       <retrieval syntax="xml" name="dc">
+         <backend syntax="xml" name="marcxml">
+           <xslt stylesheet="MARC21slim2DC.xsl"/>
+        </backend>
+       </retrieval>
+     </retrievalinfo>
+]]>
+     </programlisting>
+     <para>
+      This means that our frontend supports:
+      <itemizedlist>
+       <listitem>
+        <para>
+         MARC21 records (any element set name) in MARC-8 encoding.
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         MARCXML records for element-set=marcxml
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         Dublin core records for element-set=dc.
+        </para>
+       </listitem>
+      </itemizedlist>
+     </para>
+    </example>
+
    </sect2>
    <sect2 id="tools.retrieval.api">
     <title>API</title>
@@ -2424,6 +2523,80 @@ void cql_to_xml_stdio(struct cql_node *cn, FILE *f);
     </para>
    </sect2>
   </sect1>
+  <sect1><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>
  </chapter>
 
  <!-- Keep this comment at the end of the file