doc/tools.xml

   1  <chapter id="tools"><title>Supporting Tools</title>
   2
   3   <para>
   4    In support of the service API - primarily the ASN module, which
   5    provides the pro-grammatic interface to the Z39.50 APDUs, &yaz; contains
   6    a collection of tools that support the development of applications.
   7   </para>
   8
   9   <sect1 id="tools.query"><title>Query Syntax Parsers</title>
  10
  11    <para>
  12     Since the type-1 (RPN) query structure has no direct, useful string
  13     representation, every origin application needs to provide some form of
  14     mapping from a local query notation or representation to a
  15     <token>Z_RPNQuery</token> structure. Some programmers will prefer to
  16     construct the query manually, perhaps using
  17     <function>odr_malloc()</function> to simplify memory management.
  18     The &yaz; distribution includes three separate, query-generating tools
  19     that may be of use to you.
  20    </para>
  21
  22    <sect2 id="PQF"><title>Prefix Query Format</title>
  23
  24     <para>
  25      Since RPN or reverse polish notation is really just a fancy way of
  26      describing a suffix notation format (operator follows operands), it
  27      would seem that the confusion is total when we now introduce a prefix
  28      notation for RPN. The reason is one of simple laziness - it's somewhat
  29      simpler to interpret a prefix format, and this utility was designed
  30      for maximum simplicity, to provide a baseline representation for use
  31      in simple test applications and scripting environments (like Tcl). The
  32      demonstration client included with YAZ uses the PQF.
  33     </para>
  34
  35     <note>
  36      <para>
  37       The PQF have been adopted by other parties developing Z39.50
  38       software. It is often referred to as Prefix Query Notation
  39       - PQN.
  40      </para>
  41     </note>
  42     <para>
  43      The PQF is defined by the pquery module in the YAZ library.
  44      There are two sets of function that have similar behavior. First
  45      set operates on a PQF parser handle, second set doesn't. First set
  46      set of functions are more flexible than the second set. Second set
  47      is obsolete and is only provided to ensure backwards compatibility.
  48     </para>
  49     <para>
  50      First set of functions all operate on a PQF parser handle:
  51     </para>
  52     <synopsis>
  53      #include &lt;yaz/pquery.h&gt;
  54
  55      YAZ_PQF_Parser yaz_pqf_create(void);
  56
  57      void yaz_pqf_destroy(YAZ_PQF_Parser p);
  58
  59      Z_RPNQuery *yaz_pqf_parse(YAZ_PQF_Parser p, ODR o, const char *qbuf);
  60
  61      Z_AttributesPlusTerm *yaz_pqf_scan(YAZ_PQF_Parser p, ODR o,
  62                           Odr_oid **attributeSetId, const char *qbuf);
  63
  64      int yaz_pqf_error(YAZ_PQF_Parser p, const char **msg, size_t *off);
  65     </synopsis>
  66     <para>
  67      A PQF parser is created and destructed by functions
  68      <function>yaz_pqf_create</function> and
  69      <function>yaz_pqf_destroy</function> respectively.
  70      Function <function>yaz_pqf_parse</function> parses query given
  71      by string <literal>qbuf</literal>. If parsing was successful,
  72      a Z39.50 RPN Query is returned which is created using ODR stream
  73      <literal>o</literal>. If parsing failed, a NULL pointer is
  74      returned.
  75      Function <function>yaz_pqf_scan</function> takes a scan query in
  76      <literal>qbuf</literal>. If parsing was successful, the function
  77      returns attributes plus term pointer and modifies
  78      <literal>attributeSetId</literal> to hold attribute set for the
  79      scan request - both allocated using ODR stream <literal>o</literal>.
  80      If parsing failed, yaz_pqf_scan returns a NULL pointer.
  81      Error information for bad queries can be obtained by a call to
  82      <function>yaz_pqf_error</function> which returns an error code and
  83      modifies <literal>*msg</literal> to point to an error description,
  84      and modifies <literal>*off</literal> to the offset within last
  85      query were parsing failed.
  86     </para>
  87     <para>
  88      The second set of functions are declared as follows:
  89     </para>
  90     <synopsis>
  91      #include &lt;yaz/pquery.h&gt;
  92
  93      Z_RPNQuery *p_query_rpn(ODR o, oid_proto proto, const char *qbuf);
  94
  95      Z_AttributesPlusTerm *p_query_scan(ODR o, oid_proto proto,
  96                              Odr_oid **attributeSetP, const char *qbuf);
  97
  98      int p_query_attset(const char *arg);
  99     </synopsis>
 100     <para>
 101      The function <function>p_query_rpn()</function> takes as arguments an
 102       &odr; stream (see section <link linkend="odr">The ODR Module</link>)
 103      to provide a memory source (the structure created is released on
 104      the next call to <function>odr_reset()</function> on the stream), a
 105      protocol identifier (one of the constants <token>PROTO_Z3950</token> and
 106      <token>PROTO_SR</token>), an attribute set reference, and
 107      finally a null-terminated string holding the query string.
 108     </para>
 109     <para>
 110      If the parse went well, <function>p_query_rpn()</function> returns a
 111      pointer to a <literal>Z_RPNQuery</literal> structure which can be
 112      placed directly into a <literal>Z_SearchRequest</literal>.
 113      If parsing failed, due to syntax error, a NULL pointer is returned.
 114     </para>
 115     <para>
 116      The <literal>p_query_attset</literal> specifies which attribute set
 117      to use if the query doesn't specify one by the
 118      <literal>@attrset</literal> operator.
 119      The <literal>p_query_attset</literal> returns 0 if the argument is a
 120      valid attribute set specifier; otherwise the function returns -1.
 121     </para>
 122
 123     <para>
 124      The grammar of the PQF is as follows:
 125     </para>
 126
 127     <literallayout>
 128      query ::= top-set query-struct.
 129
 130      top-set ::= [ '@attrset' string ]
 131
 132      query-struct ::= attr-spec | simple | complex | '@term' term-type query
 133
 134      attr-spec ::= '@attr' [ string ] string query-struct
 135
 136      complex ::= operator query-struct query-struct.
 137
 138      operator ::= '@and' | '@or' | '@not' | '@prox' proximity.
 139
 140      simple ::= result-set | term.
 141
 142      result-set ::= '@set' string.
 143
 144      term ::= string.
 145
 146      proximity ::= exclusion distance ordered relation which-code unit-code.
 147
 148      exclusion ::= '1' | '0' | 'void'.
 149
 150      distance ::= integer.
 151
 152      ordered ::= '1' | '0'.
 153
 154      relation ::= integer.
 155
 156      which-code ::= 'known' | 'private' | integer.
 157
 158      unit-code ::= integer.
 159
 160      term-type ::= 'general' | 'numeric' | 'string' | 'oid' | 'datetime' | 'null'.
 161     </literallayout>
 162
 163     <para>
 164      You will note that the syntax above is a fairly faithful
 165      representation of RPN, except for the Attribute, which has been
 166      moved a step away from the term, allowing you to associate one or more
 167      attributes with an entire query structure. The parser will
 168      automatically apply the given attributes to each term as required.
 169     </para>
 170
 171     <para>
 172      The @attr operator is followed by an attribute specification
 173      (<literal>attr-spec</literal> above). The specification consists
 174      of an optional attribute set, an attribute type-value pair and
 175      a sub-query. The attribute type-value pair is packed in one string:
 176      an attribute type, an equals sign, and an attribute value, like this:
 177      <literal>@attr 1=1003</literal>.
 178      The type is always an integer but the value may be either an
 179      integer or a string (if it doesn't start with a digit character).
 180      A string attribute-value is encoded as a Type-1 ``complex''
 181      attribute with the list of values containing the single string
 182      specified, and including no semantic indicators.
 183     </para>
 184
 185     <para>
 186      Version 3 of the Z39.50 specification defines various encoding of terms.
 187      Use <literal>@term </literal> <replaceable>type</replaceable>
 188      <replaceable>string</replaceable>,
 189      where type is one of: <literal>general</literal>,
 190      <literal>numeric</literal> or <literal>string</literal>
 191      (for InternationalString).
 192      If no term type has been given, the <literal>general</literal> form
 193      is used.  This is the only encoding allowed in both versions 2 and 3
 194      of the Z39.50 standard.
 195     </para>
 196
 197     <sect3 id="PQF-prox">
 198       <title>Using Proximity Operators with PQF</title>
 199       <note>
 200         <para>
 201           This is an advanced topic, describing how to construct
 202           queries that make very specific requirements on the
 203           relative location of their operands.
 204           You may wish to skip this section and go straight to
 205           <link linkend="pqf-examples">the example PQF queries</link>.
 206         </para>
 207         <para>
 208           <warning>
 209             <para>
 210               Most Z39.50 servers do not support proximity searching, or
 211               support only a small subset of the full functionality that
 212               can be expressed using the PQF proximity operator.  Be
 213               aware that the ability to <emphasis>express</emphasis> a
 214               query in PQF is no guarantee that any given server will
 215               be able to <emphasis>execute</emphasis> it.
 216             </para>
 217           </warning>
 218         </para>
 219       </note>
 220       <para>
 221         The proximity operator <literal>@prox</literal> is a special
 222         and more restrictive version of the conjunction operator
 223         <literal>@and</literal>.  Its semantics are described in
 224         section 3.7.2 (Proximity) of Z39.50 the standard itself, which
 225         can be read on-line at
 226         <ulink url="&url.z39.50.proximity;"/>
 227       </para>
 228       <para>
 229         In PQF, the proximity operation is represented by a sequence
 230         of the form
 231         <screen>
 232 @prox <replaceable>exclusion</replaceable> <replaceable>distance</replaceable> <replaceable>ordered</replaceable> <replaceable>relation</replaceable> <replaceable>which-code</replaceable> <replaceable>unit-code</replaceable>
 233         </screen>
 234         in which the meanings of the parameters are as described in in
 235         the standard, and they can take the following values:
 236         <itemizedlist>
 237           <listitem><formalpara><title>exclusion</title><para>
 238             0 = false (i.e. the proximity condition specified by the
 239             remaining parameters must be satisfied) or
 240             1 = true (the proximity condition specified by the
 241             remaining parameters must <emphasis>not</emphasis> be
 242             satisifed).
 243           </para></formalpara></listitem>
 244           <listitem><formalpara><title>distance</title><para>
 245             An integer specifying the difference between the locations
 246             of the operands: e.g. two adjacent words would have
 247             distance=1 since their locations differ by one unit.
 248           </para></formalpara></listitem>
 249           <listitem><formalpara><title>ordered</title><para>
 250             1 = ordered (the operands must occur in the order the
 251             query specifies them) or
 252             0 = unordered (they may appear in either order).
 253           </para></formalpara></listitem>
 254           <listitem><formalpara><title>relation</title><para>
 255             Recognised values are
 256             1 (lessThan),
 257             2 (lessThanOrEqual),
 258             3 (equal),
 259             4 (greaterThanOrEqual),
 260             5 (greaterThan) and
 261             6 (notEqual).
 262           </para></formalpara></listitem>
 263           <listitem><formalpara><title>which-code</title><para>
 264             <literal>known</literal>
 265             or
 266             <literal>k</literal>
 267             (the unit-code parameter is taken from the well-known list
 268             of alternatives described in below) or
 269             <literal>private</literal>
 270             or
 271             <literal>p</literal>
 272             (the unit-code paramater has semantics specific to an
 273             out-of-band agreement such as a profile).
 274           </para></formalpara></listitem>
 275           <listitem><formalpara><title>unit-code</title><para>
 276             If the which-code parameter is <literal>known</literal>
 277             then the recognised values are
 278             1 (character),
 279             2 (word),
 280             3 (sentence),
 281             4 (paragraph),
 282             5 (section),
 283             6 (chapter),
 284             7 (document),
 285             8 (element),
 286             9 (subelement),
 287             10 (elementType) and
 288             11 (byte).
 289             If which-code is <literal>private</literal> then the
 290             acceptable values are determined by the profile.
 291           </para></formalpara></listitem>
 292         </itemizedlist>
 293         (The numeric values of the relation and well-known unit-code
 294         parameters are taken straight from
 295         <ulink url="&url.z39.50.proximity.asn1;"
 296         >the ASN.1</ulink> of the proximity structure in the standard.)
 297       </para>
 298     </sect3>
 299
 300     <sect3 id="pqf-examples"><title>PQF queries</title>
 301
 302      <example id="example.pqf.simple.terms">
 303       <title>PQF queries using simple terms</title>
 304       <para>
 305        <screen>
 306         dylan
 307
 308         "bob dylan"
 309        </screen>
 310       </para>
 311      </example>
 312      <example id="pqf.example.pqf.boolean.operators">
 313       <title>PQF boolean operators</title>
 314       <para>
 315        <screen>
 316         @or "dylan" "zimmerman"
 317
 318         @and @or dylan zimmerman when
 319
 320         @and when @or dylan zimmerman
 321        </screen>
 322       </para>
 323      </example>
 324      <example id="example.pqf.result.sets">
 325       <title>PQF references to result sets</title>
 326       <para>
 327        <screen>
 328         @set Result-1
 329
 330         @and @set seta @set setb
 331        </screen>
 332       </para>
 333      </example>
 334      <example id="example.pqf.attributes">
 335       <title>Attributes for terms</title>
 336       <para>
 337        <screen>
 338         @attr 1=4 computer
 339
 340         @attr 1=4 @attr 4=1 "self portrait"
 341
 342         @attrset exp1 @attr 1=1 CategoryList
 343
 344         @attr gils 1=2008 Copenhagen
 345
 346         @attr 1=/book/title computer
 347        </screen>
 348       </para>
 349      </example>
 350      <example id="example.pqf.proximity">
 351       <title>PQF Proximity queries</title>
 352       <para>
 353        <screen>
 354         @prox 0 3 1 2 k 2 dylan zimmerman
 355        </screen>
 356        <note><para>
 357          Here the parameters 0, 3, 1, 2, k and 2 represent exclusion,
 358          distance, ordered, relation, which-code and unit-code, in that
 359          order.  So:
 360          <itemizedlist>
 361           <listitem><para>
 362             exclusion = 0: the proximity condition must hold
 363            </para></listitem>
 364           <listitem><para>
 365             distance = 3: the terms must be three units apart
 366            </para></listitem>
 367           <listitem><para>
 368             ordered = 1: they must occur in the order they are specified
 369            </para></listitem>
 370           <listitem><para>
 371             relation = 2: lessThanOrEqual (to the distance of 3 units)
 372            </para></listitem>
 373           <listitem><para>
 374             which-code is ``known'', so the standard unit-codes are used
 375            </para></listitem>
 376           <listitem><para>
 377             unit-code = 2: word.
 378            </para></listitem>
 379          </itemizedlist>
 380          So the whole proximity query means that the words
 381          <literal>dylan</literal> and <literal>zimmerman</literal> must
 382          both occur in the record, in that order, differing in position
 383          by three or fewer words (i.e. with two or fewer words between
 384          them.)  The query would find ``Bob Dylan, aka. Robert
 385          Zimmerman'', but not ``Bob Dylan, born as Robert Zimmerman''
 386          since the distance in this case is four.
 387         </para></note>
 388       </para>
 389      </example>
 390      <example id="example.pqf.search.term.type">
 391       <title>PQF specification of search term type</title>
 392       <para>
 393        <screen>
 394         @term string "a UTF-8 string, maybe?"
 395        </screen>
 396       </para>
 397      </example>
 398      <example id="example.pqf.mixed.queries">
 399       <title>PQF mixed queries</title>
 400       <para>
 401        <screen>
 402         @or @and bob dylan @set Result-1
 403
 404         @attr 4=1 @and @attr 1=1 "bob dylan" @attr 1=4 "slow train coming"
 405
 406         @and @attr 2=4 @attr gils 1=2038 -114 @attr 2=2 @attr gils 1=2039 -109
 407       </screen>
 408        <note>
 409         <para>
 410          The last of these examples is a spatial search: in
 411          <ulink url="http://www.gils.net/prof_v2.html#sec_7_4"
 412           >the GILS attribute set</ulink>,
 413          access point
 414          2038 indicates West Bounding Coordinate and
 415          2030 indicates East Bounding Coordinate,
 416          so the query is for areas extending from -114 degrees
 417          to no more than -109 degrees.
 418         </para>
 419        </note>
 420       </para>
 421      </example>
 422     </sect3>
 423    </sect2>
 424    <sect2 id="CCL"><title>CCL</title>
 425
 426     <para>
 427      Not all users enjoy typing in prefix query structures and numerical
 428      attribute values, even in a minimalistic test client. In the library
 429      world, the more intuitive Common Command Language - CCL (ISO 8777)
 430      has enjoyed some popularity - especially before the widespread
 431      availability of graphical interfaces. It is still useful in
 432      applications where you for some reason or other need to provide a
 433      symbolic language for expressing boolean query structures.
 434     </para>
 435
 436     <sect3 id="ccl.syntax">
 437      <title>CCL Syntax</title>
 438
 439      <para>
 440       The CCL parser obeys the following grammar for the FIND argument.
 441       The syntax is annotated by in the lines prefixed by
 442       <literal>--</literal>.
 443      </para>
 444
 445      <screen>
 446       CCL-Find ::= CCL-Find Op Elements
 447                 | Elements.
 448
 449       Op ::= "and" | "or" | "not"
 450       -- The above means that Elements are separated by boolean operators.
 451
 452       Elements ::= '(' CCL-Find ')'
 453                 | Set
 454                 | Terms
 455                 | Qualifiers Relation Terms
 456                 | Qualifiers Relation '(' CCL-Find ')'
 457                 | Qualifiers '=' string '-' string
 458       -- Elements is either a recursive definition, a result set reference, a
 459       -- list of terms, qualifiers followed by terms, qualifiers followed
 460       -- by a recursive definition or qualifiers in a range (lower - upper).
 461
 462       Set ::= 'set' = string
 463       -- Reference to a result set
 464
 465       Terms ::= Terms Prox Term
 466              | Term
 467       -- Proximity of terms.
 468
 469       Term ::= Term string
 470             | string
 471       -- This basically means that a term may include a blank
 472
 473       Qualifiers ::= Qualifiers ',' string
 474                   | string
 475       -- Qualifiers is a list of strings separated by comma
 476
 477       Relation ::= '=' | '>=' | '&lt;=' | '&lt;>' | '>' | '&lt;'
 478       -- Relational operators. This really doesn't follow the ISO8777
 479       -- standard.
 480
 481       Prox ::= '%' | '!'
 482       -- Proximity operator
 483
 484      </screen>
 485
 486      <example id="example.ccl.queries">
 487       <title>CCL queries</title>
 488       <para>
 489        The following queries are all valid:
 490       </para>
 491
 492       <screen>
 493        dylan
 494
 495        "bob dylan"
 496
 497        dylan or zimmerman
 498
 499        set=1
 500
 501        (dylan and bob) or set=1
 502
 503        righttrunc?
 504
 505        "notrunc?"
 506
 507        singlechar#mask
 508
 509       </screen>
 510       <para>
 511        Assuming that the qualifiers <literal>ti</literal>,
 512        <literal>au</literal>
 513        and <literal>date</literal> are defined we may use:
 514       </para>
 515
 516       <screen>
 517        ti=self portrait
 518
 519        au=(bob dylan and slow train coming)
 520
 521        date>1980 and (ti=((self portrait)))
 522
 523       </screen>
 524      </example>
 525
 526     </sect3>
 527     <sect3 id="ccl.qualifiers">
 528      <title>CCL Qualifiers</title>
 529
 530      <para>
 531       Qualifiers are used to direct the search to a particular searchable
 532       index, such as title (ti) and author indexes (au). The CCL standard
 533       itself doesn't specify a particular set of qualifiers, but it does
 534       suggest a few short-hand notations. You can customize the CCL parser
 535       to support a particular set of qualifiers to reflect the current target
 536       profile. Traditionally, a qualifier would map to a particular
 537       use-attribute within the BIB-1 attribute set. It is also
 538       possible to set other attributes, such as the structure
 539       attribute.
 540      </para>
 541
 542      <para>
 543       A  CCL profile is a set of predefined CCL qualifiers that may be
 544       read from a file or set in the CCL API.
 545       The YAZ client reads its CCL qualifiers from a file named
 546       <filename>default.bib</filename>. There are four types of
 547       lines in a CCL profile: qualifier specification,
 548       qualifier alias, comments and directives.
 549      </para>
 550      <sect4 id="ccl.qualifier.specification">
 551       <title>Qualifier specification</title>
 552       <para>
 553        A qualifier specification is of the form:
 554       </para>
 555
 556       <para>
 557        <replaceable>qualifier-name</replaceable>
 558        [<replaceable>attributeset</replaceable><literal>,</literal>]<replaceable>type</replaceable><literal>=</literal><replaceable>val</replaceable>
 559        [<replaceable>attributeset</replaceable><literal>,</literal>]<replaceable>type</replaceable><literal>=</literal><replaceable>val</replaceable> ...
 560       </para>
 561
 562       <para>
 563        where <replaceable>qualifier-name</replaceable> is the name of the
 564        qualifier to be used (eg. <literal>ti</literal>),
 565        <replaceable>type</replaceable> is attribute type in the attribute
 566        set (Bib-1 is used if no attribute set is given) and
 567        <replaceable>val</replaceable> is attribute value.
 568        The <replaceable>type</replaceable> can be specified as an
 569        integer or as it be specified either as a single-letter:
 570        <literal>u</literal> for use,
 571        <literal>r</literal> for relation,<literal>p</literal> for position,
 572        <literal>s</literal> for structure,<literal>t</literal> for truncation
 573        or <literal>c</literal> for completeness.
 574        The attributes for the special qualifier name <literal>term</literal>
 575        are used when no CCL qualifier is given in a query.
 576        <table id="ccl.common.bib1.attributes">
 577         <title>Common Bib-1 attributes</title>
 578         <tgroup cols="2">
 579          <colspec colwidth="2*" colname="type"></colspec>
 580          <colspec colwidth="9*" colname="description"></colspec>
 581          <thead>
 582           <row>
 583            <entry>Type</entry>
 584            <entry>Description</entry>
 585           </row>
 586          </thead>
 587          <tbody>
 588           <row>
 589            <entry><literal>u=</literal><replaceable>value</replaceable></entry>
 590            <entry>
 591             Use attribute (1). Common use attributes are
 592             1 Personal-name, 4 Title, 7 ISBN, 8 ISSN, 30 Date,
 593             62 Subject, 1003 Author), 1016 Any. Specify value
 594             as an integer.
 595            </entry>
 596           </row>
 597
 598           <row>
 599            <entry><literal>r=</literal><replaceable>value</replaceable></entry>
 600            <entry>
 601             Relation attribute (2). Common values are
 602             1 &lt;, 2 &lt;=, 3 =, 4 &gt;=, 5 &gt;, 6 &lt;&gt;,
 603             100 phonetic, 101 stem, 102 relevance, 103 always matches.
 604            </entry>
 605           </row>
 606
 607           <row>
 608            <entry><literal>p=</literal><replaceable>value</replaceable></entry>
 609            <entry>
 610             Position attribute (3). Values: 1 first in field, 2
 611             first in any subfield, 3 any position in field.
 612            </entry>
 613           </row>
 614
 615           <row>
 616            <entry><literal>s=</literal><replaceable>value</replaceable></entry>
 617            <entry>
 618             Structure attribute (4). Values: 1 phrase, 2 word,
 619             3 key, 4 year, 5 date, 6 word list, 100 date (un),
 620             101 name (norm), 102 name (un), 103 structure, 104 urx,
 621             105 free-form-text, 106 document-text, 107 local-number,
 622             108 string, 109 numeric string.
 623            </entry>
 624           </row>
 625
 626           <row>
 627            <entry><literal>t=</literal><replaceable>value</replaceable></entry>
 628            <entry>
 629             Truncation attribute (5). Values: 1 right, 2 left,
 630             3 left&amp; right, 100 none, 101 process #, 102 regular-1,
 631             103 regular-2, 104 CCL.
 632            </entry>
 633           </row>
 634
 635           <row>
 636            <entry><literal>c=</literal><replaceable>value</replaceable></entry>
 637            <entry>
 638             Completeness attribute (6). Values: 1 incomplete subfield,
 639             2 complete subfield, 3 complete field.
 640            </entry>
 641           </row>
 642
 643          </tbody>
 644          </tgroup>
 645         </table>
 646       </para>
 647       <para>
 648        Refer to <xref linkend="bib1"/> or the complete
 649        <ulink url="&url.z39.50.attset.bib1;">list of Bib-1 attributes</ulink>
 650       </para>
 651       <para>
 652        It is also possible to specify non-numeric attribute values,
 653        which are used in combination with certain types.
 654        The special combinations are:
 655
 656        <table id="ccl.special.attribute.combos">
 657         <title>Special attribute combos</title>
 658         <tgroup cols="2">
 659          <colspec colwidth="2*" colname="name"></colspec>
 660          <colspec colwidth="9*" colname="description"></colspec>
 661          <thead>
 662           <row>
 663            <entry>Name</entry>
 664            <entry>Description</entry>
 665           </row>
 666          </thead>
 667          <tbody>
 668           <row>
 669            <entry><literal>s=pw</literal></entry><entry>
 670             The structure is set to either word or phrase depending
 671             on the number of tokens in a term (phrase-word).
 672            </entry>
 673           </row>
 674           <row>
 675            <entry><literal>s=al</literal></entry><entry>
 676             Each token in the term is ANDed. (and-list).
 677             This does not set the structure at all.
 678            </entry>
 679           </row>
 680
 681           <row><entry><literal>s=ol</literal></entry><entry>
 682             Each token in the term is ORed. (or-list).
 683             This does not set the structure at all.
 684            </entry>
 685           </row>
 686
 687           <row><entry><literal>s=ag</literal></entry><entry>
 688             Tokens that appears as phrases (with blank in them) gets
 689             structure phrase attached (4=1). Tokens that appear to be words
 690             gets structure word attached (4=2). Phrases and words are
 691             ANDed. This is a variant of s=al and s=pw, with the main
 692             difference that words are not split (with operator AND)
 693             but instead kept in one RPN token. This facility appeared
 694             in YAZ 4.2.38.
 695            </entry>
 696           </row>
 697
 698           <row><entry><literal>r=o</literal></entry><entry>
 699             Allows ranges and the operators greather-than, less-than, ...
 700             equals.
 701             This sets Bib-1 relation attribute accordingly (relation
 702             ordered). A query construct is only treated as a range if
 703             dash is used and that is surrounded by white-space. So
 704             <literal>-1980</literal> is treated as term
 705             <literal>"-1980"</literal> not <literal>&lt;= 1980</literal>.
 706             If <literal>- 1980</literal> is used, however, that is
 707             treated as a range.
 708            </entry>
 709           </row>
 710
 711           <row><entry><literal>r=r</literal></entry><entry>
 712             Similar to <literal>r=o</literal> but assumes that terms
 713             are non-negative (not prefixed with <literal>-</literal>).
 714             Thus, a dash will always be treated as a range.
 715             The construct <literal>1980-1990</literal> is
 716             treated as a range with <literal>r=r</literal> but as a
 717             single term <literal>"1980-1990"</literal> with
 718             <literal>r=o</literal>. The special attribute
 719             <literal>r=r</literal> is available in YAZ 2.0.24 or later.
 720            </entry>
 721           </row>
 722
 723           <row><entry><literal>t=l</literal></entry><entry>
 724             Allows term to be left-truncated.
 725             If term is of the form <literal>?x</literal>, the resulting
 726             Type-1 term is <literal>x</literal> and truncation is left.
 727            </entry>
 728           </row>
 729
 730           <row><entry><literal>t=r</literal></entry><entry>
 731             Allows term to be right-truncated.
 732             If term is of the form <literal>x?</literal>, the resulting
 733             Type-1 term is <literal>x</literal> and truncation is right.
 734            </entry>
 735           </row>
 736
 737           <row><entry><literal>t=n</literal></entry><entry>
 738             If term is does not include <literal>?</literal>, the
 739             truncation attribute is set to none (100).
 740            </entry>
 741           </row>
 742
 743           <row><entry><literal>t=b</literal></entry><entry>
 744             Allows term to be both left&amp;right truncated.
 745             If term is of the form <literal>?x?</literal>, the
 746             resulting term is <literal>x</literal> and trunctation is
 747             set to both left&amp;right.
 748            </entry>
 749           </row>
 750
 751           <row><entry><literal>t=x</literal></entry><entry>
 752             Allows masking anywhere in a term, thus fully supporting
 753             # (mask one character) and ? (zero or more of any).
 754             If masking is used, trunction is set to 102 (regexp-1 in term)
 755             and the term is converted accordingly to a regular expression.
 756            </entry>
 757           </row>
 758
 759           <row><entry><literal>t=z</literal></entry><entry>
 760             Allows masking anywhere in a term, thus fully supporting
 761             # (mask one character) and ? (zero or more of any).
 762             If masking is used, trunction is set to 104 (Z39.58 in term)
 763             and the term is converted accordingly to Z39.58 masking term -
 764             actually the same truncation as CCL itself.
 765            </entry>
 766           </row>
 767
 768          </tbody>
 769         </tgroup>
 770        </table>
 771       </para>
 772       <example id="example.ccl.profile"><title>CCL profile</title>
 773        <para>
 774         Consider the following definition:
 775        </para>
 776
 777        <screen>
 778         ti       u=4 s=1
 779         au       u=1 s=1
 780         term     s=105
 781         ranked   r=102
 782         date     u=30 r=o
 783       </screen>
 784        <para>
 785         <literal>ti</literal> and <literal>au</literal> both set
 786         structure attribute to phrase (s=1).
 787         <literal>ti</literal>
 788         sets the use-attribute to 4. <literal>au</literal> sets the
 789         use-attribute to 1.
 790         When no qualifiers are used in the query the structure-attribute is
 791         set to free-form-text (105) (rule for <literal>term</literal>).
 792         The <literal>date</literal> sets the relation attribute to
 793         the relation used in the CCL query and sets the use attribute
 794         to 30 (Bib-1 Date).
 795        </para>
 796        <para>
 797         You can combine attributes. To Search for "ranked title" you
 798         can do
 799         <screen>
 800          ti,ranked=knuth computer
 801         </screen>
 802         which will set relation=ranked, use=title, structure=phrase.
 803        </para>
 804        <para>
 805         Query
 806         <screen>
 807          date > 1980
 808         </screen>
 809         is a valid query. But
 810         <screen>
 811          ti > 1980
 812         </screen>
 813         is invalid.
 814        </para>
 815       </example>
 816      </sect4>
 817      <sect4 id="ccl.qualifier.alias">
 818       <title>Qualifier alias</title>
 819       <para>
 820        A qualifier alias is of the form:
 821       </para>
 822       <para>
 823        <replaceable>q</replaceable>
 824        <replaceable>q1</replaceable> <replaceable>q2</replaceable> ..
 825       </para>
 826       <para>
 827        which declares <replaceable>q</replaceable> to
 828        be an alias for <replaceable>q1</replaceable>,
 829        <replaceable>q2</replaceable>... such that the CCL
 830        query <replaceable>q=x</replaceable> is equivalent to
 831        <replaceable>q1=x or q2=x or ...</replaceable>.
 832       </para>
 833      </sect4>
 834
 835      <sect4 id="ccl.comments">
 836       <title>Comments</title>
 837       <para>
 838        Lines with white space or lines that begin with
 839        character <literal>#</literal> are treated as comments.
 840       </para>
 841      </sect4>
 842
 843      <sect4 id="ccl.directives">
 844       <title>Directives</title>
 845       <para>
 846        Directive specifications takes the form
 847       </para>
 848       <para><literal>@</literal><replaceable>directive</replaceable> <replaceable>value</replaceable>
 849       </para>
 850       <table id="ccl.directives.table">
 851        <title>CCL directives</title>
 852        <tgroup cols="3">
 853         <colspec colwidth="2*" colname="name"></colspec>
 854         <colspec colwidth="8*" colname="description"></colspec>
 855         <colspec colwidth="1*" colname="default"></colspec>
 856         <thead>
 857          <row>
 858           <entry>Name</entry>
 859           <entry>Description</entry>
 860           <entry>Default</entry>
 861          </row>
 862         </thead>
 863         <tbody>
 864          <row>
 865           <entry>truncation</entry>
 866           <entry>Truncation character</entry>
 867           <entry><literal>?</literal></entry>
 868          </row>
 869          <row>
 870           <entry>mask</entry>
 871           <entry>Masking character. Requires YAZ 4.2.58 or later</entry>
 872           <entry><literal>#</literal></entry>
 873          </row>
 874          <row>
 875           <entry>field</entry>
 876           <entry>Specifies how multiple fields are to be
 877            combined. There are two modes: <literal>or</literal>:
 878            multiple qualifier fields are ORed,
 879            <literal>merge</literal>: attributes for the qualifier
 880            fields are merged and assigned to one term.
 881            </entry>
 882           <entry><literal>merge</literal></entry>
 883          </row>
 884          <row>
 885           <entry>case</entry>
 886           <entry>Specifies if CCL operators and qualifiers should be
 887            compared with case sensitivity or not. Specify 1 for
 888            case sensitive; 0 for case insensitive.</entry>
 889           <entry><literal>1</literal></entry>
 890          </row>
 891
 892          <row>
 893           <entry>and</entry>
 894           <entry>Specifies token for CCL operator AND.</entry>
 895           <entry><literal>and</literal></entry>
 896          </row>
 897
 898          <row>
 899           <entry>or</entry>
 900           <entry>Specifies token for CCL operator OR.</entry>
 901           <entry><literal>or</literal></entry>
 902          </row>
 903
 904          <row>
 905           <entry>not</entry>
 906           <entry>Specifies token for CCL operator NOT.</entry>
 907           <entry><literal>not</literal></entry>
 908          </row>
 909
 910          <row>
 911           <entry>set</entry>
 912           <entry>Specifies token for CCL operator SET.</entry>
 913           <entry><literal>set</literal></entry>
 914          </row>
 915         </tbody>
 916         </tgroup>
 917       </table>
 918      </sect4>
 919     </sect3>
 920     <sect3 id="ccl.api">
 921      <title>CCL API</title>
 922      <para>
 923       All public definitions can be found in the header file
 924       <filename>ccl.h</filename>. A profile identifier is of type
 925       <literal>CCL_bibset</literal>. A profile must be created with the call
 926       to the function <function>ccl_qual_mk</function> which returns a profile
 927       handle of type <literal>CCL_bibset</literal>.
 928      </para>
 929
 930      <para>
 931       To read a file containing qualifier definitions the function
 932       <function>ccl_qual_file</function> may be convenient. This function
 933       takes an already opened <literal>FILE</literal> handle pointer as
 934       argument along with a <literal>CCL_bibset</literal> handle.
 935      </para>
 936
 937      <para>
 938       To parse a simple string with a FIND query use the function
 939      </para>
 940      <screen>
 941 struct ccl_rpn_node *ccl_find_str(CCL_bibset bibset, const char *str,
 942                                   int *error, int *pos);
 943      </screen>
 944      <para>
 945       which takes the CCL profile (<literal>bibset</literal>) and query
 946       (<literal>str</literal>) as input. Upon successful completion the RPN
 947       tree is returned. If an error occur, such as a syntax error, the integer
 948       pointed to by <literal>error</literal> holds the error code and
 949       <literal>pos</literal> holds the offset inside query string in which
 950       the parsing failed.
 951      </para>
 952
 953      <para>
 954       An English representation of the error may be obtained by calling
 955       the <literal>ccl_err_msg</literal> function. The error codes are
 956       listed in <filename>ccl.h</filename>.
 957      </para>
 958
 959      <para>
 960       To convert the CCL RPN tree (type
 961       <literal>struct ccl_rpn_node *</literal>)
 962       to the Z_RPNQuery of YAZ the function <function>ccl_rpn_query</function>
 963       must be used. This function which is part of YAZ is implemented in
 964       <filename>yaz-ccl.c</filename>.
 965       After calling this function the CCL RPN tree is probably no longer
 966       needed. The <literal>ccl_rpn_delete</literal> destroys the CCL RPN tree.
 967      </para>
 968
 969      <para>
 970       A CCL profile may be destroyed by calling the
 971       <function>ccl_qual_rm</function> function.
 972      </para>
 973
 974      <para>
 975       The token names for the CCL operators may be changed by setting the
 976       globals (all type <literal>char *</literal>)
 977       <literal>ccl_token_and</literal>, <literal>ccl_token_or</literal>,
 978       <literal>ccl_token_not</literal> and <literal>ccl_token_set</literal>.
 979       An operator may have aliases, i.e. there may be more than one name for
 980       the operator. To do this, separate each alias with a space character.
 981      </para>
 982     </sect3>
 983    </sect2>
 984    <sect2 id="cql"><title>CQL</title>
 985     <para>
 986      <ulink url="&url.cql;">CQL</ulink>
 987       - Common Query Language - was defined for the
 988      <ulink url="&url.sru;">SRU</ulink> protocol.
 989      In many ways CQL has a similar syntax to CCL.
 990      The objective of CQL is different. Where CCL aims to be
 991      an end-user language, CQL is <emphasis>the</emphasis> protocol
 992      query language for SRU.
 993     </para>
 994     <tip>
 995      <para>
 996       If you are new to CQL, read the
 997       <ulink url="&url.cql.intro;">Gentle Introduction</ulink>.
 998      </para>
 999     </tip>
