All changes to the CQL section:
[yaz-moved-to-github.git] / doc / tools.xml
1 <!-- $Id: tools.xml,v 1.34 2003-12-18 17:27:31 mike Exp $ -->
2  <chapter id="tools"><title>Supporting Tools</title>
3   
4   <para>
5    In support of the service API - primarily the ASN module, which
6    provides the pro-grammatic interface to the Z39.50 APDUs, &yaz; contains
7    a collection of tools that support the development of applications.
8   </para>
9
10   <sect1 id="tools.query"><title>Query Syntax Parsers</title>
11
12    <para>
13     Since the type-1 (RPN) query structure has no direct, useful string
14     representation, every origin application needs to provide some form of
15     mapping from a local query notation or representation to a
16     <token>Z_RPNQuery</token> structure. Some programmers will prefer to
17     construct the query manually, perhaps using
18     <function>odr_malloc()</function> to simplify memory management.
19     The &yaz; distribution includes three separate, query-generating tools
20     that may be of use to you.
21    </para>
22
23    <sect2 id="PQF"><title>Prefix Query Format</title>
24
25     <para>
26      Since RPN or reverse polish notation is really just a fancy way of
27      describing a suffix notation format (operator follows operands), it
28      would seem that the confusion is total when we now introduce a prefix
29      notation for RPN. The reason is one of simple laziness - it's somewhat
30      simpler to interpret a prefix format, and this utility was designed
31      for maximum simplicity, to provide a baseline representation for use
32      in simple test applications and scripting environments (like Tcl). The
33      demonstration client included with YAZ uses the PQF.
34     </para>
35
36     <note>
37      <para>
38       The PQF have been adopted by other parties developing Z39.50
39       software. It is often referred to as Prefix Query Notation
40       - PQN.
41      </para>
42     </note>
43     <para>
44      The PQF is defined by the pquery module in the YAZ library. 
45      There are two sets of function that have similar behavior. First
46      set operates on a PQF parser handle, second set doesn't. First set
47      set of functions are more flexible than the second set. Second set
48      is obsolete and is only provided to ensure backwards compatibility.
49     </para>
50     <para>
51      First set of functions all operate on a PQF parser handle:
52     </para>
53     <synopsis>
54      #include &lt;yaz/pquery.h&gt;
55
56      YAZ_PQF_Parser yaz_pqf_create (void);
57
58      void yaz_pqf_destroy (YAZ_PQF_Parser p);
59
60      Z_RPNQuery *yaz_pqf_parse (YAZ_PQF_Parser p, ODR o, const char *qbuf);
61
62      Z_AttributesPlusTerm *yaz_pqf_scan (YAZ_PQF_Parser p, ODR o,
63                           Odr_oid **attributeSetId, const char *qbuf);
64
65
66      int yaz_pqf_error (YAZ_PQF_Parser p, const char **msg, size_t *off);
67     </synopsis>
68     <para>
69      A PQF parser is created and destructed by functions
70      <function>yaz_pqf_create</function> and
71      <function>yaz_pqf_destroy</function> respectively.
72      Function <function>yaz_pqf_parse</function> parses query given
73      by string <literal>qbuf</literal>. If parsing was successful,
74      a Z39.50 RPN Query is returned which is created using ODR stream
75      <literal>o</literal>. If parsing failed, a NULL pointer is
76      returned.
77      Function <function>yaz_pqf_scan</function> takes a scan query in 
78      <literal>qbuf</literal>. If parsing was successful, the function
79      returns attributes plus term pointer and modifies
80      <literal>attributeSetId</literal> to hold attribute set for the
81      scan request - both allocated using ODR stream <literal>o</literal>.
82      If parsing failed, yaz_pqf_scan returns a NULL pointer.
83      Error information for bad queries can be obtained by a call to
84      <function>yaz_pqf_error</function> which returns an error code and
85      modifies <literal>*msg</literal> to point to an error description,
86      and modifies <literal>*off</literal> to the offset within last
87      query were parsing failed.
88     </para>
89     <para>
90      The second set of functions are declared as follows:
91     </para>
92     <synopsis>
93      #include &lt;yaz/pquery.h&gt;
94
95      Z_RPNQuery *p_query_rpn (ODR o, oid_proto proto, const char *qbuf);
96
97      Z_AttributesPlusTerm *p_query_scan (ODR o, oid_proto proto,
98                              Odr_oid **attributeSetP, const char *qbuf);
99
100      int p_query_attset (const char *arg);
101     </synopsis>
102     <para>
103      The function <function>p_query_rpn()</function> takes as arguments an
104       &odr; stream (see section <link linkend="odr">The ODR Module</link>)
105      to provide a memory source (the structure created is released on
106      the next call to <function>odr_reset()</function> on the stream), a
107      protocol identifier (one of the constants <token>PROTO_Z3950</token> and
108      <token>PROTO_SR</token>), an attribute set reference, and
109      finally a null-terminated string holding the query string.
110     </para>
111     <para>
112      If the parse went well, <function>p_query_rpn()</function> returns a
113      pointer to a <literal>Z_RPNQuery</literal> structure which can be
114      placed directly into a <literal>Z_SearchRequest</literal>. 
115      If parsing failed, due to syntax error, a NULL pointer is returned.
116     </para>
117     <para>
118      The <literal>p_query_attset</literal> specifies which attribute set
119      to use if the query doesn't specify one by the
120      <literal>@attrset</literal> operator.
121      The <literal>p_query_attset</literal> returns 0 if the argument is a
122      valid attribute set specifier; otherwise the function returns -1.
123     </para>
124
125     <para>
126      The grammar of the PQF is as follows:
127     </para>
128
129     <literallayout>
130      query ::= top-set query-struct.
131
132      top-set ::= &lsqb; '@attrset' string &rsqb;
133
134      query-struct ::= attr-spec | simple | complex | '@term' term-type query
135
136      attr-spec ::= '@attr' &lsqb; string &rsqb; string query-struct
137
138      complex ::= operator query-struct query-struct.
139
140      operator ::= '@and' | '@or' | '@not' | '@prox' proximity.
141
142      simple ::= result-set | term.
143
144      result-set ::= '@set' string.
145
146      term ::= string.
147
148      proximity ::= exclusion distance ordered relation which-code unit-code.
149
150      exclusion ::= '1' | '0' | 'void'.
151
152      distance ::= integer.
153
154      ordered ::= '1' | '0'.
155
156      relation ::= integer.
157
158      which-code ::= 'known' | 'private' | integer.
159
160      unit-code ::= integer.
161
162      term-type ::= 'general' | 'numeric' | 'string' | 'oid' | 'datetime' | 'null'.
163     </literallayout>
164
165     <para>
166      You will note that the syntax above is a fairly faithful
167      representation of RPN, except for the Attribute, which has been
168      moved a step away from the term, allowing you to associate one or more
169      attributes with an entire query structure. The parser will
170      automatically apply the given attributes to each term as required.
171     </para>
172
173     <para>
174      The @attr operator is followed by an attribute specification 
175      (<literal>attr-spec</literal> above). The specification consists
176      of an optional attribute set, an attribute type-value pair and
177      a sub-query. The attribute type-value pair is packed in one string:
178      an attribute type, an equals sign, and an attribute value, like this:
179      <literal>@attr 1=1003</literal>.
180      The type is always an integer but the value may be either an
181      integer or a string (if it doesn't start with a digit character).
182      A string attribute-value is encoded as a Type-1 ``complex''
183      attribute with the list of values containing the single string
184      specified, and including no semantic indicators.
185     </para>
186
187     <para>
188      Version 3 of the Z39.50 specification defines various encoding of terms.
189      Use <literal>@term </literal> <replaceable>type</replaceable>
190      <replaceable>string</replaceable>,
191      where type is one of: <literal>general</literal>,
192      <literal>numeric</literal> or <literal>string</literal>
193      (for InternationalString).
194      If no term type has been given, the <literal>general</literal> form
195      is used.  This is the only encoding allowed in both versions 2 and 3
196      of the Z39.50 standard.
197     </para>
198     
199     <sect3 id="PQF-prox">
200       <title>Using Proximity Operators with PQF</title>
201       <note>
202         <para>
203           This is an advanced topic, describing how to construct
204           queries that make very specific requirements on the
205           relative location of their operands.
206           You may wish to skip this section and go straight to
207           <link linkend="pqf-examples">the example PQF queries</link>.
208         </para>
209         <para>
210           <warning>
211             <para>
212               Most Z39.50 servers do not support proximity searching, or
213               support only a small subset of the full functionality that
214               can be expressed using the PQF proximity operator.  Be
215               aware that the ability to <emphasis>express</emphasis> a
216               query in PQF is no guarantee that any given server will
217               be able to <emphasis>execute</emphasis> it.
218             </para>
219           </warning>
220         </para>
221       </note>
222       <para>
223         The proximity operator <literal>@prox</literal> is a special
224         and more restrictive version of the conjunction operator
225         <literal>@and</literal>.  Its semantics are described in 
226         section 3.7.2 (Proximity) of Z39.50 the standard itself, which
227         can be read on-line at
228         <ulink url="http://lcweb.loc.gov/z3950/agency/markup/09.html"/>
229       </para>
230       <para>
231         In PQF, the proximity operation is represented by a sequence
232         of the form
233         <screen>
234 @prox <replaceable>exclusion</replaceable> <replaceable>distance</replaceable> <replaceable>ordered</replaceable> <replaceable>relation</replaceable> <replaceable>which-code</replaceable> <replaceable>unit-code</replaceable>
235         </screen>
236         in which the meanings of the parameters are as described in in
237         the standard, and they can take the following values:
238         <itemizedlist>
239           <listitem><formalpara><title>exclusion</title><para>
240             0 = false (i.e. the proximity condition specified by the
241             remaining parameters must be satisfied) or
242             1 = true (the proximity condition specified by the
243             remaining parameters must <emphasis>not</emphasis> be
244             satisifed).
245           </para></formalpara></listitem>
246           <listitem><formalpara><title>distance</title><para>
247             An integer specifying the difference between the locations
248             of the operands: e.g. two adjacent words would have
249             distance=1 since their locations differ by one unit.
250           </para></formalpara></listitem>
251           <listitem><formalpara><title>ordered</title><para>
252             1 = ordered (the operands must occur in the order the
253             query specifies them) or
254             0 = unordered (they may appear in either order).
255           </para></formalpara></listitem>
256           <listitem><formalpara><title>relation</title><para>
257             Recognised values are
258             1 (lessThan),
259             2 (lessThanOrEqual),
260             3 (equal),
261             4 (greaterThanOrEqual),
262             5 (greaterThan) and
263             6 (notEqual).
264           </para></formalpara></listitem>
265           <listitem><formalpara><title>which-code</title><para>
266             <literal>known</literal>
267             or
268             <literal>k</literal>
269             (the unit-code parameter is taken from the well-known list
270             of alternatives described in below) or
271             <literal>private</literal>
272             or
273             <literal>p</literal>
274             (the unit-code paramater has semantics specific to an
275             out-of-band agreement such as a profile).
276           </para></formalpara></listitem>
277           <listitem><formalpara><title>unit-code</title><para>
278             If the which-code parameter is <literal>known</literal>
279             then the recognised values are
280             1 (character),
281             2 (word),
282             3 (sentence),
283             4 (paragraph),
284             5 (section),
285             6 (chapter),
286             7 (document),
287             8 (element),
288             9 (subelement),
289             10 (elementType) and
290             11 (byte).
291             If which-code is <literal>private</literal> then the
292             acceptable values are determined by the profile.
293           </para></formalpara></listitem>
294         </itemizedlist>
295         (The numeric values of the relation and well-known unit-code
296         parameters are taken straight from
297         <ulink url="http://lcweb.loc.gov/z3950/agency/asn1.html#ProximityOperator"
298         >the ASN.1</ulink> of the proximity structure in the standard.)
299       </para>
300     </sect3>
301
302     <sect3 id="pqf-examples"><title>PQF queries</title>
303
304      <example><title>PQF queries using simple terms</title>
305       <para>
306        <screen>
307         dylan
308         "bob dylan"
309        </screen>
310       </para>
311      </example>
312      <example><title>PQF boolean operators</title>
313       <para>
314        <screen>
315         @or "dylan" "zimmerman"
316         @and @or dylan zimmerman when
317         @and when @or dylan zimmerman
318        </screen>
319       </para>
320      </example>
321      <example><title>PQF references to result sets</title>
322       <para>
323        <screen>
324         @set Result-1
325         @and @set seta setb
326        </screen>
327       </para>
328      </example>
329      <example><title>Attributes for terms</title>
330       <para>
331        <screen>
332         @attr 1=4 computer
333         @attr 1=4 @attr 4=1 "self portrait"
334         @attrset exp1 @attr 1=1 CategoryList
335         @attr gils 1=2008 Copenhagen
336         @attr 1=/book/title computer
337        </screen>
338       </para>
339      </example>
340      <example><title>PQF Proximity queries</title>
341       <para>
342        <screen>
343         @prox 0 3 1 2 k 2 dylan zimmerman
344        </screen>
345        <note><para>
346          Here the parameters 0, 3, 1, 2, k and 2 represent exclusion,
347          distance, ordered, relation, which-code and unit-code, in that
348          order.  So:
349          <itemizedlist>
350           <listitem><para>
351             exclusion = 0: the proximity condition must hold
352            </para></listitem>
353           <listitem><para>
354             distance = 3: the terms must be three units apart
355            </para></listitem>
356           <listitem><para>
357             ordered = 1: they must occur in the order they are specified
358            </para></listitem>
359           <listitem><para>
360             relation = 2: lessThanOrEqual (to the distance of 3 units)
361            </para></listitem>
362           <listitem><para>
363             which-code is ``known'', so the standard unit-codes are used
364            </para></listitem>
365           <listitem><para>
366             unit-code = 2: word.
367            </para></listitem>
368          </itemizedlist>
369          So the whole proximity query means that the words
370          <literal>dylan</literal> and <literal>zimmerman</literal> must
371          both occur in the record, in that order, differing in position
372          by three or fewer words (i.e. with two or fewer words between
373          them.)  The query would find ``Bob Dylan, aka. Robert
374          Zimmerman'', but not ``Bob Dylan, born as Robert Zimmerman''
375          since the distance in this case is four.
376         </para></note>
377       </para>
378      </example>
379      <example><title>PQF specification of search term</title>
380       <para>
381        <screen>
382         @term string "a UTF-8 string, maybe?"
383        </screen>
384       </para>
385      </example>
386      <example><title>PQF mixed queries</title>
387       <para>
388        <screen>
389         @or @and bob dylan @set Result-1
390         
391         @attr 4=1 @and @attr 1=1 "bob dylan" @attr 1=4 "slow train coming"
392         
393         @and @attr 2=4 @attr gils 1=2038 -114 @attr 2=2 @attr gils 1=2039 -109
394       </screen>
395        <note>
396         <para>
397          The last of these examples is a spatial search: in
398          <ulink url="http://www.gils.net/prof_v2.html#sec_7_4"
399           >the GILS attribute set</ulink>,
400          access point
401          2038 indicates West Bounding Coordinate and
402          2030 indicates East Bounding Coordinate,
403          so the query is for areas extending from -114 degrees
404          to no more than -109 degrees.
405         </para>
406        </note>
407       </para>
408      </example>
409     </sect3>
410    </sect2>
411    <sect2 id="CCL"><title>CCL</title>
412
413     <para>
414      Not all users enjoy typing in prefix query structures and numerical
415      attribute values, even in a minimalistic test client. In the library
416      world, the more intuitive Common Command Language - CCL (ISO 8777)
417      has enjoyed some popularity - especially before the widespread
418      availability of graphical interfaces. It is still useful in
419      applications where you for some reason or other need to provide a
420      symbolic language for expressing boolean query structures.
421     </para>
422
423     <para>
424      The EUROPAGATE research project working under the Libraries programme
425      of the European Commission's DG XIII has, amongst other useful tools,
426      implemented a general-purpose CCL parser which produces an output
427      structure that can be trivially converted to the internal RPN
428      representation of &yaz; (The <literal>Z_RPNQuery</literal> structure).
429      Since the CCL utility - along with the rest of the software
430      produced by EUROPAGATE - is made freely available on a liberal
431      license, it is included as a supplement to &yaz;.
432     </para>
433
434     <sect3><title>CCL Syntax</title>
435
436      <para>
437       The CCL parser obeys the following grammar for the FIND argument.
438       The syntax is annotated by in the lines prefixed by
439       <literal>&dash;&dash;</literal>.
440      </para>
441
442      <screen>
443       CCL-Find ::= CCL-Find Op Elements
444                 | Elements.
445
446       Op ::= "and" | "or" | "not"
447       -- The above means that Elements are separated by boolean operators.
448
449       Elements ::= '(' CCL-Find ')'
450                 | Set
451                 | Terms
452                 | Qualifiers Relation Terms
453                 | Qualifiers Relation '(' CCL-Find ')'
454                 | Qualifiers '=' string '-' string
455       -- Elements is either a recursive definition, a result set reference, a
456       -- list of terms, qualifiers followed by terms, qualifiers followed
457       -- by a recursive definition or qualifiers in a range (lower - upper).
458
459       Set ::= 'set' = string
460       -- Reference to a result set
461
462       Terms ::= Terms Prox Term
463              | Term
464       -- Proximity of terms.
465
466       Term ::= Term string
467             | string
468       -- This basically means that a term may include a blank
469
470       Qualifiers ::= Qualifiers ',' string
471                   | string
472       -- Qualifiers is a list of strings separated by comma
473
474       Relation ::= '=' | '>=' | '&lt;=' | '&lt;>' | '>' | '&lt;'
475       -- Relational operators. This really doesn't follow the ISO8777
476       -- standard.
477
478       Prox ::= '%' | '!'
479       -- Proximity operator
480
481      </screen>
482      
483      <example><title>CCL queries</title>
484       <para>
485        The following queries are all valid:
486       </para>
487       
488       <screen>
489        dylan
490        
491        "bob dylan"
492        
493        dylan or zimmerman
494        
495        set=1
496        
497        (dylan and bob) or set=1
498        
499       </screen>
500       <para>
501        Assuming that the qualifiers <literal>ti</literal>,
502        <literal>au</literal>
503        and <literal>date</literal> are defined we may use:
504       </para>
505       
506       <screen>
507        ti=self portrait
508        
509        au=(bob dylan and slow train coming)
510
511        date>1980 and (ti=((self portrait)))
512        
513       </screen>
514      </example>
515      
516     </sect3>
517     <sect3><title>CCL Qualifiers</title>
518      
519      <para>
520       Qualifiers are used to direct the search to a particular searchable
521       index, such as title (ti) and author indexes (au). The CCL standard
522       itself doesn't specify a particular set of qualifiers, but it does
523       suggest a few short-hand notations. You can customize the CCL parser
524       to support a particular set of qualifiers to reflect the current target
525       profile. Traditionally, a qualifier would map to a particular
526       use-attribute within the BIB-1 attribute set. It is also
527       possible to set other attributes, such as the structure
528       attribute.
529      </para>
530
531      <para>
532       A  CCL profile is a set of predefined CCL qualifiers that may be
533       read from a file or set in the CCL API.
534       The YAZ client reads its CCL qualifiers from a file named
535       <filename>default.bib</filename>. There are four types of
536       lines in a CCL profile: qualifier specification,
537       qualifier alias, comments and directives.
538      </para>
539      <sect4><title id="qualifier-specification">Qualifier specification</title>
540       <para>
541        A qualifier specification is of the form:
542       </para>
543       
544       <para>
545        <replaceable>qualifier-name</replaceable>  
546        [<replaceable>attributeset</replaceable><literal>,</literal>]<replaceable>type</replaceable><literal>=</literal><replaceable>val</replaceable>
547        [<replaceable>attributeset</replaceable><literal>,</literal>]<replaceable>type</replaceable><literal>=</literal><replaceable>val</replaceable> ...      
548       </para>
549       
550       <para>
551        where <replaceable>qualifier-name</replaceable> is the name of the
552        qualifier to be used (eg. <literal>ti</literal>),
553        <replaceable>type</replaceable> is attribute type in the attribute
554        set (Bib-1 is used if no attribute set is given) and
555        <replaceable>val</replaceable> is attribute value.
556        The <replaceable>type</replaceable> can be specified as an
557        integer or as it be specified either as a single-letter:
558        <literal>u</literal> for use, 
559        <literal>r</literal> for relation,<literal>p</literal> for position,
560        <literal>s</literal> for structure,<literal>t</literal> for truncation
561        or <literal>c</literal> for completeness.
562        The attributes for the special qualifier name <literal>term</literal>
563        are used when no CCL qualifier is given in a query.
564        <table><title>Common Bib-1 attributes</title>
565         <tgroup cols="2">
566          <colspec colwidth="2*" colname="type"></colspec>
567          <colspec colwidth="9*" colname="description"></colspec>
568          <thead>
569           <row>
570            <entry>Type</entry>
571            <entry>Description</entry>
572           </row>
573          </thead>
574          <tbody>
575           <row>
576            <entry><literal>u=</literal><replaceable>value</replaceable></entry>
577            <entry>
578             Use attribute. Common use attributes are
579             1 Personal-name, 4 Title, 7 ISBN, 8 ISSN, 30 Date,
580             62 Subject, 1003 Author), 1016 Any. Specify value
581             as an integer.
582            </entry>
583           </row>
584
585           <row>
586            <entry><literal>r=</literal><replaceable>value</replaceable></entry>
587            <entry>
588             Relation attribute. Common values are
589             1 &lt;, 2 &lt;=, 3 =, 4 &gt;=, 5 &gt;, 6 &lt;&gt;,
590             100 phonetic, 101 stem, 102 relevance, 103 always matches.
591            </entry>
592           </row>
593
594           <row>
595            <entry><literal>p=</literal><replaceable>value</replaceable></entry>
596            <entry>
597             Position attribute. Values: 1 first in field, 2
598             first in any subfield, 3 any position in field.
599            </entry>
600           </row>
601
602           <row>
603            <entry><literal>s=</literal><replaceable>value</replaceable></entry>
604            <entry>
605             Structure attribute. Values: 1 phrase, 2 word,
606             3 key, 4 year, 5 date, 6 word list, 100 date (un),
607             101 name (norm), 102 name (un), 103 structure, 104 urx,
608             105 free-form-text, 106 document-text, 107 local-number,
609             108 string, 109 numeric string.
610            </entry>
611           </row>
612
613           <row>
614            <entry><literal>t=</literal><replaceable>value</replaceable></entry>
615            <entry>
616             Truncation attribute. Values: 1 right, 2 left,
617             3 left&amp; right, 100 none, 101 process #, 102 regular-1,
618             103 regular-2, 104 CCL.
619            </entry>
620           </row>
621
622           <row>
623            <entry><literal>c=</literal><replaceable>value</replaceable></entry>
624            <entry>
625             Completeness attribute. Values: 1 incomplete subfield,
626             2 complete subfield, 3 complete field.
627            </entry>
628           </row>
629
630          </tbody>
631          </tgroup>
632         </table>
633       </para>
634       <para>
635        The complete list of Bib-1 attributes can be found 
636        <ulink url="http://lcweb.loc.gov/z3950/agency/defns/bib1.html">
637         here
638        </ulink>.
639       </para>
640       <para>
641        It is also possible to specify non-numeric attribute values, 
642        which are used in combination with certain types.
643        The special combinations are:
644        
645        <table><title>Special attribute combos</title>
646         <tgroup cols="2">
647          <colspec colwidth="2*" colname="name"></colspec>
648          <colspec colwidth="9*" colname="description"></colspec>
649          <thead>
650           <row>
651            <entry>Name</entry>
652            <entry>Description</entry>
653           </row>
654          </thead>
655          <tbody>
656           <row>
657            <entry><literal>s=pw</literal></entry><entry>
658             The structure is set to either word or phrase depending
659             on the number of tokens in a term (phrase-word).
660            </entry>
661           </row>
662           <row>
663            <entry><literal>s=al</literal></entry><entry>
664             Each token in the term is ANDed. (and-list).
665             This does not set the structure at all.
666            </entry>
667           </row>
668           
669           <row><entry><literal>s=ol</literal></entry><entry>
670             Each token in the term is ORed. (or-list).
671             This does not set the structure at all.
672            </entry>
673           </row>
674           
675           <row><entry><literal>r=o</literal></entry><entry>
676             Allows operators greather-than, less-than, ... equals and
677             sets relation attribute accordingly (relation ordered).
678            </entry>
679           </row>
680           
681           <row><entry><literal>t=l</literal></entry><entry>
682             Allows term to be left-truncated.
683             If term is of the form <literal>?x</literal>, the resulting
684             Type-1 term is <literal>x</literal> and truncation is left.
685            </entry>
686           </row>
687           
688           <row><entry><literal>t=r</literal></entry><entry>
689             Allows term to be right-truncated.
690             If term is of the form <literal>x?</literal>, the resulting
691             Type-1 term is <literal>x</literal> and truncation is right.
692            </entry>
693           </row>
694           
695           <row><entry><literal>t=n</literal></entry><entry>
696             If term is does not include <literal>?</literal>, the
697             truncation attribute is set to none (100).
698            </entry>
699           </row>
700           
701           <row><entry><literal>t=b</literal></entry><entry>
702             Allows term to be both left&amp;right truncated.
703             If term is of the form <literal>?x?</literal>, the
704             resulting term is <literal>x</literal> and trunctation is
705             set to both left&amp;right.
706            </entry>
707           </row>
708          </tbody>
709         </tgroup>
710        </table>
711       </para>
712       <example><title>CCL profile</title>
713        <para>
714         Consider the following definition:
715        </para>
716        
717        <screen>
718         ti       u=4 s=1
719         au       u=1 s=1
720         term     s=105
721         ranked   r=102
722         date     u=30 r=o
723       </screen>
724        <para>
725         Four qualifiers are defined - <literal>ti</literal>, 
726         <literal>au</literal>, <literal>ranked</literal> and
727         <literal>date</literal>.
728        </para>
729        <para>
730         <literal>ti</literal> and <literal>au</literal> both set 
731         structure attribute to phrase (s=1).
732         <literal>ti</literal>
733         sets the use-attribute to 4. <literal>au</literal> sets the
734         use-attribute to 1.
735         When no qualifiers are used in the query the structure-attribute is
736         set to free-form-text (105) (rule for <literal>term</literal>).
737         The <literal>date</literal> sets the relation attribute to
738         the relation used in the CCL query and sets the use attribute
739         to 30 (Bib-1 Date).
740        </para>
741        <para>
742         You can combine attributes. To Search for "ranked title" you
743         can do 
744         <screen>
745          ti,ranked=knuth computer
746         </screen>
747         which will set relation=ranked, use=title, structure=phrase.
748        </para>
749        <para>
750         Query
751         <screen>
752          year > 1980
753         </screen>
754         is a valid query, while
755         <screen>
756          ti > 1980
757         </screen>
758         is invalid.
759        </para>
760       </example>
761      </sect4>
762      <sect4><title>Qualifier alias</title>
763       <para>
764        A qualifier alias is of the form:
765       </para>
766       <para>
767        <replaceable>q</replaceable>  
768        <replaceable>q1</replaceable> <replaceable>q2</replaceable> ..
769       </para>
770       <para>
771        which declares <replaceable>q</replaceable> to
772        be an alias for <replaceable>q1</replaceable>, 
773        <replaceable>q2</replaceable>... such that the CCL
774        query <replaceable>q=x</replaceable> is equivalent to
775        <replaceable>q1=x or w2=x or ...</replaceable>.
776       </para>
777      </sect4>
778
779      <sect4><title>Comments</title>
780       <para>
781        Lines with white space or lines that begin with
782        character <literal>#</literal> are treated as comments.
783       </para>
784      </sect4>
785
786      <sect4><title>Directives</title>
787       <para>
788        Directive specifications takes the form
789       </para>
790       <para><literal>@</literal><replaceable>directive</replaceable> <replaceable>value</replaceable>
791       </para>
792       <table><title>CCL directives</title>
793        <tgroup cols="3">
794         <colspec colwidth="2*" colname="name"></colspec>
795         <colspec colwidth="8*" colname="description"></colspec>
796         <colspec colwidth="1*" colname="default"></colspec>
797         <thead>
798          <row>
799           <entry>Name</entry>
800           <entry>Description</entry>
801           <entry>Default</entry>
802          </row>
803         </thead>
804         <tbody>
805          <row>
806           <entry>truncation</entry>
807           <entry>Truncation character</entry>
808           <entry><literal>?</literal></entry>
809          </row>
810          <row>
811           <entry>field</entry>
812           <entry>Specifies how multiple fields are to be
813            combined. There are two modes: <literal>or</literal>:
814            multiple qualifier fields are ORed,
815            <literal>merge</literal>: attributes for the qualifier
816            fields are merged and assigned to one term.
817            </entry>
818           <entry><literal>merge</literal></entry>
819          </row>
820          <row>
821           <entry>case</entry>
822           <entry>Specificies if CCL operatores and qualifiers should be
823            compared with case sensitivity or not. Specify 0 for
824            case sensitive; 1 for case insensitive.</entry>
825           <entry><literal>0</literal></entry>
826          </row>
827
828          <row>
829           <entry>and</entry>
830           <entry>Specifies token for CCL operator AND.</entry>
831           <entry><literal>and</literal></entry>
832          </row>
833
834          <row>
835           <entry>or</entry>
836           <entry>Specifies token for CCL operator OR.</entry>
837           <entry><literal>or</literal></entry>
838          </row>
839
840          <row>
841           <entry>not</entry>
842           <entry>Specifies token for CCL operator NOT.</entry>
843           <entry><literal>not</literal></entry>
844          </row>
845
846          <row>
847           <entry>set</entry>
848           <entry>Specifies token for CCL operator SET.</entry>
849           <entry><literal>set</literal></entry>
850          </row>
851         </tbody>
852         </tgroup>
853       </table>
854      </sect4>
855     </sect3>
856     <sect3><title>CCL API</title>
857      <para>
858       All public definitions can be found in the header file
859       <filename>ccl.h</filename>. A profile identifier is of type
860       <literal>CCL_bibset</literal>. A profile must be created with the call
861       to the function <function>ccl_qual_mk</function> which returns a profile
862       handle of type <literal>CCL_bibset</literal>.
863      </para>
864
865      <para>
866       To read a file containing qualifier definitions the function
867       <function>ccl_qual_file</function> may be convenient. This function
868       takes an already opened <literal>FILE</literal> handle pointer as
869       argument along with a <literal>CCL_bibset</literal> handle.
870      </para>
871
872      <para>
873       To parse a simple string with a FIND query use the function
874      </para>
875      <screen>
876 struct ccl_rpn_node *ccl_find_str (CCL_bibset bibset, const char *str,
877                                    int *error, int *pos);
878      </screen>
879      <para>
880       which takes the CCL profile (<literal>bibset</literal>) and query
881       (<literal>str</literal>) as input. Upon successful completion the RPN
882       tree is returned. If an error occur, such as a syntax error, the integer
883       pointed to by <literal>error</literal> holds the error code and
884       <literal>pos</literal> holds the offset inside query string in which
885       the parsing failed.
886      </para>
887
888      <para>
889       An English representation of the error may be obtained by calling
890       the <literal>ccl_err_msg</literal> function. The error codes are
891       listed in <filename>ccl.h</filename>.
892      </para>
893
894      <para>
895       To convert the CCL RPN tree (type
896       <literal>struct ccl_rpn_node *</literal>)
897       to the Z_RPNQuery of YAZ the function <function>ccl_rpn_query</function>
898       must be used. This function which is part of YAZ is implemented in
899       <filename>yaz-ccl.c</filename>.
900       After calling this function the CCL RPN tree is probably no longer
901       needed. The <literal>ccl_rpn_delete</literal> destroys the CCL RPN tree.
902      </para>
903
904      <para>
905       A CCL profile may be destroyed by calling the
906       <function>ccl_qual_rm</function> function.
907      </para>
908
909      <para>
910       The token names for the CCL operators may be changed by setting the
911       globals (all type <literal>char *</literal>)
912       <literal>ccl_token_and</literal>, <literal>ccl_token_or</literal>,
913       <literal>ccl_token_not</literal> and <literal>ccl_token_set</literal>.
914       An operator may have aliases, i.e. there may be more than one name for
915       the operator. To do this, separate each alias with a space character.
916      </para>
917     </sect3>
918    </sect2>
919    <sect2 id="tools.cql"><title>CQL</title>
920     <para>
921      <ulink url="http://www.loc.gov/z3950/agency/zing/cql/">CQL</ulink>
922       - Common Query Language - was defined for the
923      <ulink url="http://www.loc.gov/z3950/agency/zing/srw/">SRW</ulink>
924      protocol.
925      In many ways CQL has a similar syntax to CCL.
926      The objective of CQL is different. Where CCL aims to be
927      an end-user language, CQL is <emphasis>the</emphasis> protocol
928      query language for SRW.
929     </para>
930     <tip>
931      <para>
932       If you are new to CQL, read the 
933       <ulink url="http://zing.z3950.org/cql/intro.html">Gentle
934        Introduction</ulink>.
935      </para>
936     </tip>
937     <para>
938      The CQL parser in &yaz; provides the following:
939      <itemizedlist>
940       <listitem>
941        <para>
942         It parses and validates a CQL query.
943        </para>
944       </listitem>
945       <listitem>
946        <para>
947         It generates a C structure that allows you to convert
948         a CQL query to some other query language, such as SQL.
949        </para>
950       </listitem>
951       <listitem>
952        <para>
953         The parser converts a valid CQL query to PQF, thus providing a
954         way to use CQL for both SRW/SRU servers and Z39.50 targets at the
955         same time.
956        </para>
957       </listitem>
958       <listitem>
959        <para>
960         The parser converts CQL to
961         <ulink url="http://www.loc.gov/z3950/agency/zing/cql/xcql.html">
962          XCQL</ulink>.
963         XCQL is an XML representation of CQL.
964         XCQL is part of the SRW specification. However, since SRU
965         supports CQL only, we don't expect XCQL to be widely used.
966         Furthermore, CQL has the advantage over XCQL that it is
967         easy to read.
968        </para>
969       </listitem>
970      </itemizedlist>
971     </para>
972     <sect3 id="tools.cql.parsing"><title>CQL parsing</title>
973      <para>
974       A CQL parser is represented by the <literal>CQL_parser</literal>
975       handle. Its contents should be considered &yaz; internal (private).
976       <synopsis>
977 #include &lt;yaz/cql.h&gt;
978
979 typedef struct cql_parser *CQL_parser;
980
981 CQL_parser cql_parser_create(void);
982 void cql_parser_destroy(CQL_parser cp);
983       </synopsis>
984      A parser is created by <function>cql_parser_create</function> and
985      is destroyed by <function>cql_parser_destroy</function>.
986      </para>
987      <para>
988       To parse a CQL query string, the following function
989       is provided:
990       <synopsis>
991 int cql_parser_string(CQL_parser cp, const char *str);
992       </synopsis>
993       A CQL query is parsed by the <function>cql_parser_string</function>
994       which takes a query <parameter>str</parameter>.
995       If the query was valid (no syntax errors), then zero is returned;
996       otherwise -1 is returned to indicate a syntax error.
997      </para>
998      <para>
999       <synopsis>
1000 int cql_parser_stream(CQL_parser cp,
1001                       int (*getbyte)(void *client_data),
1002                       void (*ungetbyte)(int b, void *client_data),
1003                       void *client_data);
1004
1005 int cql_parser_stdio(CQL_parser cp, FILE *f);
1006       </synopsis>
1007       The functions <function>cql_parser_stream</function> and
1008       <function>cql_parser_stdio</function> parses a CQL query
1009       - just like <function>cql_parser_string</function>.
1010       The only difference is that the CQL query can be
1011       fed to the parser in different ways.
1012       The <function>cql_parser_stream</function> uses a generic
1013       byte stream as input. The <function>cql_parser_stdio</function>
1014       uses a <literal>FILE</literal> handle which is opened for reading.
1015      </para>
1016     </sect3>
1017     
1018     <sect3 id="tools.cql.tree"><title>CQL tree</title>
1019      <para>
1020       The the query string is valid, the CQL parser
1021       generates a tree representing the structure of the
1022       CQL query.
1023      </para>
1024      <para>
1025       <synopsis>
1026 struct cql_node *cql_parser_result(CQL_parser cp);
1027       </synopsis>
1028       <function>cql_parser_result</function> returns the
1029       a pointer to the root node of the resulting tree.
1030      </para>
1031      <para>
1032       Each node in a CQL tree is represented by a 
1033       <literal>struct cql_node</literal>.
1034       It is defined as follows:
1035       <synopsis>
1036 #define CQL_NODE_ST 1
1037 #define CQL_NODE_BOOL 2
1038 #define CQL_NODE_MOD 3
1039 struct cql_node {
1040     int which;
1041     union {
1042         struct {
1043             char *index;
1044             char *term;
1045             char *relation;
1046             struct cql_node *modifiers;
1047             struct cql_node *prefixes;
1048         } st;
1049         struct {
1050             char *value;
1051             struct cql_node *left;
1052             struct cql_node *right;
1053             struct cql_node *modifiers;
1054             struct cql_node *prefixes;
1055         } boolean;
1056         struct {
1057             char *name;
1058             char *value;
1059             struct cql_node *next;
1060         } mod;
1061     } u;
1062 };
1063       </synopsis>
1064       There are three kinds of nodes, search term (ST), boolean (BOOL),
1065       and modifier (MOD).
1066      </para>
1067      <para>
1068       The search term node has five members:
1069       <itemizedlist>
1070        <listitem>
1071         <para>
1072          <literal>index</literal>: index for search term.
1073          If an index is unspecified for a search term,
1074          <literal>index</literal> will be NULL.
1075         </para>
1076        </listitem>
1077        <listitem>
1078         <para>
1079          <literal>term</literal>: the search term itself.
1080         </para>
1081        </listitem>
1082        <listitem>
1083         <para>
1084          <literal>relation</literal>: relation for search term.
1085         </para>
1086        </listitem>
1087        <listitem>
1088         <para>
1089          <literal>modifiers</literal>: relation modifiers for search
1090          term. The <literal>modifiers</literal> is a simple linked
1091          list (NULL for last entry). Each relation modifier node
1092          is of type <literal>MOD</literal>.
1093         </para>
1094        </listitem>
1095        <listitem>
1096         <para>
1097          <literal>prefixes</literal>: index prefixes for search
1098          term. The <literal>prefixes</literal> is a simple linked
1099          list (NULL for last entry). Each prefix node
1100          is of type <literal>MOD</literal>.
1101         </para>
1102        </listitem>
1103       </itemizedlist>
1104      </para>
1105
1106      <para>
1107       The boolean node represents both <literal>and</literal>,
1108       <literal>or</literal>, not as well as
1109       proximity.
1110       <itemizedlist>
1111        <listitem>
1112         <para>
1113          <literal>left</literal> and <literal>right</literal>: left
1114          - and right operand respectively.
1115         </para>
1116        </listitem>
1117        <listitem>
1118         <para>
1119          <literal>modifiers</literal>: proximity arguments.
1120         </para>
1121        </listitem>
1122        <listitem>
1123         <para>
1124          <literal>prefixes</literal>: index prefixes.
1125          The <literal>prefixes</literal> is a simple linked
1126          list (NULL for last entry). Each prefix node
1127          is of type <literal>MOD</literal>.
1128         </para>
1129        </listitem>
1130       </itemizedlist>
1131      </para>
1132
1133      <para>
1134       The modifier node is a "utility" node used for name-value pairs,
1135       such as prefixes, proximity arguements, etc.
1136       <itemizedlist>
1137        <listitem>
1138         <para>
1139          <literal>name</literal> name of mod node.
1140         </para>
1141        </listitem>
1142        <listitem>
1143         <para>
1144          <literal>value</literal> value of mod node.
1145         </para>
1146        </listitem>
1147        <listitem>
1148         <para>
1149          <literal>next</literal>: pointer to next node which is
1150          always a mod node (NULL for last entry).
1151         </para>
1152        </listitem>
1153       </itemizedlist>
1154      </para>
1155
1156     </sect3>
1157     <sect3 id="tools.cql.pqf"><title>CQL to PQF conversion</title>
1158      <para>
1159       Conversion to PQF (and Z39.50 RPN) is tricky by the fact
1160       that the resulting RPN depends on the Z39.50 target
1161       capabilities (combinations of supported attributes). 
1162       In addition, the CQL and SRW operates on index prefixes
1163       (URI or strings), whereas the RPN uses Object Identifiers
1164       for attribute sets.
1165      </para>
1166      <para>
1167       The CQL library of &yaz; defines a <literal>cql_transform_t</literal>
1168       type. It represents a particular mapping between CQL and RPN.
1169       This handle is created and destroyed by the functions:
1170      <synopsis>
1171 cql_transform_t cql_transform_open_FILE (FILE *f);
1172 cql_transform_t cql_transform_open_fname(const char *fname);
1173 void cql_transform_close(cql_transform_t ct);
1174       </synopsis>
1175       The first two functions create a tranformation handle from
1176       either an already open FILE or from a filename respectively.
1177      </para>
1178      <para>
1179       The handle is destroyed by <function>cql_transform_close</function> 
1180       in which case no further reference of the handle is allowed.
1181      </para>
1182      <para>
1183       When a <literal>cql_transform_t</literal> handle has been created
1184       you can convert to RPN.
1185       <synopsis>
1186 int cql_transform_buf(cql_transform_t ct,
1187                       struct cql_node *cn, char *out, int max);
1188       </synopsis>
1189       This function converts the CQL tree <literal>cn</literal> 
1190       using handle <literal>ct</literal>.
1191       For the resulting PQF, you supply a buffer <literal>out</literal>
1192       which must be able to hold at at least <literal>max</literal>
1193       characters.
1194      </para>
1195      <para>
1196       If conversion failed, <function>cql_transform_buf</function>
1197       returns a non-zero SRW error code; otherwise zero is returned
1198       (conversion successful).  The meanings of the numeric error
1199       codes are listed in the SRW specifications at
1200       <ulink url="http://www.loc.gov/srw/diagnostic-list.html"/>
1201      </para>
1202      <para>
1203       If conversion fails, more information can be obtained by calling
1204       <synopsis>
1205 int cql_transform_error(cql_transform_t ct, char **addinfop);
1206       </synopsis>
1207       This function returns the most recently returned numeric
1208       error-code and sets the string-pointer at
1209       <literal>*addinfop</literal> to point to a string containing
1210       additional information about the error that occurred: for
1211       example, if the error code is 15 (``Illegal or unsupported context
1212       set''), the additional information is the name of the requested
1213       context set that was not recognised.
1214      </para>
1215      <para>
1216       The SRW error-codes may be translated into brief human-readable
1217       error messages using
1218       <synopsis>
1219 const char *cql_strerror(int code);
1220       </synopsis>
1221      </para>
1222      <para>
1223       If you wish to be able to produce a PQF result in a different
1224       way, there are two alternatives.
1225       <synopsis>
1226 void cql_transform_pr(cql_transform_t ct,
1227                       struct cql_node *cn,
1228                       void (*pr)(const char *buf, void *client_data),
1229                       void *client_data);
1230
1231 int cql_transform_FILE(cql_transform_t ct,
1232                        struct cql_node *cn, FILE *f);
1233       </synopsis>
1234       The former function produces output to a user-defined
1235       output stream. The latter writes the result to an already
1236       open <literal>FILE</literal>.
1237      </para>
1238     </sect3>
1239     <sect3 id="tools.cql.map">
1240      <title>Specification of CQL to RPN mapping</title>
1241      <para>
1242       The file supplied to functions 
1243       <function>cql_transform_open_FILE</function>,
1244       <function>cql_transform_open_fname</function> follows
1245       a structure found in many Unix utilities.
1246       It consists of mapping specifications - one per line.
1247       Lines starting with <literal>#</literal> are ignored (comments).
1248      </para>
1249      <para>
1250       Each line is of the form
1251       <literallayout>
1252        <replaceable>CQL pattern</replaceable><literal> = </literal> <replaceable> RPN equivalent</replaceable>
1253       </literallayout>
1254      </para>
1255      <para>
1256       An RPN pattern is a simple attribute list. Each attribute pair
1257       takes the form:
1258       <literallayout>
1259        [<replaceable>set</replaceable>] <replaceable>type</replaceable><literal>=</literal><replaceable>value</replaceable>
1260       </literallayout>
1261       The attribute <replaceable>set</replaceable> is optional.
1262       The <replaceable>type</replaceable> is the attribute type,
1263       <replaceable>value</replaceable> the attribute value.
1264      </para>
1265      <para>
1266       The following CQL patterns are recognized:
1267       <variablelist>
1268        <varlistentry><term>
1269          <literal>index.</literal><replaceable>set</replaceable><literal>.</literal><replaceable>name</replaceable>
1270         </term>
1271         <listitem>
1272          <para>
1273           This pattern is invoked when a CQL index, such as 
1274           dc.title is converted. <replaceable>set</replaceable>
1275           and <replaceable>name</replaceable> are the context set and index
1276           name respectively.
1277           Typically, the RPN specifies an equivalent use attribute.
1278          </para>
1279          <para>
1280           For terms not bound by an index the pattern
1281           <literal>index.cql.serverChoice</literal> is used.
1282           Here, the prefix <literal>cql</literal> is defined as
1283           <literal>http://www.loc.gov/zing/cql/cql-indexes/v1.0/</literal>.
1284           If this pattern is not defined, the mapping will fail.
1285          </para>
1286         </listitem>
1287        </varlistentry>
1288        <varlistentry><term>
1289          <literal>qualifier.</literal><replaceable>set</replaceable><literal>.</literal><replaceable>name</replaceable>
1290          (DEPRECATED)
1291         </term>
1292         <listitem>
1293          <para>
1294           For backwards compatibility, this is recognised as a synonym of
1295           <literal>index.</literal><replaceable>set</replaceable><literal>.</literal><replaceable>name</replaceable>
1296          </para>
1297         </listitem>
1298        </varlistentry>
1299        <varlistentry><term>
1300          <literal>relation.</literal><replaceable>relation</replaceable>
1301         </term>
1302         <listitem>
1303          <para>
1304           This pattern specifies how a CQL relation is mapped to RPN.
1305           <replaceable>pattern</replaceable> is name of relation
1306           operator. Since <literal>=</literal> is used as
1307           separator between CQL pattern and RPN, CQL relations
1308           including <literal>=</literal> cannot be
1309           used directly. To avoid a conflict, the names
1310           <literal>ge</literal>,
1311           <literal>eq</literal>,
1312           <literal>le</literal>,
1313           must be used for CQL operators, greater-than-or-equal,
1314           equal, less-than-or-equal respectively.
1315           The RPN pattern is supposed to include a relation attribute.
1316          </para>
1317          <para>
1318           For terms not bound by a relation, the pattern
1319           <literal>relation.scr</literal> is used. If the pattern
1320           is not defined, the mapping will fail.
1321          </para>
1322          <para>
1323           The special pattern, <literal>relation.*</literal> is used
1324           when no other relation pattern is matched.
1325          </para>
1326         </listitem>
1327        </varlistentry>
1328
1329        <varlistentry><term>
1330          <literal>relationModifier.</literal><replaceable>mod</replaceable>
1331         </term>
1332         <listitem>
1333          <para>
1334           This pattern specifies how a CQL relation modifier is mapped to RPN.
1335           The RPN pattern is usually a relation attribute.
1336          </para>
1337         </listitem>
1338        </varlistentry>
1339
1340        <varlistentry><term>
1341          <literal>structure.</literal><replaceable>type</replaceable>
1342         </term>
1343         <listitem>
1344          <para>
1345           This pattern specifies how a CQL structure is mapped to RPN.
1346           Note that this CQL pattern is somewhat to similar to
1347           CQL pattern <literal>relation</literal>. 
1348           The <replaceable>type</replaceable> is a CQL relation.
1349          </para>
1350          <para>
1351           The pattern, <literal>structure.*</literal> is used
1352           when no other structure pattern is matched.
1353           Usually, the RPN equivalent specifies a structure attribute.
1354          </para>
1355         </listitem>
1356        </varlistentry>
1357
1358        <varlistentry><term>
1359          <literal>position.</literal><replaceable>type</replaceable>
1360         </term>
1361         <listitem>
1362          <para>
1363           This pattern specifies how the anchor (position) of
1364           CQL is mapped to RPN.
1365           The <replaceable>type</replaceable> is one
1366           of <literal>first</literal>, <literal>any</literal>,
1367           <literal>last</literal>, <literal>firstAndLast</literal>.
1368          </para>
1369          <para>
1370           The pattern, <literal>position.*</literal> is used
1371           when no other position pattern is matched.
1372          </para>
1373         </listitem>
1374        </varlistentry>
1375
1376        <varlistentry><term>
1377          <literal>set.</literal><replaceable>prefix</replaceable>
1378         </term>
1379         <listitem>
1380          <para>
1381           This specification defines a CQL context set for a given prefix.
1382           The value on the right hand side is the URI for the set - 
1383           <emphasis>not</emphasis> RPN. All prefixes used in
1384           index patterns must be defined this way.
1385          </para>
1386         </listitem>
1387        </varlistentry>
1388       </variablelist>
1389      </para>
1390      <example><title>CQL to RPN mapping file</title>
1391       <para>
1392        This simple file defines two context sets, three indexes and three
1393        relations, a position pattern and a default structure.
1394       </para>
1395       <programlisting><![CDATA[
1396        set.cql    = http://www.loc.gov/zing/cql/context-sets/cql/v1.1/
1397        set.dc     = http://www.loc.gov/zing/cql/dc-indexes/v1.0/
1398
1399        index.cql.serverChoice = 1=1016
1400        index.dc.title         = 1=4
1401        index.dc.subject       = 1=21
1402   
1403        relation.<                 = 2=1
1404        relation.eq                = 2=3
1405        relation.scr               = 2=3
1406
1407        position.any               = 3=3 6=1
1408
1409        structure.*                = 4=1
1410 ]]>
1411       </programlisting>
1412       <para>
1413        With the mappings above, the CQL query
1414        <screen>
1415         computer
1416        </screen>
1417        is converted to the PQF:
1418        <screen>
1419         @attr 1=1016 @attr 2=3 @attr 4=1 @attr 3=3 @attr 6=1 "computer"
1420        </screen>
1421        by rules <literal>index.cql.serverChoice</literal>,
1422        <literal>relation.scr</literal>, <literal>structure.*</literal>,
1423        <literal>position.any</literal>.
1424       </para>
1425       <para>
1426        CQL query
1427        <screen>
1428         computer^
1429        </screen>
1430        is rejected, since <literal>position.right</literal> is
1431        undefined.
1432       </para>
1433       <para>
1434        CQL query
1435        <screen>
1436         >my = "http://www.loc.gov/zing/cql/dc-indexes/v1.0/" my.title = x
1437        </screen>
1438        is converted to
1439        <screen>
1440         @attr 1=4 @attr 2=3 @attr 4=1 @attr 3=3 @attr 6=1 "x"
1441        </screen>
1442       </para>
1443      </example>
1444     </sect3>
1445     <sect3 id="tools.cql.xcql"><title>CQL to XCQL conversion</title>
1446      <para>
1447       Conversion from CQL to XCQL is trivial and does not
1448       require a mapping to be defined.
1449       There three functions to choose from depending on the
1450       way you wish to store the resulting output (XML buffer
1451       containing XCQL).
1452       <synopsis>
1453 int cql_to_xml_buf(struct cql_node *cn, char *out, int max);
1454 void cql_to_xml(struct cql_node *cn, 
1455                 void (*pr)(const char *buf, void *client_data),
1456                 void *client_data);
1457 void cql_to_xml_stdio(struct cql_node *cn, FILE *f);
1458       </synopsis>
1459       Function <function>cql_to_xml_buf</function> converts
1460       to XCQL and stores result in a user supplied buffer of a given
1461       max size.
1462      </para>
1463      <para>
1464       <function>cql_to_xml</function> writes the result in
1465       a user defined output stream.
1466       <function>cql_to_xml_stdio</function> writes to a
1467       a file.
1468      </para>
1469     </sect3>
1470    </sect2>
1471   </sect1>
1472   <sect1 id="tools.oid"><title>Object Identifiers</title>
1473
1474    <para>
1475     The basic YAZ representation of an OID is an array of integers,
1476     terminated with the value -1. The &odr; module provides two
1477     utility-functions to create and copy this type of data elements:
1478    </para>
1479
1480    <screen>
1481     Odr_oid *odr_getoidbystr(ODR o, char *str);
1482    </screen>
1483
1484    <para>
1485     Creates an OID based on a string-based representation using dots (.)
1486     to separate elements in the OID.
1487    </para>
1488
1489    <screen>
1490     Odr_oid *odr_oiddup(ODR odr, Odr_oid *o);
1491    </screen>
1492
1493    <para>
1494     Creates a copy of the OID referenced by the <emphasis>o</emphasis>
1495     parameter.
1496     Both functions take an &odr; stream as parameter. This stream is used to
1497     allocate memory for the data elements, which is released on a
1498     subsequent call to <function>odr_reset()</function> on that stream.
1499    </para>
1500
1501    <para>
1502     The OID module provides a higher-level representation of the
1503     family of object identifiers which describe the Z39.50 protocol and its
1504     related objects. The definition of the module interface is given in
1505     the <filename>oid.h</filename> file.
1506    </para>
1507
1508    <para>
1509     The interface is mainly based on the <literal>oident</literal> structure.
1510     The definition of this structure looks like this:
1511    </para>
1512
1513    <screen>
1514 typedef struct oident
1515 {
1516     oid_proto proto;
1517     oid_class oclass;
1518     oid_value value;
1519     int oidsuffix[OID_SIZE];
1520     char *desc;
1521 } oident;
1522    </screen>
1523
1524    <para>
1525     The proto field takes one of the values
1526    </para>
1527
1528    <screen>
1529     PROTO_Z3950
1530     PROTO_GENERAL
1531    </screen>
1532
1533    <para>
1534     Use <literal>PROTO_Z3950</literal> for Z39.50 Object Identifers,
1535     <literal>PROTO_GENERAL</literal> for other types (such as
1536     those associated with ILL).
1537    </para>
1538    <para>
1539
1540     The oclass field takes one of the values
1541    </para>
1542
1543    <screen>
1544     CLASS_APPCTX
1545     CLASS_ABSYN
1546     CLASS_ATTSET
1547     CLASS_TRANSYN
1548     CLASS_DIAGSET
1549     CLASS_RECSYN
1550     CLASS_RESFORM
1551     CLASS_ACCFORM
1552     CLASS_EXTSERV
1553     CLASS_USERINFO
1554     CLASS_ELEMSPEC
1555     CLASS_VARSET
1556     CLASS_SCHEMA
1557     CLASS_TAGSET
1558     CLASS_GENERAL
1559    </screen>
1560
1561    <para>
1562     corresponding to the OID classes defined by the Z39.50 standard.
1563
1564     Finally, the value field takes one of the values
1565    </para>
1566
1567    <screen>
1568     VAL_APDU
1569     VAL_BER
1570     VAL_BASIC_CTX
1571     VAL_BIB1
1572     VAL_EXP1
1573     VAL_EXT1
1574     VAL_CCL1
1575     VAL_GILS
1576     VAL_WAIS
1577     VAL_STAS
1578     VAL_DIAG1
1579     VAL_ISO2709
1580     VAL_UNIMARC
1581     VAL_INTERMARC
1582     VAL_CCF
1583     VAL_USMARC
1584     VAL_UKMARC
1585     VAL_NORMARC
1586     VAL_LIBRISMARC
1587     VAL_DANMARC
1588     VAL_FINMARC
1589     VAL_MAB
1590     VAL_CANMARC
1591     VAL_SBN
1592     VAL_PICAMARC
1593     VAL_AUSMARC
1594     VAL_IBERMARC
1595     VAL_EXPLAIN
1596     VAL_SUTRS
1597     VAL_OPAC
1598     VAL_SUMMARY
1599     VAL_GRS0
1600     VAL_GRS1
1601     VAL_EXTENDED
1602     VAL_RESOURCE1
1603     VAL_RESOURCE2
1604     VAL_PROMPT1
1605     VAL_DES1
1606     VAL_KRB1
1607     VAL_PRESSET
1608     VAL_PQUERY
1609     VAL_PCQUERY
1610     VAL_ITEMORDER
1611     VAL_DBUPDATE
1612     VAL_EXPORTSPEC
1613     VAL_EXPORTINV
1614     VAL_NONE
1615     VAL_SETM
1616     VAL_SETG
1617     VAL_VAR1
1618     VAL_ESPEC1
1619    </screen>
1620
1621    <para>
1622     again, corresponding to the specific OIDs defined by the standard.
1623     Refer to the
1624     <ulink url="http://lcweb.loc.gov/z3950/agency/defns/oids.html">
1625      Registry of Z39.50 Object Identifiers</ulink> for the
1626      whole list.
1627    </para>
1628
1629    <para>
1630     The desc field contains a brief, mnemonic name for the OID in question.
1631    </para>
1632
1633    <para>
1634     The function
1635    </para>
1636
1637    <screen>
1638     struct oident *oid_getentbyoid(int *o);
1639    </screen>
1640
1641    <para>
1642     takes as argument an OID, and returns a pointer to a static area
1643     containing an <literal>oident</literal> structure. You typically use
1644     this function when you receive a PDU containing an OID, and you wish
1645     to branch out depending on the specific OID value.
1646    </para>
1647
1648    <para>
1649     The function
1650    </para>
1651
1652    <screen>
1653     int *oid_ent_to_oid(struct oident *ent, int *dst);
1654    </screen>
1655
1656    <para>
1657     Takes as argument an <literal>oident</literal> structure - in which
1658     the <literal>proto</literal>, <literal>oclass</literal>/, and
1659     <literal>value</literal> fields are assumed to be set correctly -
1660     and returns a pointer to a the buffer as given by <literal>dst</literal>
1661     containing the base
1662     representation of the corresponding OID. The function returns
1663     NULL and the array dst is unchanged if a mapping couldn't place.
1664     The array <literal>dst</literal> should be at least of size
1665     <literal>OID_SIZE</literal>.
1666    </para>
1667    <para>
1668
1669     The <function>oid_ent_to_oid()</function> function can be used whenever
1670     you need to prepare a PDU containing one or more OIDs. The separation of
1671     the <literal>protocol</literal> element from the remainder of the
1672     OID-description makes it simple to write applications that can
1673     communicate with either Z39.50 or OSI SR-based applications.
1674    </para>
1675
1676    <para>
1677     The function
1678    </para>
1679
1680    <screen>
1681     oid_value oid_getvalbyname(const char *name);
1682    </screen>
1683
1684    <para>
1685     takes as argument a mnemonic OID name, and returns the
1686     <literal>/value</literal> field of the first entry in the database that 
1687     contains the given name in its <literal>desc</literal> field.
1688    </para>
1689
1690    <para>
1691     Three utility functions are provided for translating OIDs'
1692     symbolic names (e.g. <literal>Usmarc</literal> into OID structures
1693     (int arrays) and strings containing the OID in dotted notation
1694     (e.g. <literal>1.2.840.10003.9.5.1</literal>).  They are:
1695    </para>
1696
1697    <screen>
1698     int *oid_name_to_oid(oid_class oclass, const char *name, int *oid);
1699     char *oid_to_dotstring(const int *oid, char *oidbuf);
1700     char *oid_name_to_dotstring(oid_class oclass, const char *name, char *oidbuf);
1701    </screen>
1702
1703    <para>
1704     <literal>oid_name_to_oid()</literal>
1705      translates the specified symbolic <literal>name</literal>,
1706      interpreted as being of class <literal>oclass</literal>.  (The
1707      class must be specified as many symbolic names exist within
1708      multiple classes - for example, <literal>Zthes</literal> is the
1709      symbolic name of an attribute set, a schema and a tag-set.)  The
1710      sequence of integers representing the OID is written into the
1711      area <literal>oid</literal> provided by the caller; it is the
1712      caller's responsibility to ensure that this area is large enough
1713      to contain the translated OID.  As a convenience, the address of
1714      the buffer (i.e. the value of <literal>oid</literal>) is
1715      returned.
1716    </para>
1717    <para>
1718     <literal>oid_to_dotstring()</literal>
1719     Translates the int-array <literal>oid</literal> into a dotted
1720     string which is written into the area <literal>oidbuf</literal>
1721     supplied by the caller; it is the caller's responsibility to
1722     ensure that this area is large enough.  The address of the buffer
1723     is returned.
1724    </para>
1725    <para>
1726     <literal>oid_name_to_dotstring()</literal>
1727     combines the previous two functions to derive a dotted string
1728     representing the OID specified by <literal>oclass</literal> and
1729     <literal>name</literal>, writing it into the buffer passed as
1730     <literal>oidbuf</literal> and returning its address.
1731    </para>
1732
1733    <para>
1734     Finally, the module provides the following utility functions, whose
1735     meaning should be obvious:
1736    </para>
1737
1738    <screen>
1739     void oid_oidcpy(int *t, int *s);
1740     void oid_oidcat(int *t, int *s);
1741     int oid_oidcmp(int *o1, int *o2);
1742     int oid_oidlen(int *o);
1743    </screen>
1744
1745    <note>
1746     <para>
1747      The OID module has been criticized - and perhaps rightly so
1748      - for needlessly abstracting the
1749      representation of OIDs. Other toolkits use a simple
1750      string-representation of OIDs with good results. In practice, we have
1751      found the interface comfortable and quick to work with, and it is a
1752      simple matter (for what it's worth) to create applications compatible
1753      with both ISO SR and Z39.50. Finally, the use of the
1754      <literal>/oident</literal> database is by no means mandatory.
1755      You can easily create your own system for representing OIDs, as long
1756      as it is compatible with the low-level integer-array representation
1757      of the ODR module.
1758     </para>
1759    </note>
1760
1761   </sect1>
1762
1763   <sect1 id="tools.nmem"><title>Nibble Memory</title>
1764
1765    <para>
1766     Sometimes when you need to allocate and construct a large,
1767     interconnected complex of structures, it can be a bit of a pain to
1768     release the associated memory again. For the structures describing the
1769     Z39.50 PDUs and related structures, it is convenient to use the
1770     memory-management system of the &odr; subsystem (see
1771     <xref linkend="odr.use"/>). However, in some circumstances
1772     where you might otherwise benefit from using a simple nibble memory
1773     management system, it may be impractical to use
1774     <function>odr_malloc()</function> and <function>odr_reset()</function>.
1775     For this purpose, the memory manager which also supports the &odr;
1776     streams is made available in the NMEM module. The external interface
1777     to this module is given in the <filename>nmem.h</filename> file.
1778    </para>
1779
1780    <para>
1781     The following prototypes are given:
1782    </para>
1783
1784    <screen>
1785     NMEM nmem_create(void);
1786     void nmem_destroy(NMEM n);
1787     void *nmem_malloc(NMEM n, int size);
1788     void nmem_reset(NMEM n);
1789     int nmem_total(NMEM n);
1790     void nmem_init(void);
1791     void nmem_exit(void);
1792    </screen>
1793
1794    <para>
1795     The <function>nmem_create()</function> function returns a pointer to a
1796     memory control handle, which can be released again by
1797     <function>nmem_destroy()</function> when no longer needed.
1798     The function <function>nmem_malloc()</function> allocates a block of
1799     memory of the requested size. A call to <function>nmem_reset()</function>
1800     or <function>nmem_destroy()</function> will release all memory allocated
1801     on the handle since it was created (or since the last call to
1802     <function>nmem_reset()</function>. The function
1803     <function>nmem_total()</function> returns the number of bytes currently
1804     allocated on the handle.
1805    </para>
1806
1807    <para>
1808     The nibble memory pool is shared amongst threads. POSIX
1809     mutex'es and WIN32 Critical sections are introduced to keep the
1810     module thread safe. Function <function>nmem_init()</function>
1811     initializes the nibble memory library and it is called automatically
1812     the first time the <literal>YAZ.DLL</literal> is loaded. &yaz; uses
1813     function <function>DllMain</function> to achieve this. You should
1814     <emphasis>not</emphasis> call <function>nmem_init</function> or
1815     <function>nmem_exit</function> unless you're absolute sure what
1816     you're doing. Note that in previous &yaz; versions you'd have to call
1817     <function>nmem_init</function> yourself. 
1818    </para>
1819
1820   </sect1>
1821  </chapter>
1822  
1823  <!-- Keep this comment at the end of the file
1824  Local variables:
1825  mode: sgml
1826  sgml-omittag:t
1827  sgml-shorttag:t
1828  sgml-minimize-attributes:nil
1829  sgml-always-quote-attributes:t
1830  sgml-indent-step:1
1831  sgml-indent-data:t
1832  sgml-parent-document: "yaz.xml"
1833  sgml-local-catalogs: nil
1834  sgml-namecase-general:t
1835  End:
1836  -->