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