1000     <para>
1001      The CQL parser in &yaz; provides the following:
1002      <itemizedlist>
1003       <listitem>
1004        <para>
1005         It parses and validates a CQL query.
1006        </para>
1007       </listitem>
1008       <listitem>
1009        <para>
1010         It generates a C structure that allows you to convert
1011         a CQL query to some other query language, such as SQL.
1012        </para>
1013       </listitem>
1014       <listitem>
1015        <para>
1016         The parser converts a valid CQL query to PQF, thus providing a
1017         way to use CQL for both SRU servers and Z39.50 targets at the
1018         same time.
1019        </para>
1020       </listitem>
1021       <listitem>
1022        <para>
1023         The parser converts CQL to
1024         <ulink url="&url.xcql;">XCQL</ulink>.
1025         XCQL is an XML representation of CQL.
1026         XCQL is part of the SRU specification. However, since SRU
1027         supports CQL only, we don't expect XCQL to be widely used.
1028         Furthermore, CQL has the advantage over XCQL that it is
1029         easy to read.
1030        </para>
1031       </listitem>
1032      </itemizedlist>
1033     </para>
1034     <sect3 id="cql.parsing"><title>CQL parsing</title>
1035      <para>
1036       A CQL parser is represented by the <literal>CQL_parser</literal>
1037       handle. Its contents should be considered &yaz; internal (private).
1038       <synopsis>
1039 #include &lt;yaz/cql.h&gt;
1040
1041 typedef struct cql_parser *CQL_parser;
1042
1043 CQL_parser cql_parser_create(void);
1044 void cql_parser_destroy(CQL_parser cp);
1045       </synopsis>
1046      A parser is created by <function>cql_parser_create</function> and
1047      is destroyed by <function>cql_parser_destroy</function>.
1048      </para>
1049      <para>
1050       To parse a CQL query string, the following function
1051       is provided:
1052       <synopsis>
1053 int cql_parser_string(CQL_parser cp, const char *str);
1054       </synopsis>
1055       A CQL query is parsed by the <function>cql_parser_string</function>
1056       which takes a query <parameter>str</parameter>.
1057       If the query was valid (no syntax errors), then zero is returned;
1058       otherwise -1 is returned to indicate a syntax error.
1059      </para>
1060      <para>
1061       <synopsis>
1062 int cql_parser_stream(CQL_parser cp,
1063                       int (*getbyte)(void *client_data),
1064                       void (*ungetbyte)(int b, void *client_data),
1065                       void *client_data);
1066
1067 int cql_parser_stdio(CQL_parser cp, FILE *f);
1068       </synopsis>
1069       The functions <function>cql_parser_stream</function> and
1070       <function>cql_parser_stdio</function> parses a CQL query
1071       - just like <function>cql_parser_string</function>.
1072       The only difference is that the CQL query can be
1073       fed to the parser in different ways.
1074       The <function>cql_parser_stream</function> uses a generic
1075       byte stream as input. The <function>cql_parser_stdio</function>
1076       uses a <literal>FILE</literal> handle which is opened for reading.
1077      </para>
1078     </sect3>
1079
1080     <sect3 id="cql.tree"><title>CQL tree</title>
1081      <para>
1082       The the query string is valid, the CQL parser
1083       generates a tree representing the structure of the
1084       CQL query.
1085      </para>
1086      <para>
1087       <synopsis>
1088 struct cql_node *cql_parser_result(CQL_parser cp);
1089       </synopsis>
1090       <function>cql_parser_result</function> returns the
1091       a pointer to the root node of the resulting tree.
1092      </para>
1093      <para>
1094       Each node in a CQL tree is represented by a
1095       <literal>struct cql_node</literal>.
1096       It is defined as follows:
1097       <synopsis>
1098 #define CQL_NODE_ST 1
1099 #define CQL_NODE_BOOL 2
1100 #define CQL_NODE_SORT 3
1101 struct cql_node {
1102     int which;
1103     union {
1104         struct {
1105             char *index;
1106             char *index_uri;
1107             char *term;
1108             char *relation;
1109             char *relation_uri;
1110             struct cql_node *modifiers;
1111         } st;
1112         struct {
1113             char *value;
1114             struct cql_node *left;
1115             struct cql_node *right;
1116             struct cql_node *modifiers;
1117         } boolean;
1118         struct {
1119             char *index;
1120             struct cql_node *next;
1121             struct cql_node *modifiers;
1122             struct cql_node *search;
1123         } sort;
1124     } u;
1125 };
1126       </synopsis>
1127       There are three node types: search term (ST), boolean (BOOL)
1128       and sortby (SORT).
1129       A modifier is treated as a search term too.
1130      </para>
1131      <para>
1132       The search term node has five members:
1133       <itemizedlist>
1134        <listitem>
1135         <para>
1136          <literal>index</literal>: index for search term.
1137          If an index is unspecified for a search term,
1138          <literal>index</literal> will be NULL.
1139         </para>
1140        </listitem>
1141        <listitem>
1142         <para>
1143          <literal>index_uri</literal>: index URi for search term
1144          or NULL if none could be resolved for the index.
1145         </para>
1146        </listitem>
1147        <listitem>
1148         <para>
1149          <literal>term</literal>: the search term itself.
1150         </para>
1151        </listitem>
1152        <listitem>
1153         <para>
1154          <literal>relation</literal>: relation for search term.
1155         </para>
1156        </listitem>
1157        <listitem>
1158         <para>
1159          <literal>relation_uri</literal>: relation URI for search term.
1160         </para>
1161        </listitem>
1162        <listitem>
1163         <para>
1164          <literal>modifiers</literal>: relation modifiers for search
1165          term. The <literal>modifiers</literal> list itself of cql_nodes
1166          each of type <literal>ST</literal>.
1167         </para>
1168        </listitem>
1169       </itemizedlist>
1170      </para>
1171
1172      <para>
1173       The boolean node represents <literal>and</literal>,
1174       <literal>or</literal>, <literal>not</literal> +
1175       proximity.
1176       <itemizedlist>
1177        <listitem>
1178         <para>
1179          <literal>left</literal> and <literal>right</literal>: left
1180          - and right operand respectively.
1181         </para>
1182        </listitem>
1183        <listitem>
1184         <para>
1185          <literal>modifiers</literal>: proximity arguments.
1186         </para>
1187        </listitem>
1188       </itemizedlist>
1189      </para>
1190
1191      <para>
1192       The sort node represents both the SORTBY clause.
1193      </para>
1194
1195     </sect3>
1196     <sect3 id="cql.to.pqf"><title>CQL to PQF conversion</title>
1197      <para>
1198       Conversion to PQF (and Z39.50 RPN) is tricky by the fact
1199       that the resulting RPN depends on the Z39.50 target
1200       capabilities (combinations of supported attributes).
1201       In addition, the CQL and SRU operates on index prefixes
1202       (URI or strings), whereas the RPN uses Object Identifiers
1203       for attribute sets.
1204      </para>
1205      <para>
1206       The CQL library of &yaz; defines a <literal>cql_transform_t</literal>
1207       type. It represents a particular mapping between CQL and RPN.
1208       This handle is created and destroyed by the functions:
1209      <synopsis>
1210 cql_transform_t cql_transform_open_FILE (FILE *f);
1211 cql_transform_t cql_transform_open_fname(const char *fname);
1212 void cql_transform_close(cql_transform_t ct);
1213       </synopsis>
1214       The first two functions create a tranformation handle from
1215       either an already open FILE or from a filename respectively.
1216      </para>
1217      <para>
1218       The handle is destroyed by <function>cql_transform_close</function>
1219       in which case no further reference of the handle is allowed.
1220      </para>
1221      <para>
1222       When a <literal>cql_transform_t</literal> handle has been created
1223       you can convert to RPN.
1224       <synopsis>
1225 int cql_transform_buf(cql_transform_t ct,
1226                       struct cql_node *cn, char *out, int max);
1227       </synopsis>
1228       This function converts the CQL tree <literal>cn</literal>
1229       using handle <literal>ct</literal>.
1230       For the resulting PQF, you supply a buffer <literal>out</literal>
1231       which must be able to hold at at least <literal>max</literal>
1232       characters.
1233      </para>
1234      <para>
1235       If conversion failed, <function>cql_transform_buf</function>
1236       returns a non-zero SRU error code; otherwise zero is returned
1237       (conversion successful).  The meanings of the numeric error
1238       codes are listed in the SRU specifications at
1239       <ulink url="&url.sru.diagnostics.list;"/>
1240      </para>
1241      <para>
1242       If conversion fails, more information can be obtained by calling
1243       <synopsis>
1244 int cql_transform_error(cql_transform_t ct, char **addinfop);
1245       </synopsis>
1246       This function returns the most recently returned numeric
1247       error-code and sets the string-pointer at
1248       <literal>*addinfop</literal> to point to a string containing
1249       additional information about the error that occurred: for
1250       example, if the error code is 15 (``Illegal or unsupported context
1251       set''), the additional information is the name of the requested
1252       context set that was not recognised.
1253      </para>
1254      <para>
1255       The SRU error-codes may be translated into brief human-readable
1256       error messages using
1257       <synopsis>
1258 const char *cql_strerror(int code);
1259       </synopsis>
1260      </para>
1261      <para>
1262       If you wish to be able to produce a PQF result in a different
1263       way, there are two alternatives.
1264       <synopsis>
1265 void cql_transform_pr(cql_transform_t ct,
1266                       struct cql_node *cn,
1267                       void (*pr)(const char *buf, void *client_data),
1268                       void *client_data);
1269
1270 int cql_transform_FILE(cql_transform_t ct,
1271                        struct cql_node *cn, FILE *f);
1272       </synopsis>
1273       The former function produces output to a user-defined
1274       output stream. The latter writes the result to an already
1275       open <literal>FILE</literal>.
1276      </para>
1277     </sect3>
1278     <sect3 id="cql.to.rpn">
1279      <title>Specification of CQL to RPN mappings</title>
1280      <para>
1281       The file supplied to functions
1282       <function>cql_transform_open_FILE</function>,
1283       <function>cql_transform_open_fname</function> follows
1284       a structure found in many Unix utilities.
1285       It consists of mapping specifications - one per line.
1286       Lines starting with <literal>#</literal> are ignored (comments).
1287      </para>
1288      <para>
1289       Each line is of the form
1290       <literallayout>
1291        <replaceable>CQL pattern</replaceable><literal> = </literal> <replaceable> RPN equivalent</replaceable>
1292       </literallayout>
1293      </para>
1294      <para>
1295       An RPN pattern is a simple attribute list. Each attribute pair
1296       takes the form:
1297       <literallayout>
1298        [<replaceable>set</replaceable>] <replaceable>type</replaceable><literal>=</literal><replaceable>value</replaceable>
1299       </literallayout>
1300       The attribute <replaceable>set</replaceable> is optional.
1301       The <replaceable>type</replaceable> is the attribute type,
1302       <replaceable>value</replaceable> the attribute value.
1303      </para>
1304      <para>
1305       The character <literal>*</literal> (asterisk) has special meaning
1306       when used in the RPN pattern.
1307       Each occurrence of <literal>*</literal> is substituted with the
1308       CQL matching name (index, relation, qualifier etc).
1309       This facility can be used to copy a CQL name verbatim to the RPN result.
1310      </para>
1311      <para>
1312       The following CQL patterns are recognized:
1313       <variablelist>
1314        <varlistentry><term>
1315          <literal>index.</literal><replaceable>set</replaceable><literal>.</literal><replaceable>name</replaceable>
1316         </term>
1317         <listitem>
1318          <para>
1319           This pattern is invoked when a CQL index, such as
1320           dc.title is converted. <replaceable>set</replaceable>
1321           and <replaceable>name</replaceable> are the context set and index
1322           name respectively.
1323           Typically, the RPN specifies an equivalent use attribute.
1324          </para>
1325          <para>
1326           For terms not bound by an index the pattern
1327           <literal>index.cql.serverChoice</literal> is used.
1328           Here, the prefix <literal>cql</literal> is defined as
1329           <literal>http://www.loc.gov/zing/cql/cql-indexes/v1.0/</literal>.
1330           If this pattern is not defined, the mapping will fail.
1331          </para>
1332          <para>
1333           The pattern,
1334           <literal>index.</literal><replaceable>set</replaceable><literal>.*</literal>
1335           is used when no other index pattern is matched.
1336         </para>
1337         </listitem>
1338        </varlistentry>
1339        <varlistentry><term>
1340          <literal>qualifier.</literal><replaceable>set</replaceable><literal>.</literal><replaceable>name</replaceable>
1341          (DEPRECATED)
1342         </term>
1343         <listitem>
1344          <para>
1345           For backwards compatibility, this is recognised as a synonym of
1346           <literal>index.</literal><replaceable>set</replaceable><literal>.</literal><replaceable>name</replaceable>
1347          </para>
1348         </listitem>
1349        </varlistentry>
1350        <varlistentry><term>
1351          <literal>relation.</literal><replaceable>relation</replaceable>
1352         </term>
1353         <listitem>
1354          <para>
1355           This pattern specifies how a CQL relation is mapped to RPN.
1356           <replaceable>pattern</replaceable> is name of relation
1357           operator. Since <literal>=</literal> is used as
1358           separator between CQL pattern and RPN, CQL relations
1359           including <literal>=</literal> cannot be
1360           used directly. To avoid a conflict, the names
1361           <literal>ge</literal>,
1362           <literal>eq</literal>,
1363           <literal>le</literal>,
1364           must be used for CQL operators, greater-than-or-equal,
1365           equal, less-than-or-equal respectively.
1366           The RPN pattern is supposed to include a relation attribute.
1367          </para>
1368          <para>
1369           For terms not bound by a relation, the pattern
1370           <literal>relation.scr</literal> is used. If the pattern
1371           is not defined, the mapping will fail.
1372          </para>
1373          <para>
1374           The special pattern, <literal>relation.*</literal> is used
1375           when no other relation pattern is matched.
1376          </para>
1377         </listitem>
1378        </varlistentry>
1379
1380        <varlistentry><term>
1381          <literal>relationModifier.</literal><replaceable>mod</replaceable>
1382         </term>
1383         <listitem>
1384          <para>
1385           This pattern specifies how a CQL relation modifier is mapped to RPN.
1386           The RPN pattern is usually a relation attribute.
1387          </para>
1388         </listitem>
1389        </varlistentry>
1390
1391        <varlistentry><term>
1392          <literal>structure.</literal><replaceable>type</replaceable>
1393         </term>
1394         <listitem>
1395          <para>
1396           This pattern specifies how a CQL structure is mapped to RPN.
1397           Note that this CQL pattern is somewhat to similar to
1398           CQL pattern <literal>relation</literal>.
1399           The <replaceable>type</replaceable> is a CQL relation.
1400          </para>
1401          <para>
1402           The pattern, <literal>structure.*</literal> is used
1403           when no other structure pattern is matched.
1404           Usually, the RPN equivalent specifies a structure attribute.
1405          </para>
1406         </listitem>
1407        </varlistentry>
1408
1409        <varlistentry><term>
1410          <literal>position.</literal><replaceable>type</replaceable>
1411         </term>
1412         <listitem>
1413          <para>
1414           This pattern specifies how the anchor (position) of
1415           CQL is mapped to RPN.
1416           The <replaceable>type</replaceable> is one
1417           of <literal>first</literal>, <literal>any</literal>,
1418           <literal>last</literal>, <literal>firstAndLast</literal>.
1419          </para>
1420          <para>
1421           The pattern, <literal>position.*</literal> is used
1422           when no other position pattern is matched.
1423          </para>
1424         </listitem>
1425        </varlistentry>
1426
1427        <varlistentry><term>
1428          <literal>set.</literal><replaceable>prefix</replaceable>
1429         </term>
1430         <listitem>
1431          <para>
1432           This specification defines a CQL context set for a given prefix.
1433           The value on the right hand side is the URI for the set -
1434           <emphasis>not</emphasis> RPN. All prefixes used in
1435           index patterns must be defined this way.
1436          </para>
1437         </listitem>
1438        </varlistentry>
1439
1440        <varlistentry><term>
1441          <literal>set</literal>
1442         </term>
1443         <listitem>
1444          <para>
1445           This specification defines a default CQL context set for index names.
1446           The value on the right hand side is the URI for the set.
1447          </para>
1448         </listitem>
1449        </varlistentry>
1450
1451       </variablelist>
1452      </para>
1453      <example id="example.cql.to.rpn.mapping">
1454       <title>CQL to RPN mapping file</title>
1455       <para>
1456        This simple file defines two context sets, three indexes and three
1457        relations, a position pattern and a default structure.
1458       </para>
1459       <programlisting><![CDATA[
1460        set.cql  = http://www.loc.gov/zing/cql/context-sets/cql/v1.1/
1461        set.dc   = http://www.loc.gov/zing/cql/dc-indexes/v1.0/
1462
1463        index.cql.serverChoice = 1=1016
1464        index.dc.title         = 1=4
1465        index.dc.subject       = 1=21
1466
1467        relation.<             = 2=1
1468        relation.eq            = 2=3
1469        relation.scr           = 2=3
1470
1471        position.any           = 3=3 6=1
1472
1473        structure.*            = 4=1
1474 ]]>
1475       </programlisting>
1476       <para>
1477        With the mappings above, the CQL query
1478        <screen>
1479         computer
1480        </screen>
1481        is converted to the PQF:
1482        <screen>
1483         @attr 1=1016 @attr 2=3 @attr 4=1 @attr 3=3 @attr 6=1 "computer"
1484        </screen>
1485        by rules <literal>index.cql.serverChoice</literal>,
1486        <literal>relation.scr</literal>, <literal>structure.*</literal>,
1487        <literal>position.any</literal>.
1488       </para>
1489       <para>
1490        CQL query
1491        <screen>
1492         computer^
1493        </screen>
1494        is rejected, since <literal>position.right</literal> is
1495        undefined.
1496       </para>
1497       <para>
1498        CQL query
1499        <screen>
1500         >my = "http://www.loc.gov/zing/cql/dc-indexes/v1.0/" my.title = x
1501        </screen>
1502        is converted to
1503        <screen>
1504         @attr 1=4 @attr 2=3 @attr 4=1 @attr 3=3 @attr 6=1 "x"
1505        </screen>
1506       </para>
1507      </example>
1508      <example id="example.cql.to.rpn.string">
1509       <title>CQL to RPN string attributes</title>
1510       <para>
1511        In this example we allow any index to be passed to RPN as
1512        a use attribute.
1513       </para>
1514       <programlisting><![CDATA[
1515        # Identifiers for prefixes used in this file. (index.*)
1516        set.cql  = info:srw/cql-context-set/1/cql-v1.1
1517        set.rpn  = http://bogus/rpn
1518        set      = http://bogus/rpn
1519
1520        # The default index when none is specified by the query
1521        index.cql.serverChoice     = 1=any
1522
1523        index.rpn.*                = 1=*
1524        relation.eq                = 2=3
1525        structure.*                = 4=1
1526        position.any               = 3=3
1527 ]]>
1528       </programlisting>
1529       <para>
1530        The <literal>http://bogus/rpn</literal> context set is also the default
1531        so we can make queries such as
1532        <screen>
1533         title = a
1534        </screen>
1535        which is converted to
1536        <screen>
1537         @attr 2=3 @attr 4=1 @attr 3=3 @attr 1=title "a"
1538        </screen>
1539       </para>
1540      </example>
1541      <example id="example.cql.to.rpn.bathprofile">
1542       <title>CQL to RPN using Bath Profile</title>
1543       <para>
1544        The file <filename>etc/pqf.properties</filename> has mappings from
1545        the Bath Profile and Dublin Core to RPN.
1546        If YAZ is installed as a package it's usually located
1547        in <filename>/usr/share/yaz/etc</filename> and part of the
1548        development package, such as <literal>libyaz-dev</literal>.
1549       </para>
1550      </example>
1551     </sect3>
1552     <sect3 id="cql.xcql"><title>CQL to XCQL conversion</title>
1553      <para>
1554       Conversion from CQL to XCQL is trivial and does not
1555       require a mapping to be defined.
1556       There three functions to choose from depending on the
1557       way you wish to store the resulting output (XML buffer
1558       containing XCQL).
1559       <synopsis>
1560 int cql_to_xml_buf(struct cql_node *cn, char *out, int max);
1561 void cql_to_xml(struct cql_node *cn,
1562                 void (*pr)(const char *buf, void *client_data),
1563                 void *client_data);
1564 void cql_to_xml_stdio(struct cql_node *cn, FILE *f);
1565       </synopsis>
1566       Function <function>cql_to_xml_buf</function> converts
1567       to XCQL and stores result in a user supplied buffer of a given
1568       max size.
1569      </para>
1570      <para>
1571       <function>cql_to_xml</function> writes the result in
1572       a user defined output stream.
1573       <function>cql_to_xml_stdio</function> writes to a
1574       a file.
1575      </para>
1576     </sect3>
1577     <sect3 id="rpn.to.cql">
1578      <title>PQF to CQL conversion</title>
1579      <para>
1580       Conversion from PQF to CQL is offered by the two functions shown
1581       below. The former uses a generic stream for result. The latter
1582       puts result in a WRBUF (string container).
1583      <synopsis>
1584 #include &lt;yaz/rpn2cql.h>
1585
1586 int cql_transform_rpn2cql_stream(cql_transform_t ct,
1587                                  void (*pr)(const char *buf, void *client_data),
1588                                  void *client_data,
1589                                  Z_RPNQuery *q);
1590
1591 int cql_transform_rpn2cql_wrbuf(cql_transform_t ct,
1592                                 WRBUF w,
1593                                 Z_RPNQuery *q);
1594       </synopsis>
1595       The configuration is the same as used in CQL to PQF conversions.
1596      </para>
1597     </sect3>
1598    </sect2>
1599   </sect1>
1600   <sect1 id="tools.oid"><title>Object Identifiers</title>
1601
1602    <para>
1603     The basic YAZ representation of an OID is an array of integers,
1604     terminated with the value -1. This integer is of type
1605     <literal>Odr_oid</literal>.
1606    </para>
1607    <para>
1608     Fundamental OID operations and the type <literal>Odr_oid</literal>
1609     are defined in <filename>yaz/oid_util.h</filename>.
1610    </para>
1611    <para>
1612     An OID can either be declared as a automatic variable or it can
1613     allocated using the memory utilities or ODR/NMEM. It's
1614     guaranteed that an OID can fit in <literal>OID_SIZE</literal> integers.
1615    </para>
1616    <example id="tools.oid.bib1.1"><title>Create OID on stack</title>
1617     <para>
1618      We can create an OID for the Bib-1 attribute set with:
1619      <screen>
1620       Odr_oid bib1[OID_SIZE];
1621       bib1[0] = 1;
1622       bib1[1] = 2;
1623       bib1[2] = 840;
1624       bib1[3] = 10003;
1625       bib1[4] = 3;
1626       bib1[5] = 1;
1627       bib1[6] = -1;
1628      </screen>
1629     </para>
1630    </example>
1631    <para>
1632     And OID may also be filled from a string-based representation using
1633     dots (.). This is achieved by function
1634     <screen>
1635      int oid_dotstring_to_oid(const char *name, Odr_oid *oid);
1636     </screen>
1637     This functions returns 0 if name could be converted; -1 otherwise.
1638    </para>
1639    <example id="tools.oid.bib1.2"><title>Using oid_oiddotstring_to_oid</title>
1640     <para>
1641      We can fill the Bib-1 attribute set OID easier with:
1642      <screen>
1643       Odr_oid bib1[OID_SIZE];
1644       oid_oiddotstring_to_oid("1.2.840.10003.3.1", bib1);
1645      </screen>
1646    </para>
1647    </example>
1648    <para>
1649     We can also allocate an OID dynamically on a ODR stream with:
1650    <screen>
1651     Odr_oid *odr_getoidbystr(ODR o, const char *str);
1652    </screen>
1653     This creates an OID from string-based representation using dots.
1654     This function take an &odr; stream as parameter. This stream is used to
1655     allocate memory for the data elements, which is released on a
1656     subsequent call to <function>odr_reset()</function> on that stream.
1657    </para>
1658
1659    <example id="tools.oid.bib1.3"><title>Using odr_getoidbystr</title>
1660     <para>
1661      We can create a OID for the Bib-1 attribute set with:
1662      <screen>
1663       Odr_oid *bib1 = odr_getoidbystr(odr, "1.2.840.10003.3.1");
1664      </screen>
1665     </para>
1666    </example>
1667
1668    <para>
1669     The function
1670     <screen>
1671      char *oid_oid_to_dotstring(const Odr_oid *oid, char *oidbuf)
1672     </screen>
1673     does the reverse of <function>oid_oiddotstring_to_oid</function>. It
1674     converts an OID to the string-based representation using dots.
1675     The supplied char buffer <literal>oidbuf</literal> holds the resulting
1676     string and must be at least <literal>OID_STR_MAX</literal> in size.
1677    </para>
1678
1679    <para>
1680     OIDs can be copied with <function>oid_oidcpy</function> which takes
1681     two OID lists as arguments. Alternativly, an OID copy can be allocated
1682     on a ODR stream with:
1683     <screen>
1684      Odr_oid *odr_oiddup(ODR odr, const Odr_oid *o);
1685     </screen>
1686    </para>
1687
1688    <para>
1689     OIDs can be compared with <function>oid_oidcmp</function> which returns
1690     zero if the two OIDs provided are identical; non-zero otherwise.
1691    </para>
1692
1693    <sect2 id="tools.oid.database"><title>OID database</title>
1694     <para>
1695      From YAZ version 3 and later, the oident system has been replaced
1696      by an OID database. OID database is a misnomer .. the old odient
1697      system was also a database.
1698     </para>
1699     <para>
1700      The OID database is really just a map between named Object Identifiers
1701      (string) and their OID raw equivalents. Most operations either
1702      convert from string to OID or other way around.
1703     </para>
1704     <para>
1705      Unfortunately, whenever we supply a string we must also specify the
1706      <emphasis>OID class</emphasis>. The class is necessary because some
1707      strings correspond to multiple OIDs. An example of such a string is
1708      <literal>Bib-1</literal> which may either be an attribute-set
1709      or a diagnostic-set.
1710     </para>
1711     <para>
1712      Applications using the YAZ database should include
1713      <filename>yaz/oid_db.h</filename>.
1714     </para>
1715     <para>
1716      A YAZ database handle is of type <literal>yaz_oid_db_t</literal>.
1717      Actually that's a pointer. You need not think deal with that.
1718      YAZ has a built-in database which can be considered "constant" for
1719      most purposes.
1720      We can get hold that by using function <function>yaz_oid_std</function>.
1721     </para>
1722     <para>
1723      All functions with prefix <function>yaz_string_to_oid</function>
1724      converts from class + string to OID. We have variants of this
1725      operation due to different memory allocation strategies.
1726     </para>
1727     <para>
1728      All functions with prefix
1729      <function>yaz_oid_to_string</function> converts from OID to string
1730      + class.
1731     </para>
1732
1733     <example id="tools.oid.bib1.4"><title>Create OID with YAZ DB</title>
1734      <para>
1735       We can create an OID for the Bib-1 attribute set on the ODR stream
1736       odr with:
1737      <screen>
1738         Odr_oid *bib1 =
1739          yaz_string_to_oid_odr(yaz_oid_std(), CLASS_ATTSET, "Bib-1", odr);
1740       </screen>
1741       This is more complex than using <function>odr_getoidbystr</function>.
1742       You would only use <function>yaz_string_to_oid_odr</function> when the
1743       string (here Bib-1) is supplied by a user or configuration.
1744      </para>
1745     </example>
1746
1747    </sect2>
1748    <sect2 id="tools.oid.std"><title>Standard OIDs</title>
1749
1750     <para>
1751      All the object identifers in the standard OID database as returned
1752      by <function>yaz_oid_std</function> can referenced directly in a
1753      program as a constant OID.
1754      Each constant OID is prefixed with <literal>yaz_oid_</literal> -
1755      followed by OID class (lowercase) - then by OID name (normalized and
1756      lowercase).
1757     </para>
1758     <para>
1759      See <xref linkend="list-oids"/> for list of all object identifiers
1760      built into YAZ.
1761      These are declared in <filename>yaz/oid_std.h</filename> but are
1762      included by <filename>yaz/oid_db.h</filename> as well.
1763     </para>
1764
1765     <example id="tools.oid.bib1.5"><title>Use a built-in OID</title>
1766      <para>
1767       We can allocate our own OID filled with the constant OID for
1768       Bib-1 with:
1769       <screen>
1770         Odr_oid *bib1 = odr_oiddup(o, yaz_oid_attset_bib1);
1771       </screen>
1772      </para>
1773     </example>
1774    </sect2>
1775   </sect1>
1776   <sect1 id="tools.nmem"><title>Nibble Memory</title>
1777
1778    <para>
1779     Sometimes when you need to allocate and construct a large,
1780     interconnected complex of structures, it can be a bit of a pain to
1781     release the associated memory again. For the structures describing the
1782     Z39.50 PDUs and related structures, it is convenient to use the
1783     memory-management system of the &odr; subsystem (see
1784     <xref linkend="odr.use"/>). However, in some circumstances
1785     where you might otherwise benefit from using a simple nibble memory
1786     management system, it may be impractical to use
1787     <function>odr_malloc()</function> and <function>odr_reset()</function>.
1788     For this purpose, the memory manager which also supports the &odr;
1789     streams is made available in the NMEM module. The external interface
1790     to this module is given in the <filename>nmem.h</filename> file.
1791    </para>
1792
1793    <para>
1794     The following prototypes are given:
1795    </para>
1796
1797    <screen>
1798     NMEM nmem_create(void);
1799     void nmem_destroy(NMEM n);
1800     void *nmem_malloc(NMEM n, size_t size);
1801     void nmem_reset(NMEM n);
1802     size_t nmem_total(NMEM n);
1803     void nmem_init(void);
1804     void nmem_exit(void);
1805    </screen>
1806
1807    <para>
1808     The <function>nmem_create()</function> function returns a pointer to a
1809     memory control handle, which can be released again by
1810     <function>nmem_destroy()</function> when no longer needed.
1811     The function <function>nmem_malloc()</function> allocates a block of
1812     memory of the requested size. A call to <function>nmem_reset()</function>
1813     or <function>nmem_destroy()</function> will release all memory allocated
1814     on the handle since it was created (or since the last call to
1815     <function>nmem_reset()</function>. The function
1816     <function>nmem_total()</function> returns the number of bytes currently
1817     allocated on the handle.
1818    </para>
1819
1820    <para>
1821     The nibble memory pool is shared amongst threads. POSIX
1822     mutex'es and WIN32 Critical sections are introduced to keep the
1823     module thread safe. Function <function>nmem_init()</function>
1824     initializes the nibble memory library and it is called automatically
1825     the first time the <literal>YAZ.DLL</literal> is loaded. &yaz; uses
1826     function <function>DllMain</function> to achieve this. You should
1827     <emphasis>not</emphasis> call <function>nmem_init</function> or
1828     <function>nmem_exit</function> unless you're absolute sure what
1829     you're doing. Note that in previous &yaz; versions you'd have to call
1830     <function>nmem_init</function> yourself.
1831    </para>
1832
1833   </sect1>
1834
1835   <sect1 id="tools.log"><title>Log</title>
1836   <para>
1837    &yaz; has evolved a fairly complex log system which should be useful both
1838    for debugging &yaz; itself, debugging applications that use &yaz;, and for
1839    production use of those applications.
1840   </para>
1841   <para>
1842    The log functions are declared in header <filename>yaz/log.h</filename>
1843     and implemented in <filename>src/log.c</filename>.
1844     Due to name clash with syslog and some math utilities the logging
1845     interface has been modified as of YAZ 2.0.29. The obsolete interface
1846     is still available if in header file <filename>yaz/log.h</filename>.
1847     The key points of the interface are:
1848   </para>
1849   <screen>
1850    void yaz_log(int level, const char *fmt, ...)
1851
1852    void yaz_log_init(int level, const char *prefix, const char *name);
1853    void yaz_log_init_file(const char *fname);
1854    void yaz_log_init_level(int level);
1855    void yaz_log_init_prefix(const char *prefix);
1856    void yaz_log_time_format(const char *fmt);
1857    void yaz_log_init_max_size(int mx);
1858
1859    int yaz_log_mask_str(const char *str);
1860    int yaz_log_module_level(const char *name);
1861   </screen>
1862
1863   <para>
1864    The reason for the whole log module is the <function>yaz_log</function>
1865    function. It takes a bitmask indicating the log levels, a
1866    <literal>printf</literal>-like format string, and a variable number of
1867    arguments to log.
1868   </para>
1869
1870   <para>
1871    The <literal>log level</literal> is a bit mask, that says on which level(s)
1872    the log entry should be made, and optionally set some behaviour of the
1873    logging. In the most simple cases, it can be one of <literal>YLOG_FATAL,
1874    YLOG_DEBUG, YLOG_WARN, YLOG_LOG</literal>. Those can be combined with bits
1875    that modify the way the log entry is written:<literal>YLOG_ERRNO,
1876    YLOG_NOTIME, YLOG_FLUSH</literal>.
1877    Most of the rest of the bits are deprecated, and should not be used. Use
1878    the dynamic log levels instead.
1879   </para>
1880
1881   <para>
1882    Applications that use &yaz;, should not use the LOG_LOG for ordinary
1883    messages, but should make use of the dynamic loglevel system. This consists
1884    of two parts, defining the loglevel and checking it.
1885   </para>
1886
1887   <para>
1888    To define the log levels, the (main) program should pass a string to
1889    <function>yaz_log_mask_str</function> to define which log levels are to be
1890    logged. This string should be a comma-separated list of log level names,
1891    and can contain both hard-coded names and dynamic ones. The log level
1892    calculation starts with <literal>YLOG_DEFAULT_LEVEL</literal> and adds a bit
1893    for each word it meets, unless the word starts with a '-', in which case it
1894    clears the bit. If the string <literal>'none'</literal> is found,
1895    all bits are cleared. Typically this string comes from the command-line,
1896    often identified by <literal>-v</literal>. The
1897    <function>yaz_log_mask_str</function> returns a log level that should be
1898    passed to <function>yaz_log_init_level</function> for it to take effect.
1899   </para>
1900
1901   <para>
1902    Each module should check what log bits it should be used, by calling
1903    <function>yaz_log_module_level</function> with a suitable name for the
1904    module. The name is cleared from a preceding path and an extension, if any,
1905    so it is quite possible to use <literal>__FILE__</literal> for it. If the
1906    name has been passed to <function>yaz_log_mask_str</function>, the routine
1907    returns a non-zero bitmask, which should then be used in consequent calls
1908    to yaz_log. (It can also be tested, so as to avoid unnecessary calls to
1909    yaz_log, in time-critical places, or when the log entry would take time
1910    to construct.)
1911   </para>
1912
1913   <para>
1914    Yaz uses the following dynamic log levels:
1915    <literal>server, session, request, requestdetail</literal> for the server
1916    functionality.
1917    <literal>zoom</literal> for the zoom client api.
1918    <literal>ztest</literal> for the simple test server.
1919    <literal>malloc, nmem, odr, eventl</literal> for internal debugging of yaz itself.
1920    Of course, any program using yaz is welcome to define as many new ones, as
1921    it needs.
1922   </para>
1923
1924   <para>
1925    By default the log is written to stderr, but this can be changed by a call
1926    to <function>yaz_log_init_file</function> or
1927    <function>yaz_log_init</function>. If the log is directed to a file, the
1928    file size is checked at every write, and if it exceeds the limit given in
1929    <function>yaz_log_init_max_size</function>, the log is rotated. The
1930    rotation keeps one old version (with a <literal>.1</literal> appended to
1931    the name). The size defaults to 1GB. Setting it to zero will disable the
1932    rotation feature.
1933   </para>
1934
1935   <screen>
1936   A typical yaz-log looks like this
1937   13:23:14-23/11 yaz-ztest(1) [session] Starting session from tcp:127.0.0.1 (pid=30968)
1938   13:23:14-23/11 yaz-ztest(1) [request] Init from 'YAZ' (81) (ver 2.0.28) OK
1939   13:23:17-23/11 yaz-ztest(1) [request] Search Z: @attrset Bib-1 foo  OK:7 hits
1940   13:23:22-23/11 yaz-ztest(1) [request] Present: [1] 2+2  OK 2 records returned
1941   13:24:13-23/11 yaz-ztest(1) [request] Close OK
1942   </screen>
1943
1944   <para>
1945    The log entries start with a time stamp. This can be omitted by setting the
1946    <literal>YLOG_NOTIME</literal> bit in the loglevel. This way automatic tests
1947    can be hoped to produce identical log files, that are easy to diff. The
1948    format of the time stamp can be set with
1949    <function>yaz_log_time_format</function>, which takes a format string just
1950    like <function>strftime</function>.
1951   </para>
1952
1953   <para>
1954    Next in a log line comes the prefix, often the name of the program. For
1955    yaz-based servers, it can also contain the session number. Then
1956    comes one or more logbits in square brackets, depending on the logging
1957    level set by <function>yaz_log_init_level</function> and the loglevel
1958    passed to <function>yaz_log_init_level</function>. Finally comes the format
1959    string and additional values passed to <function>yaz_log</function>
1960   </para>
1961
1962   <para>
1963    The log level <literal>YLOG_LOGLVL</literal>, enabled by the string
1964    <literal>loglevel</literal>, will log all the log-level affecting
1965    operations. This can come in handy if you need to know what other log
1966    levels would be useful. Grep the logfile for <literal>[loglevel]</literal>.
1967   </para>
1968
1969   <para>
1970    The log system is almost independent of the rest of &yaz;, the only
1971    important dependence is of <filename>nmem</filename>, and that only for
1972    using the semaphore definition there.
1973   </para>
1974
1975   <para>
1976    The dynamic log levels and log rotation were introduced in &yaz; 2.0.28. At
1977    the same time, the log bit names were changed from
1978    <literal>LOG_something</literal> to <literal>YLOG_something</literal>,
1979    to avoid collision with <filename>syslog.h</filename>.
1980   </para>
1981
1982   </sect1>
1983
1984   <sect1 id="marc"><title>MARC</title>
1985
1986    <para>
1987     YAZ provides a fast utility for working with MARC records.
1988     Early versions of the MARC utility only allowed decoding of ISO2709.
1989     Today the utility may both encode - and decode to a varity of formats.
1990    </para>
1991    <synopsis><![CDATA[
1992     #include <yaz/marcdisp.h>
1993
1994     /* create handler */
1995     yaz_marc_t yaz_marc_create(void);
1996     /* destroy */
1997     void yaz_marc_destroy(yaz_marc_t mt);
1998
1999     /* set XML mode YAZ_MARC_LINE, YAZ_MARC_SIMPLEXML, ... */
2000     void yaz_marc_xml(yaz_marc_t mt, int xmlmode);
2001     #define YAZ_MARC_LINE      0
2002     #define YAZ_MARC_SIMPLEXML 1
2003     #define YAZ_MARC_OAIMARC   2
2004     #define YAZ_MARC_MARCXML   3
2005     #define YAZ_MARC_ISO2709   4
2006     #define YAZ_MARC_XCHANGE   5
2007     #define YAZ_MARC_CHECK     6
2008     #define YAZ_MARC_TURBOMARC 7
2009     #define YAZ_MARC_JSON      8
2010
2011     /* supply iconv handle for character set conversion .. */
2012     void yaz_marc_iconv(yaz_marc_t mt, yaz_iconv_t cd);
2013
2014     /* set debug level, 0=none, 1=more, 2=even more, .. */
2015     void yaz_marc_debug(yaz_marc_t mt, int level);
2016
2017     /* decode MARC in buf of size bsize. Returns >0 on success; <=0 on failure.
2018     On success, result in *result with size *rsize. */
2019     int yaz_marc_decode_buf(yaz_marc_t mt, const char *buf, int bsize,
2020                             const char **result, size_t *rsize);
2021
2022     /* decode MARC in buf of size bsize. Returns >0 on success; <=0 on failure.
2023        On success, result in WRBUF */
2024     int yaz_marc_decode_wrbuf(yaz_marc_t mt, const char *buf,
2025                               int bsize, WRBUF wrbuf);
2026 ]]>
2027    </synopsis>
2028    <note>
2029     <para>
2030      The synopsis is just a basic subset of all functionality. Refer
2031      to the actual header file <filename>marcdisp.h</filename> for
2032      details.
2033     </para>
2034    </note>
2035    <para>
2036     A MARC conversion handle must be created by using
2037     <function>yaz_marc_create</function> and destroyed
2038     by calling <function>yaz_marc_destroy</function>.
2039   </para>
2040    <para>
2041     All other function operate on a <literal>yaz_marc_t</literal> handle.
2042     The output is specified by a call to <function>yaz_marc_xml</function>.
2043     The <literal>xmlmode</literal> must be one of
2044     <variablelist>
2045      <varlistentry>
2046       <term>YAZ_MARC_LINE</term>
2047       <listitem>
2048        <para>
2049         A simple line-by-line format suitable for display but not
2050         recommend for further (machine) processing.
2051        </para>
2052       </listitem>
2053      </varlistentry>
2054
2055      <varlistentry>
2056       <term>YAZ_MARC_MARCXML</term>
2057       <listitem>
2058        <para>
2059         <ulink url="&url.marcxml;">MARCXML</ulink>.
2060        </para>
2061       </listitem>
2062      </varlistentry>
2063
2064      <varlistentry>
2065       <term>YAZ_MARC_ISO2709</term>
2066       <listitem>
2067        <para>
2068         ISO2709 (sometimes just referred to as "MARC").
2069        </para>
2070       </listitem>
2071      </varlistentry>
2072
2073      <varlistentry>
2074       <term>YAZ_MARC_XCHANGE</term>
2075       <listitem>
2076        <para>
2077         <ulink url="&url.marcxchange;">MarcXchange</ulink>.
2078        </para>
2079       </listitem>
2080      </varlistentry>
2081
2082      <varlistentry>
2083       <term>YAZ_MARC_CHECK</term>
2084       <listitem>
2085        <para>
2086         Pseudo format for validation only. Does not generate
2087         any real output except diagnostics.
2088        </para>
2089       </listitem>
2090      </varlistentry>
2091
2092      <varlistentry>
2093       <term>YAZ_MARC_TURBOMARC</term>
2094       <listitem>
2095        <para>
2096         XML format with same semantics as MARCXML but more compact
2097         and geared towards fast processing with XSLT. Refer to
2098         <xref linkend="tools.turbomarc"/> for more information.
2099        </para>
2100       </listitem>
2101      </varlistentry>
2102
2103      <varlistentry>
2104       <term>YAZ_MARC_JSON</term>
2105       <listitem>
2106        <para>
2107         <ulink url="&url.marc_in_json;">MARC-in_JSON</ulink> format.
2108        </para>
2109       </listitem>
2110      </varlistentry>
2111
2112     </variablelist>
2113    </para>
2114    <para>
2115     The actual conversion functions are
2116     <function>yaz_marc_decode_buf</function> and
2117     <function>yaz_marc_decode_wrbuf</function> which decodes and encodes
2118     a MARC record. The former function operates on simple buffers, the
2119     stores the resulting record in a WRBUF handle (WRBUF is a simple string
2120     type).
2121    </para>
2122    <example id="example.marc.display">
2123     <title>Display of MARC record</title>
2124     <para>
2125      The following program snippet illustrates how the MARC API may
2126      be used to convert a MARC record to the line-by-line format:
2127      <programlisting><![CDATA[
2128       void print_marc(const char *marc_buf, int marc_buf_size)
2129       {
2130          char *result;      /* for result buf */
2131          size_t result_len;    /* for size of result */
2132          yaz_marc_t mt = yaz_marc_create();
2133          yaz_marc_xml(mt, YAZ_MARC_LINE);
2134          yaz_marc_decode_buf(mt, marc_buf, marc_buf_size,
2135                              &result, &result_len);
2136          fwrite(result, result_len, 1, stdout);
2137          yaz_marc_destroy(mt);  /* note that result is now freed... */
2138       }
2139 ]]>
2140       </programlisting>
2141     </para>
2142    </example>
2143    <sect2 id="tools.turbomarc">
2144     <title>TurboMARC</title>
2145     <para>
2146      TurboMARC is yet another XML encoding of a MARC record. The format
2147      was designed for fast processing with XSLT.
2148     </para>
2149     <para>
2150      Applications like
2151      Pazpar2 uses XSLT to convert an XML encoded MARC record to an internal
2152      representation. This conversion mostly check the tag of a MARC field
2153      to determine the basic rules in the conversion. This check is
2154      costly when that is tag is encoded as an attribute in MARCXML.
2155      By having the tag value as the element instead, makes processing
2156      many times faster (at least for Libxslt).
2157     </para>
2158     <para>
2159      TurboMARC is encoded as follows:
2160      <itemizedlist>
2161       <listitem><para>
2162         Record elements is part of namespace
2163         "<literal>http://www.indexdata.com/turbomarc</literal>".
2164        </para></listitem>
2165       <listitem><para>
2166         A record is enclosed in element <literal>r</literal>.
2167        </para></listitem>
2168       <listitem><para>
2169         A collection of records is enclosed in element
2170         <literal>collection</literal>.
2171        </para></listitem>
2172       <listitem><para>
2173         The leader is encoded as element <literal>l</literal> with the
2174         leader content as its (text) value.
2175        </para></listitem>
2176       <listitem><para>
2177         A control field is encoded as element <literal>c</literal> concatenated
2178         with the tag value of the control field if the tag value
2179         matches the regular expression <literal>[a-zA-Z0-9]*</literal>.
2180         If the tag value do not match the regular expression
2181         <literal>[a-zA-Z0-9]*</literal> the control field is encoded
2182         as element <literal>c</literal> and attribute <literal>code</literal>
2183         will hold the tag value.
2184         This rule ensure that in the rare cases where a tag value might
2185         result in a non-wellformed XML YAZ encode it as a coded attribute
2186         (as in MARCXML).
2187        </para>
2188        <para>
2189         The control field content is the the text value of this element.
2190         Indicators are encoded as attribute names
2191         <literal>i1</literal>, <literal>i2</literal>, etc.. and
2192         corresponding values for each indicator.
2193        </para></listitem>
2194       <listitem><para>
2195         A data field is encoded as element <literal>d</literal> concatenated
2196         with the tag value of the data field or using the attribute
2197         <literal>code</literal> as described in the rules for control fields.
2198         The children of the data field element is subfield elements.
2199         Each subfield element is encoded as <literal>s</literal>
2200         concatenated with the sub field code.
2201         The text of the subfield element is the contents of the subfield.
2202         Indicators are encoded as attributes for the data field element similar
2203         to the encoding for control fields.
2204        </para></listitem>
2205      </itemizedlist>
2206     </para>
2207    </sect2>
2208   </sect1>
2209
2210   <sect1 id="tools.retrieval">
2211    <title>Retrieval Facility</title>
2212    <para>
2213     YAZ version 2.1.20 or later includes a Retrieval facility tool
2214     which allows a SRU/Z39.50 to describe itself and perform record
2215     conversions. The idea is the following:
2216
2217     <itemizedlist>
2218      <listitem>
2219       <para>
2220        An SRU/Z39.50 client sends a retrieval request which includes
2221        a combination of the following parameters: syntax (format),
2222        schema (or element set name).
2223       </para>
2224      </listitem>
2225
2226      <listitem>
2227       <para>
2228        The retrieval facility is invoked with parameters in a
2229        server/proxy. The retrieval facility matches the parameters a set of
2230        "supported" retrieval types.
2231        If there is no match, the retrieval signals an error
2232        (syntax and / or schema not supported).
2233       </para>
2234      </listitem>
2235
2236      <listitem>
2237       <para>
2238        For a successful match, the backend is invoked with the same
2239        or altered retrieval parameters (syntax, schema). If
2240        a record is received from the backend, it is converted to the
2241        frontend name / syntax.
2242       </para>
2243      </listitem>
2244
2245      <listitem>
2246       <para>
2247        The resulting record is sent back the client and tagged with
2248        the frontend syntax / schema.
2249       </para>
2250      </listitem>
2251
2252     </itemizedlist>
2253    </para>
2254    <para>
2255     The Retrieval facility is driven by an XML configuration. The
2256     configuration is neither Z39.50 ZeeRex or SRU ZeeRex. But it
2257     should be easy to generate both of them from the XML configuration.
2258     (unfortunately the two versions
2259     of ZeeRex differ substantially in this regard).
2260    </para>
2261    <sect2 id="tools.retrieval.format">
2262     <title>Retrieval XML format</title>
2263     <para>
2264      All elements should be covered by namespace
2265      <literal>http://indexdata.com/yaz</literal> .
2266      The root element node must be <literal>retrievalinfo</literal>.
2267     </para>
2268     <para>
2269      The <literal>retrievalinfo</literal> must include one or
2270      more <literal>retrieval</literal> elements. Each
2271     <literal>retrieval</literal> defines specific combination of
2272      syntax, name and identifier supported by this retrieval service.
2273     </para>
2274     <para>
2275      The <literal>retrieval</literal> element may include any of the
2276      following attributes:
2277      <variablelist>
2278       <varlistentry><term><literal>syntax</literal> (REQUIRED)</term>
2279        <listitem>
2280         <para>
2281          Defines the record syntax. Possible values is any
2282          of the names defined in YAZ' OID database or a raw
2283          OID in (n.n ... n).
2284         </para>
2285        </listitem>
2286       </varlistentry>
2287       <varlistentry><term><literal>name</literal> (OPTIONAL)</term>
2288        <listitem>
2289         <para>
2290          Defines the name of the retrieval format. This can be
2291          any string. For SRU, the value, is equivalent to schema (short-hand);
2292          for Z39.50 it's equivalent to simple element set name.
2293          For YAZ 3.0.24 and later this name may be specified as a glob
2294          expression with operators
2295          <literal>*</literal> and <literal>?</literal>.
2296         </para>
2297        </listitem>
2298       </varlistentry>
2299       <varlistentry><term><literal>identifier</literal> (OPTIONAL)</term>
2300        <listitem>
2301         <para>
2302          Defines the URI schema name of the retrieval format. This can be
2303          any string. For SRU, the value, is equivalent to URI schema.
2304          For Z39.50, there is no equivalent.
2305         </para>
2306        </listitem>
2307       </varlistentry>
2308      </variablelist>
2309     </para>
2310     <para>
2311      The <literal>retrieval</literal> may include one
2312      <literal>backend</literal> element. If a <literal>backend</literal>
2313      element is given, it specifies how the records are retrieved by
2314      some backend and how the records are converted from the backend to
2315      the "frontend".
2316     </para>
2317     <para>
2318      The attributes, <literal>name</literal> and <literal>syntax</literal>
2319      may be specified for the <literal>backend</literal> element. These
2320      semantics of these attributes is equivalent to those for the
2321      <literal>retrieval</literal>. However, these values are passed to
2322      the "backend".
2323     </para>
2324     <para>
2325      The <literal>backend</literal> element may includes one or more
2326      conversion instructions (as children elements). The supported
2327      conversions are:
2328      <variablelist>
2329       <varlistentry><term><literal>marc</literal></term>
2330        <listitem>
2331         <para>
2332          The <literal>marc</literal> element specifies a conversion
2333          to - and from ISO2709 encoded MARC and
2334          <ulink url="&url.marcxml;">&acro.marcxml;</ulink>/MarcXchange.
2335          The following attributes may be specified:
2336
2337          <variablelist>
2338           <varlistentry><term><literal>inputformat</literal> (REQUIRED)</term>
2339            <listitem>
2340             <para>
2341              Format of input. Supported values are
2342              <literal>marc</literal> (for ISO2709), <literal>xml</literal>
2343              (MARCXML/MarcXchange) and <literal>json</literal>
2344              (<ulink url="&url.marc_in_json;">MARC-in_JSON</ulink>).
2345             </para>
2346            </listitem>
2347           </varlistentry>
2348
2349           <varlistentry><term><literal>outputformat</literal> (REQUIRED)</term>
2350            <listitem>
2351             <para>
2352              Format of output. Supported values are
2353              <literal>line</literal> (MARC line format);
2354              <literal>marcxml</literal> (for MARCXML),
2355              <literal>marc</literal> (ISO2709),
2356              <literal>marcxhcange</literal> (for MarcXchange),
2357              or <literal>json</literal>
2358              (<ulink url="&url.marc_in_json;">MARC-in_JSON </ulink>).
2359             </para>
2360            </listitem>
2361           </varlistentry>
2362
2363           <varlistentry><term><literal>inputcharset</literal> (OPTIONAL)</term>
2364            <listitem>
2365             <para>
2366              Encoding of input. For XML input formats, this need not
2367              be given, but for ISO2709 based inputformats, this should
2368              be set to the encoding used. For MARC21 records, a common
2369              inputcharset value  would be <literal>marc-8</literal>.
2370             </para>
2371            </listitem>
2372           </varlistentry>
2373
2374           <varlistentry><term><literal>outputcharset</literal> (OPTIONAL)</term>
2375            <listitem>
2376             <para>
2377              Encoding of output. If outputformat is XML based, it is
2378              strongly recommened to use <literal>utf-8</literal>.
2379             </para>
2380            </listitem>
2381           </varlistentry>
2382
2383          </variablelist>
2384         </para>
2385        </listitem>
2386       </varlistentry>
2387       <varlistentry><term><literal>xslt</literal></term>
2388        <listitem>
2389         <para>
2390          The <literal>xslt</literal> element specifies a conversion
2391          via &acro.xslt;. The following attributes may be specified:
2392
2393          <variablelist>
2394           <varlistentry><term><literal>stylesheet</literal> (REQUIRED)</term>
2395            <listitem>
2396             <para>
2397              Stylesheet file.
2398             </para>
2399            </listitem>
2400           </varlistentry>
2401          </variablelist>
2402
2403         </para>
2404        </listitem>
2405       </varlistentry>
2406      </variablelist>
2407     </para>
2408    </sect2>
2409    <sect2 id="tools.retrieval.examples">
2410     <title>Retrieval Facility Examples</title>
2411     <example id="tools.retrieval.marc21">
2412      <title>MARC21 backend</title>
2413      <para>
2414       A typical way to use the retrieval facility is to enable XML
2415       for servers that only supports ISO2709 encoded MARC21 records.
2416      </para>
2417      <programlisting><![CDATA[
2418      <retrievalinfo>
2419        <retrieval syntax="usmarc" name="F"/>
2420        <retrieval syntax="usmarc" name="B"/>
2421        <retrieval syntax="xml" name="marcxml"
2422                   identifier="info:srw/schema/1/marcxml-v1.1">
2423          <backend syntax="usmarc" name="F">
2424            <marc inputformat="marc" outputformat="marcxml"
2425                  inputcharset="marc-8"/>
2426          </backend>
2427        </retrieval>
2428        <retrieval syntax="xml" name="dc">
2429          <backend syntax="usmarc" name="F">
2430            <marc inputformat="marc" outputformat="marcxml"
2431                  inputcharset="marc-8"/>
2432            <xslt stylesheet="MARC21slim2DC.xsl"/>
2433          </backend>
2434        </retrieval>
2435      </retrievalinfo>
2436 ]]>
2437      </programlisting>
2438      <para>
2439       This means that our frontend supports:
2440       <itemizedlist>
2441        <listitem>
2442         <para>
2443          MARC21 F(ull) records.
2444         </para>
2445        </listitem>
2446        <listitem>
2447         <para>
2448          MARC21 B(rief) records.
2449         </para>
2450        </listitem>
2451
2452        <listitem>
2453         <para>
2454          MARCXML records.
2455         </para>
2456        </listitem>
2457
2458        <listitem>
2459         <para>
2460          Dublin core records.
2461         </para>
2462        </listitem>
2463       </itemizedlist>
2464      </para>
2465     </example>
2466
2467     <example id="tools.retrieval.marcxml">
2468      <title>MARCXML backend</title>
2469      <para>
2470       SRW/SRU and Solr backends returns records in XML.
2471       If they return MARCXML or MarcXchange, the retrieval module
2472       can convert those into ISO2709 formats, most commonly USMARC
2473       (AKA MARC21).
2474       In this example, the backend returns MARCXML for schema="marcxml".
2475      </para>
2476      <programlisting><![CDATA[
2477      <retrievalinfo>
2478        <retrieval syntax="usmarc">
2479          <backend syntax="xml" name="marcxml">
2480            <marc inputformat="xml" outputformat="marc"
2481                  outputcharset="marc-8"/>
2482          </backend>
2483        </retrieval>
2484        <retrieval syntax="xml" name="marcxml"
2485                   identifier="info:srw/schema/1/marcxml-v1.1"/>
2486        <retrieval syntax="xml" name="dc">
2487          <backend syntax="xml" name="marcxml">
2488            <xslt stylesheet="MARC21slim2DC.xsl"/>
2489          </backend>
2490        </retrieval>
2491      </retrievalinfo>
2492 ]]>
2493      </programlisting>
2494      <para>
2495       This means that our frontend supports:
2496       <itemizedlist>
2497        <listitem>
2498         <para>
2499          MARC21 records (any element set name) in MARC-8 encoding.
2500         </para>
2501        </listitem>
2502        <listitem>
2503         <para>
2504          MARCXML records for element-set=marcxml
2505         </para>
2506        </listitem>
2507        <listitem>
2508         <para>
2509          Dublin core records for element-set=dc.
2510         </para>
2511        </listitem>
2512       </itemizedlist>
2513      </para>
2514     </example>
2515
2516    </sect2>
2517    <sect2 id="tools.retrieval.api">
2518     <title>API</title>
2519     <para>
2520      It should be easy to use the retrieval systems from applications. Refer
2521      to the headers
2522      <filename>yaz/retrieval.h</filename> and
2523      <filename>yaz/record_conv.h</filename>.
2524     </para>
2525    </sect2>
2526   </sect1>
2527   <sect1><title>Sorting</title>
2528    <para>
2529     This chapter describes sorting and how it is supported in YAZ.
2530     Sorting applies to a result-set.
2531     The <ulink url="http://www.loc.gov/z3950/agency/markup/05.html#3.2.7">
2532      Z39.50 sorting facility
2533     </ulink>
2534     takes one or more input result-sets
2535     and one result-set as output. The most simple case is that
2536     the input-set is the same as the output-set.
2537    </para>
2538    <para>
2539     Z39.50 sorting has a separate APDU (service) that is, thus, performed
2540     following a search (two phases).
2541    </para>
2542    <para>
2543     In SRU/Solr, however, the model is different. Here, sorting is specified
2544     during the the search operation. Note, however, that SRU might
2545     perform sort as separate search, by referring to an existing result-set
2546     in the query (result-set reference).
2547    </para>
2548    <sect2><title>Using the Z39.50 sort service</title>
2549     <para>
2550      yaz-client and the ZOOM API supports the Z39.50 sort facility. In any
2551      case the sort sequence or sort critiera is using a string notation.
2552      This notation is a one-line notation suitable for being manually
2553      entered or generated and allows for easy logging (one liner).
2554      For the ZOOM API, the sort is specified in the call to ZOOM_query_sortby
2555      function. For yaz-client the sort is performed and specified using
2556      the sort and sort+ commands. For description of the sort criteria notation
2557      refer to the <link linkend="sortspec">sort command</link> in the
2558      yaz-client manual.
2559     </para>
2560     <para>
2561      The ZOOM API might choose one of several sort strategies for
2562      sorting. Refer to <xref linkend="zoom-sort-strategy"/>.
2563     </para>
2564    </sect2>
2565    <sect2><title>Type-7 sort</title>
2566     <para>
2567      Type-7 sort is an extension to the Bib-1 based RPN query where the
2568      sort specification is embedded as an Attribute-Plus-Term.
2569     </para>
2570     <para>
2571      The objectives for introducing Type-7 sorting is that it allows
2572      a client to perform sorting even if it does not implement/support
2573      Z39.50 sort. Virtually all Z39.50 client software supports
2574      RPN queries. It also may improve performance because the sort
2575      critieria is specified along with the search query.
2576     </para>
2577     <para>
2578      The sort is triggered by the presence of type 7 and the value of type 7
2579      specifies the
2580      <ulink url="http://www.loc.gov/z3950/agency/asn1.html#SortKeySpec">
2581       sortRelation
2582      </ulink>
2583      The value for type 7 is 1 for ascending and 2 for descending.
2584      For the
2585      <ulink url="http://www.loc.gov/z3950/agency/asn1.html#SortElement">
2586       sortElement
2587      </ulink>
2588      only the generic part is handled. If generic sortKey is of type
2589      sortField, then attribute type 1 is present and the value is
2590      sortField (InternationalString). If generic sortKey is of type
2591      sortAttributes, then the attributes in list is used . generic sortKey
2592      of type elementSpec is not supported.
2593     </para>
2594     <para>
2595      The term in the sorting Attribute-Plus-Term combo should hold
2596      an integer. The value is 0 for primary sorting criteria, 1 for second
2597      criteria, etc.
2598     </para>
2599    </sect2>
2600   </sect1>
2601  </chapter>
2602
2603  <!-- Keep this comment at the end of the file
2604  Local variables:
2605  mode: sgml
2606  sgml-omittag:t
2607  sgml-shorttag:t
2608  sgml-minimize-attributes:nil
2609  sgml-always-quote-attributes:t
2610  sgml-indent-step:1
2611  sgml-indent-data:t
2612  sgml-parent-document: "yaz.xml"
2613  sgml-local-catalogs: nil
2614  sgml-namecase-general:t
2615  End:
2616  -->