1 <!-- $Id: tools.xml,v 1.37 2004-10-01 19:34:09 adam Exp $ -->
2 <chapter id="tools"><title>Supporting Tools</title>
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.
10 <sect1 id="tools.query"><title>Query Syntax Parsers</title>
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.
23 <sect2 id="PQF"><title>Prefix Query Format</title>
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.
38 The PQF have been adopted by other parties developing Z39.50
39 software. It is often referred to as Prefix Query Notation
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.
51 First set of functions all operate on a PQF parser handle:
54 #include <yaz/pquery.h>
56 YAZ_PQF_Parser yaz_pqf_create (void);
58 void yaz_pqf_destroy (YAZ_PQF_Parser p);
60 Z_RPNQuery *yaz_pqf_parse (YAZ_PQF_Parser p, ODR o, const char *qbuf);
62 Z_AttributesPlusTerm *yaz_pqf_scan (YAZ_PQF_Parser p, ODR o,
63 Odr_oid **attributeSetId, const char *qbuf);
66 int yaz_pqf_error (YAZ_PQF_Parser p, const char **msg, size_t *off);
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
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.
90 The second set of functions are declared as follows:
93 #include <yaz/pquery.h>
95 Z_RPNQuery *p_query_rpn (ODR o, oid_proto proto, const char *qbuf);
97 Z_AttributesPlusTerm *p_query_scan (ODR o, oid_proto proto,
98 Odr_oid **attributeSetP, const char *qbuf);
100 int p_query_attset (const char *arg);
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.
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.
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.
126 The grammar of the PQF is as follows:
130 query ::= top-set query-struct.
132 top-set ::= [ '@attrset' string ]
134 query-struct ::= attr-spec | simple | complex | '@term' term-type query
136 attr-spec ::= '@attr' [ string ] string query-struct
138 complex ::= operator query-struct query-struct.
140 operator ::= '@and' | '@or' | '@not' | '@prox' proximity.
142 simple ::= result-set | term.
144 result-set ::= '@set' string.
148 proximity ::= exclusion distance ordered relation which-code unit-code.
150 exclusion ::= '1' | '0' | 'void'.
152 distance ::= integer.
154 ordered ::= '1' | '0'.
156 relation ::= integer.
158 which-code ::= 'known' | 'private' | integer.
160 unit-code ::= integer.
162 term-type ::= 'general' | 'numeric' | 'string' | 'oid' | 'datetime' | 'null'.
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.
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.
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.
199 <sect3 id="PQF-prox">
200 <title>Using Proximity Operators with PQF</title>
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>.
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.
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"/>
231 In PQF, the proximity operation is represented by a sequence
234 @prox <replaceable>exclusion</replaceable> <replaceable>distance</replaceable> <replaceable>ordered</replaceable> <replaceable>relation</replaceable> <replaceable>which-code</replaceable> <replaceable>unit-code</replaceable>
236 in which the meanings of the parameters are as described in in
237 the standard, and they can take the following values:
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
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
261 4 (greaterThanOrEqual),
264 </para></formalpara></listitem>
265 <listitem><formalpara><title>which-code</title><para>
266 <literal>known</literal>
269 (the unit-code parameter is taken from the well-known list
270 of alternatives described in below) or
271 <literal>private</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
291 If which-code is <literal>private</literal> then the
292 acceptable values are determined by the profile.
293 </para></formalpara></listitem>
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.)
302 <sect3 id="pqf-examples"><title>PQF queries</title>
304 <example><title>PQF queries using simple terms</title>
312 <example><title>PQF boolean operators</title>
315 @or "dylan" "zimmerman"
316 @and @or dylan zimmerman when
317 @and when @or dylan zimmerman
321 <example><title>PQF references to result sets</title>
329 <example><title>Attributes for terms</title>
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
340 <example><title>PQF Proximity queries</title>
343 @prox 0 3 1 2 k 2 dylan zimmerman
346 Here the parameters 0, 3, 1, 2, k and 2 represent exclusion,
347 distance, ordered, relation, which-code and unit-code, in that
351 exclusion = 0: the proximity condition must hold
354 distance = 3: the terms must be three units apart
357 ordered = 1: they must occur in the order they are specified
360 relation = 2: lessThanOrEqual (to the distance of 3 units)
363 which-code is ``known'', so the standard unit-codes are used
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.
379 <example><title>PQF specification of search term</title>
382 @term string "a UTF-8 string, maybe?"
386 <example><title>PQF mixed queries</title>
389 @or @and bob dylan @set Result-1
391 @attr 4=1 @and @attr 1=1 "bob dylan" @attr 1=4 "slow train coming"
393 @and @attr 2=4 @attr gils 1=2038 -114 @attr 2=2 @attr gils 1=2039 -109
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>,
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.
411 <sect2 id="CCL"><title>CCL</title>
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.
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;.
434 <sect3><title>CCL Syntax</title>
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>‐‐</literal>.
443 CCL-Find ::= CCL-Find Op Elements
446 Op ::= "and" | "or" | "not"
447 -- The above means that Elements are separated by boolean operators.
449 Elements ::= '(' CCL-Find ')'
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).
459 Set ::= 'set' = string
460 -- Reference to a result set
462 Terms ::= Terms Prox Term
464 -- Proximity of terms.
468 -- This basically means that a term may include a blank
470 Qualifiers ::= Qualifiers ',' string
472 -- Qualifiers is a list of strings separated by comma
474 Relation ::= '=' | '>=' | '<=' | '<>' | '>' | '<'
475 -- Relational operators. This really doesn't follow the ISO8777
479 -- Proximity operator
483 <example><title>CCL queries</title>
485 The following queries are all valid:
497 (dylan and bob) or set=1
501 Assuming that the qualifiers <literal>ti</literal>,
502 <literal>au</literal>
503 and <literal>date</literal> are defined we may use:
509 au=(bob dylan and slow train coming)
511 date>1980 and (ti=((self portrait)))
517 <sect3><title>CCL Qualifiers</title>
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
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.
539 <sect4><title id="qualifier-specification">Qualifier specification</title>
541 A qualifier specification is of the form:
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> ...
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>
566 <colspec colwidth="2*" colname="type"></colspec>
567 <colspec colwidth="9*" colname="description"></colspec>
571 <entry>Description</entry>
576 <entry><literal>u=</literal><replaceable>value</replaceable></entry>
578 Use attribute (1). 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
586 <entry><literal>r=</literal><replaceable>value</replaceable></entry>
588 Relation attribute (2). Common values are
589 1 <, 2 <=, 3 =, 4 >=, 5 >, 6 <>,
590 100 phonetic, 101 stem, 102 relevance, 103 always matches.
595 <entry><literal>p=</literal><replaceable>value</replaceable></entry>
597 Position attribute (3). Values: 1 first in field, 2
598 first in any subfield, 3 any position in field.
603 <entry><literal>s=</literal><replaceable>value</replaceable></entry>
605 Structure attribute (4). 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.
614 <entry><literal>t=</literal><replaceable>value</replaceable></entry>
616 Truncation attribute (5). Values: 1 right, 2 left,
617 3 left& right, 100 none, 101 process #, 102 regular-1,
618 103 regular-2, 104 CCL.
623 <entry><literal>c=</literal><replaceable>value</replaceable></entry>
625 Completeness attribute (6). Values: 1 incomplete subfield,
626 2 complete subfield, 3 complete field.
635 The complete list of Bib-1 attributes can be found
636 <ulink url="http://lcweb.loc.gov/z3950/agency/defns/bib1.html">
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:
645 <table><title>Special attribute combos</title>
647 <colspec colwidth="2*" colname="name"></colspec>
648 <colspec colwidth="9*" colname="description"></colspec>
652 <entry>Description</entry>
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).
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.
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.
675 <row><entry><literal>r=o</literal></entry><entry>
676 Allows ranges and the operators greather-than, less-than, ...
678 This sets Bib-1 relation attribute accordingly (relation
679 ordered). A query construct is only treated as a range if
680 dash is used and that is surrounded by white-space. So
681 <literal>-1980</literal> is treated as term
682 <literal>"-1980"</literal> not <literal><= 1980</literal>.
683 If <literal>- 1980</literal> is used, however, that is
688 <row><entry><literal>r=r</literal></entry><entry>
689 Similar to <literal>r=o</literal> but assumes that terms
690 are non-negative (not prefixed with <literal>-</literal>).
691 Thus, a dash will always be treated as a range.
692 The construct <literal>1980-1990</literal> is
693 treated as a range with <literal>r=r</literal> but as a
694 single term <literal>"1980-1990"</literal> with
695 <literal>r=o</literal>. The special attribute
696 <literal>r=r</literal> is available in YAZ 2.0.24 or later.
700 <row><entry><literal>t=l</literal></entry><entry>
701 Allows term to be left-truncated.
702 If term is of the form <literal>?x</literal>, the resulting
703 Type-1 term is <literal>x</literal> and truncation is left.
707 <row><entry><literal>t=r</literal></entry><entry>
708 Allows term to be right-truncated.
709 If term is of the form <literal>x?</literal>, the resulting
710 Type-1 term is <literal>x</literal> and truncation is right.
714 <row><entry><literal>t=n</literal></entry><entry>
715 If term is does not include <literal>?</literal>, the
716 truncation attribute is set to none (100).
720 <row><entry><literal>t=b</literal></entry><entry>
721 Allows term to be both left&right truncated.
722 If term is of the form <literal>?x?</literal>, the
723 resulting term is <literal>x</literal> and trunctation is
724 set to both left&right.
731 <example><title>CCL profile</title>
733 Consider the following definition:
744 <literal>ti</literal> and <literal>au</literal> both set
745 structure attribute to phrase (s=1).
746 <literal>ti</literal>
747 sets the use-attribute to 4. <literal>au</literal> sets the
749 When no qualifiers are used in the query the structure-attribute is
750 set to free-form-text (105) (rule for <literal>term</literal>).
751 The <literal>date</literal> sets the relation attribute to
752 the relation used in the CCL query and sets the use attribute
756 You can combine attributes. To Search for "ranked title" you
759 ti,ranked=knuth computer
761 which will set relation=ranked, use=title, structure=phrase.
768 is a valid query. But
776 <sect4><title>Qualifier alias</title>
778 A qualifier alias is of the form:
781 <replaceable>q</replaceable>
782 <replaceable>q1</replaceable> <replaceable>q2</replaceable> ..
785 which declares <replaceable>q</replaceable> to
786 be an alias for <replaceable>q1</replaceable>,
787 <replaceable>q2</replaceable>... such that the CCL
788 query <replaceable>q=x</replaceable> is equivalent to
789 <replaceable>q1=x or q2=x or ...</replaceable>.
793 <sect4><title>Comments</title>
795 Lines with white space or lines that begin with
796 character <literal>#</literal> are treated as comments.
800 <sect4><title>Directives</title>
802 Directive specifications takes the form
804 <para><literal>@</literal><replaceable>directive</replaceable> <replaceable>value</replaceable>
806 <table><title>CCL directives</title>
808 <colspec colwidth="2*" colname="name"></colspec>
809 <colspec colwidth="8*" colname="description"></colspec>
810 <colspec colwidth="1*" colname="default"></colspec>
814 <entry>Description</entry>
815 <entry>Default</entry>
820 <entry>truncation</entry>
821 <entry>Truncation character</entry>
822 <entry><literal>?</literal></entry>
826 <entry>Specifies how multiple fields are to be
827 combined. There are two modes: <literal>or</literal>:
828 multiple qualifier fields are ORed,
829 <literal>merge</literal>: attributes for the qualifier
830 fields are merged and assigned to one term.
832 <entry><literal>merge</literal></entry>
836 <entry>Specificies if CCL operatores and qualifiers should be
837 compared with case sensitivity or not. Specify 0 for
838 case sensitive; 1 for case insensitive.</entry>
839 <entry><literal>0</literal></entry>
844 <entry>Specifies token for CCL operator AND.</entry>
845 <entry><literal>and</literal></entry>
850 <entry>Specifies token for CCL operator OR.</entry>
851 <entry><literal>or</literal></entry>
856 <entry>Specifies token for CCL operator NOT.</entry>
857 <entry><literal>not</literal></entry>
862 <entry>Specifies token for CCL operator SET.</entry>
863 <entry><literal>set</literal></entry>
870 <sect3><title>CCL API</title>
872 All public definitions can be found in the header file
873 <filename>ccl.h</filename>. A profile identifier is of type
874 <literal>CCL_bibset</literal>. A profile must be created with the call
875 to the function <function>ccl_qual_mk</function> which returns a profile
876 handle of type <literal>CCL_bibset</literal>.
880 To read a file containing qualifier definitions the function
881 <function>ccl_qual_file</function> may be convenient. This function
882 takes an already opened <literal>FILE</literal> handle pointer as
883 argument along with a <literal>CCL_bibset</literal> handle.
887 To parse a simple string with a FIND query use the function
890 struct ccl_rpn_node *ccl_find_str (CCL_bibset bibset, const char *str,
891 int *error, int *pos);
894 which takes the CCL profile (<literal>bibset</literal>) and query
895 (<literal>str</literal>) as input. Upon successful completion the RPN
896 tree is returned. If an error occur, such as a syntax error, the integer
897 pointed to by <literal>error</literal> holds the error code and
898 <literal>pos</literal> holds the offset inside query string in which
903 An English representation of the error may be obtained by calling
904 the <literal>ccl_err_msg</literal> function. The error codes are
905 listed in <filename>ccl.h</filename>.
909 To convert the CCL RPN tree (type
910 <literal>struct ccl_rpn_node *</literal>)
911 to the Z_RPNQuery of YAZ the function <function>ccl_rpn_query</function>
912 must be used. This function which is part of YAZ is implemented in
913 <filename>yaz-ccl.c</filename>.
914 After calling this function the CCL RPN tree is probably no longer
915 needed. The <literal>ccl_rpn_delete</literal> destroys the CCL RPN tree.
919 A CCL profile may be destroyed by calling the
920 <function>ccl_qual_rm</function> function.
924 The token names for the CCL operators may be changed by setting the
925 globals (all type <literal>char *</literal>)
926 <literal>ccl_token_and</literal>, <literal>ccl_token_or</literal>,
927 <literal>ccl_token_not</literal> and <literal>ccl_token_set</literal>.
928 An operator may have aliases, i.e. there may be more than one name for
929 the operator. To do this, separate each alias with a space character.
933 <sect2 id="tools.cql"><title>CQL</title>
935 <ulink url="http://www.loc.gov/z3950/agency/zing/cql/">CQL</ulink>
936 - Common Query Language - was defined for the
937 <ulink url="http://www.loc.gov/z3950/agency/zing/srw/">SRW</ulink>
939 In many ways CQL has a similar syntax to CCL.
940 The objective of CQL is different. Where CCL aims to be
941 an end-user language, CQL is <emphasis>the</emphasis> protocol
942 query language for SRW.
946 If you are new to CQL, read the
947 <ulink url="http://zing.z3950.org/cql/intro.html">Gentle
948 Introduction</ulink>.
952 The CQL parser in &yaz; provides the following:
956 It parses and validates a CQL query.
961 It generates a C structure that allows you to convert
962 a CQL query to some other query language, such as SQL.
967 The parser converts a valid CQL query to PQF, thus providing a
968 way to use CQL for both SRW/SRU servers and Z39.50 targets at the
974 The parser converts CQL to
975 <ulink url="http://www.loc.gov/z3950/agency/zing/cql/xcql.html">
977 XCQL is an XML representation of CQL.
978 XCQL is part of the SRW specification. However, since SRU
979 supports CQL only, we don't expect XCQL to be widely used.
980 Furthermore, CQL has the advantage over XCQL that it is
986 <sect3 id="tools.cql.parsing"><title>CQL parsing</title>
988 A CQL parser is represented by the <literal>CQL_parser</literal>
989 handle. Its contents should be considered &yaz; internal (private).
991 #include <yaz/cql.h>
993 typedef struct cql_parser *CQL_parser;
995 CQL_parser cql_parser_create(void);
996 void cql_parser_destroy(CQL_parser cp);
998 A parser is created by <function>cql_parser_create</function> and
999 is destroyed by <function>cql_parser_destroy</function>.
1002 To parse a CQL query string, the following function
1005 int cql_parser_string(CQL_parser cp, const char *str);
1007 A CQL query is parsed by the <function>cql_parser_string</function>
1008 which takes a query <parameter>str</parameter>.
1009 If the query was valid (no syntax errors), then zero is returned;
1010 otherwise -1 is returned to indicate a syntax error.
1014 int cql_parser_stream(CQL_parser cp,
1015 int (*getbyte)(void *client_data),
1016 void (*ungetbyte)(int b, void *client_data),
1019 int cql_parser_stdio(CQL_parser cp, FILE *f);
1021 The functions <function>cql_parser_stream</function> and
1022 <function>cql_parser_stdio</function> parses a CQL query
1023 - just like <function>cql_parser_string</function>.
1024 The only difference is that the CQL query can be
1025 fed to the parser in different ways.
1026 The <function>cql_parser_stream</function> uses a generic
1027 byte stream as input. The <function>cql_parser_stdio</function>
1028 uses a <literal>FILE</literal> handle which is opened for reading.
1032 <sect3 id="tools.cql.tree"><title>CQL tree</title>
1034 The the query string is valid, the CQL parser
1035 generates a tree representing the structure of the
1040 struct cql_node *cql_parser_result(CQL_parser cp);
1042 <function>cql_parser_result</function> returns the
1043 a pointer to the root node of the resulting tree.
1046 Each node in a CQL tree is represented by a
1047 <literal>struct cql_node</literal>.
1048 It is defined as follows:
1050 #define CQL_NODE_ST 1
1051 #define CQL_NODE_BOOL 2
1052 #define CQL_NODE_MOD 3
1060 struct cql_node *modifiers;
1061 struct cql_node *prefixes;
1065 struct cql_node *left;
1066 struct cql_node *right;
1067 struct cql_node *modifiers;
1068 struct cql_node *prefixes;
1073 struct cql_node *next;
1078 There are three kinds of nodes, search term (ST), boolean (BOOL),
1082 The search term node has five members:
1086 <literal>index</literal>: index for search term.
1087 If an index is unspecified for a search term,
1088 <literal>index</literal> will be NULL.
1093 <literal>term</literal>: the search term itself.
1098 <literal>relation</literal>: relation for search term.
1103 <literal>modifiers</literal>: relation modifiers for search
1104 term. The <literal>modifiers</literal> is a simple linked
1105 list (NULL for last entry). Each relation modifier node
1106 is of type <literal>MOD</literal>.
1111 <literal>prefixes</literal>: index prefixes for search
1112 term. The <literal>prefixes</literal> is a simple linked
1113 list (NULL for last entry). Each prefix node
1114 is of type <literal>MOD</literal>.
1121 The boolean node represents both <literal>and</literal>,
1122 <literal>or</literal>, not as well as
1127 <literal>left</literal> and <literal>right</literal>: left
1128 - and right operand respectively.
1133 <literal>modifiers</literal>: proximity arguments.
1138 <literal>prefixes</literal>: index prefixes.
1139 The <literal>prefixes</literal> is a simple linked
1140 list (NULL for last entry). Each prefix node
1141 is of type <literal>MOD</literal>.
1148 The modifier node is a "utility" node used for name-value pairs,
1149 such as prefixes, proximity arguements, etc.
1153 <literal>name</literal> name of mod node.
1158 <literal>value</literal> value of mod node.
1163 <literal>next</literal>: pointer to next node which is
1164 always a mod node (NULL for last entry).
1171 <sect3 id="tools.cql.pqf"><title>CQL to PQF conversion</title>
1173 Conversion to PQF (and Z39.50 RPN) is tricky by the fact
1174 that the resulting RPN depends on the Z39.50 target
1175 capabilities (combinations of supported attributes).
1176 In addition, the CQL and SRW operates on index prefixes
1177 (URI or strings), whereas the RPN uses Object Identifiers
1181 The CQL library of &yaz; defines a <literal>cql_transform_t</literal>
1182 type. It represents a particular mapping between CQL and RPN.
1183 This handle is created and destroyed by the functions:
1185 cql_transform_t cql_transform_open_FILE (FILE *f);
1186 cql_transform_t cql_transform_open_fname(const char *fname);
1187 void cql_transform_close(cql_transform_t ct);
1189 The first two functions create a tranformation handle from
1190 either an already open FILE or from a filename respectively.
1193 The handle is destroyed by <function>cql_transform_close</function>
1194 in which case no further reference of the handle is allowed.
1197 When a <literal>cql_transform_t</literal> handle has been created
1198 you can convert to RPN.
1200 int cql_transform_buf(cql_transform_t ct,
1201 struct cql_node *cn, char *out, int max);
1203 This function converts the CQL tree <literal>cn</literal>
1204 using handle <literal>ct</literal>.
1205 For the resulting PQF, you supply a buffer <literal>out</literal>
1206 which must be able to hold at at least <literal>max</literal>
1210 If conversion failed, <function>cql_transform_buf</function>
1211 returns a non-zero SRW error code; otherwise zero is returned
1212 (conversion successful). The meanings of the numeric error
1213 codes are listed in the SRW specifications at
1214 <ulink url="http://www.loc.gov/srw/diagnostic-list.html"/>
1217 If conversion fails, more information can be obtained by calling
1219 int cql_transform_error(cql_transform_t ct, char **addinfop);
1221 This function returns the most recently returned numeric
1222 error-code and sets the string-pointer at
1223 <literal>*addinfop</literal> to point to a string containing
1224 additional information about the error that occurred: for
1225 example, if the error code is 15 (``Illegal or unsupported context
1226 set''), the additional information is the name of the requested
1227 context set that was not recognised.
1230 The SRW error-codes may be translated into brief human-readable
1231 error messages using
1233 const char *cql_strerror(int code);
1237 If you wish to be able to produce a PQF result in a different
1238 way, there are two alternatives.
1240 void cql_transform_pr(cql_transform_t ct,
1241 struct cql_node *cn,
1242 void (*pr)(const char *buf, void *client_data),
1245 int cql_transform_FILE(cql_transform_t ct,
1246 struct cql_node *cn, FILE *f);
1248 The former function produces output to a user-defined
1249 output stream. The latter writes the result to an already
1250 open <literal>FILE</literal>.
1253 <sect3 id="tools.cql.map">
1254 <title>Specification of CQL to RPN mapping</title>
1256 The file supplied to functions
1257 <function>cql_transform_open_FILE</function>,
1258 <function>cql_transform_open_fname</function> follows
1259 a structure found in many Unix utilities.
1260 It consists of mapping specifications - one per line.
1261 Lines starting with <literal>#</literal> are ignored (comments).
1264 Each line is of the form
1266 <replaceable>CQL pattern</replaceable><literal> = </literal> <replaceable> RPN equivalent</replaceable>
1270 An RPN pattern is a simple attribute list. Each attribute pair
1273 [<replaceable>set</replaceable>] <replaceable>type</replaceable><literal>=</literal><replaceable>value</replaceable>
1275 The attribute <replaceable>set</replaceable> is optional.
1276 The <replaceable>type</replaceable> is the attribute type,
1277 <replaceable>value</replaceable> the attribute value.
1280 The following CQL patterns are recognized:
1282 <varlistentry><term>
1283 <literal>index.</literal><replaceable>set</replaceable><literal>.</literal><replaceable>name</replaceable>
1287 This pattern is invoked when a CQL index, such as
1288 dc.title is converted. <replaceable>set</replaceable>
1289 and <replaceable>name</replaceable> are the context set and index
1291 Typically, the RPN specifies an equivalent use attribute.
1294 For terms not bound by an index the pattern
1295 <literal>index.cql.serverChoice</literal> is used.
1296 Here, the prefix <literal>cql</literal> is defined as
1297 <literal>http://www.loc.gov/zing/cql/cql-indexes/v1.0/</literal>.
1298 If this pattern is not defined, the mapping will fail.
1302 <varlistentry><term>
1303 <literal>qualifier.</literal><replaceable>set</replaceable><literal>.</literal><replaceable>name</replaceable>
1308 For backwards compatibility, this is recognised as a synonym of
1309 <literal>index.</literal><replaceable>set</replaceable><literal>.</literal><replaceable>name</replaceable>
1313 <varlistentry><term>
1314 <literal>relation.</literal><replaceable>relation</replaceable>
1318 This pattern specifies how a CQL relation is mapped to RPN.
1319 <replaceable>pattern</replaceable> is name of relation
1320 operator. Since <literal>=</literal> is used as
1321 separator between CQL pattern and RPN, CQL relations
1322 including <literal>=</literal> cannot be
1323 used directly. To avoid a conflict, the names
1324 <literal>ge</literal>,
1325 <literal>eq</literal>,
1326 <literal>le</literal>,
1327 must be used for CQL operators, greater-than-or-equal,
1328 equal, less-than-or-equal respectively.
1329 The RPN pattern is supposed to include a relation attribute.
1332 For terms not bound by a relation, the pattern
1333 <literal>relation.scr</literal> is used. If the pattern
1334 is not defined, the mapping will fail.
1337 The special pattern, <literal>relation.*</literal> is used
1338 when no other relation pattern is matched.
1343 <varlistentry><term>
1344 <literal>relationModifier.</literal><replaceable>mod</replaceable>
1348 This pattern specifies how a CQL relation modifier is mapped to RPN.
1349 The RPN pattern is usually a relation attribute.
1354 <varlistentry><term>
1355 <literal>structure.</literal><replaceable>type</replaceable>
1359 This pattern specifies how a CQL structure is mapped to RPN.
1360 Note that this CQL pattern is somewhat to similar to
1361 CQL pattern <literal>relation</literal>.
1362 The <replaceable>type</replaceable> is a CQL relation.
1365 The pattern, <literal>structure.*</literal> is used
1366 when no other structure pattern is matched.
1367 Usually, the RPN equivalent specifies a structure attribute.
1372 <varlistentry><term>
1373 <literal>position.</literal><replaceable>type</replaceable>
1377 This pattern specifies how the anchor (position) of
1378 CQL is mapped to RPN.
1379 The <replaceable>type</replaceable> is one
1380 of <literal>first</literal>, <literal>any</literal>,
1381 <literal>last</literal>, <literal>firstAndLast</literal>.
1384 The pattern, <literal>position.*</literal> is used
1385 when no other position pattern is matched.
1390 <varlistentry><term>
1391 <literal>set.</literal><replaceable>prefix</replaceable>
1395 This specification defines a CQL context set for a given prefix.
1396 The value on the right hand side is the URI for the set -
1397 <emphasis>not</emphasis> RPN. All prefixes used in
1398 index patterns must be defined this way.
1404 <example><title>CQL to RPN mapping file</title>
1406 This simple file defines two context sets, three indexes and three
1407 relations, a position pattern and a default structure.
1409 <programlisting><![CDATA[
1410 set.cql = http://www.loc.gov/zing/cql/context-sets/cql/v1.1/
1411 set.dc = http://www.loc.gov/zing/cql/dc-indexes/v1.0/
1413 index.cql.serverChoice = 1=1016
1414 index.dc.title = 1=4
1415 index.dc.subject = 1=21
1421 position.any = 3=3 6=1
1427 With the mappings above, the CQL query
1431 is converted to the PQF:
1433 @attr 1=1016 @attr 2=3 @attr 4=1 @attr 3=3 @attr 6=1 "computer"
1435 by rules <literal>index.cql.serverChoice</literal>,
1436 <literal>relation.scr</literal>, <literal>structure.*</literal>,
1437 <literal>position.any</literal>.
1444 is rejected, since <literal>position.right</literal> is
1450 >my = "http://www.loc.gov/zing/cql/dc-indexes/v1.0/" my.title = x
1454 @attr 1=4 @attr 2=3 @attr 4=1 @attr 3=3 @attr 6=1 "x"
1459 <sect3 id="tools.cql.xcql"><title>CQL to XCQL conversion</title>
1461 Conversion from CQL to XCQL is trivial and does not
1462 require a mapping to be defined.
1463 There three functions to choose from depending on the
1464 way you wish to store the resulting output (XML buffer
1467 int cql_to_xml_buf(struct cql_node *cn, char *out, int max);
1468 void cql_to_xml(struct cql_node *cn,
1469 void (*pr)(const char *buf, void *client_data),
1471 void cql_to_xml_stdio(struct cql_node *cn, FILE *f);
1473 Function <function>cql_to_xml_buf</function> converts
1474 to XCQL and stores result in a user supplied buffer of a given
1478 <function>cql_to_xml</function> writes the result in
1479 a user defined output stream.
1480 <function>cql_to_xml_stdio</function> writes to a
1486 <sect1 id="tools.oid"><title>Object Identifiers</title>
1489 The basic YAZ representation of an OID is an array of integers,
1490 terminated with the value -1. The &odr; module provides two
1491 utility-functions to create and copy this type of data elements:
1495 Odr_oid *odr_getoidbystr(ODR o, char *str);
1499 Creates an OID based on a string-based representation using dots (.)
1500 to separate elements in the OID.
1504 Odr_oid *odr_oiddup(ODR odr, Odr_oid *o);
1508 Creates a copy of the OID referenced by the <emphasis>o</emphasis>
1510 Both functions take an &odr; stream as parameter. This stream is used to
1511 allocate memory for the data elements, which is released on a
1512 subsequent call to <function>odr_reset()</function> on that stream.
1516 The OID module provides a higher-level representation of the
1517 family of object identifiers which describe the Z39.50 protocol and its
1518 related objects. The definition of the module interface is given in
1519 the <filename>oid.h</filename> file.
1523 The interface is mainly based on the <literal>oident</literal> structure.
1524 The definition of this structure looks like this:
1528 typedef struct oident
1533 int oidsuffix[OID_SIZE];
1539 The proto field takes one of the values
1548 Use <literal>PROTO_Z3950</literal> for Z39.50 Object Identifers,
1549 <literal>PROTO_GENERAL</literal> for other types (such as
1550 those associated with ILL).
1554 The oclass field takes one of the values
1576 corresponding to the OID classes defined by the Z39.50 standard.
1578 Finally, the value field takes one of the values
1636 again, corresponding to the specific OIDs defined by the standard.
1638 <ulink url="http://lcweb.loc.gov/z3950/agency/defns/oids.html">
1639 Registry of Z39.50 Object Identifiers</ulink> for the
1644 The desc field contains a brief, mnemonic name for the OID in question.
1652 struct oident *oid_getentbyoid(int *o);
1656 takes as argument an OID, and returns a pointer to a static area
1657 containing an <literal>oident</literal> structure. You typically use
1658 this function when you receive a PDU containing an OID, and you wish
1659 to branch out depending on the specific OID value.
1667 int *oid_ent_to_oid(struct oident *ent, int *dst);
1671 Takes as argument an <literal>oident</literal> structure - in which
1672 the <literal>proto</literal>, <literal>oclass</literal>/, and
1673 <literal>value</literal> fields are assumed to be set correctly -
1674 and returns a pointer to a the buffer as given by <literal>dst</literal>
1676 representation of the corresponding OID. The function returns
1677 NULL and the array dst is unchanged if a mapping couldn't place.
1678 The array <literal>dst</literal> should be at least of size
1679 <literal>OID_SIZE</literal>.
1683 The <function>oid_ent_to_oid()</function> function can be used whenever
1684 you need to prepare a PDU containing one or more OIDs. The separation of
1685 the <literal>protocol</literal> element from the remainder of the
1686 OID-description makes it simple to write applications that can
1687 communicate with either Z39.50 or OSI SR-based applications.
1695 oid_value oid_getvalbyname(const char *name);
1699 takes as argument a mnemonic OID name, and returns the
1700 <literal>/value</literal> field of the first entry in the database that
1701 contains the given name in its <literal>desc</literal> field.
1705 Three utility functions are provided for translating OIDs'
1706 symbolic names (e.g. <literal>Usmarc</literal> into OID structures
1707 (int arrays) and strings containing the OID in dotted notation
1708 (e.g. <literal>1.2.840.10003.9.5.1</literal>). They are:
1712 int *oid_name_to_oid(oid_class oclass, const char *name, int *oid);
1713 char *oid_to_dotstring(const int *oid, char *oidbuf);
1714 char *oid_name_to_dotstring(oid_class oclass, const char *name, char *oidbuf);
1718 <literal>oid_name_to_oid()</literal>
1719 translates the specified symbolic <literal>name</literal>,
1720 interpreted as being of class <literal>oclass</literal>. (The
1721 class must be specified as many symbolic names exist within
1722 multiple classes - for example, <literal>Zthes</literal> is the
1723 symbolic name of an attribute set, a schema and a tag-set.) The
1724 sequence of integers representing the OID is written into the
1725 area <literal>oid</literal> provided by the caller; it is the
1726 caller's responsibility to ensure that this area is large enough
1727 to contain the translated OID. As a convenience, the address of
1728 the buffer (i.e. the value of <literal>oid</literal>) is
1732 <literal>oid_to_dotstring()</literal>
1733 Translates the int-array <literal>oid</literal> into a dotted
1734 string which is written into the area <literal>oidbuf</literal>
1735 supplied by the caller; it is the caller's responsibility to
1736 ensure that this area is large enough. The address of the buffer
1740 <literal>oid_name_to_dotstring()</literal>
1741 combines the previous two functions to derive a dotted string
1742 representing the OID specified by <literal>oclass</literal> and
1743 <literal>name</literal>, writing it into the buffer passed as
1744 <literal>oidbuf</literal> and returning its address.
1748 Finally, the module provides the following utility functions, whose
1749 meaning should be obvious:
1753 void oid_oidcpy(int *t, int *s);
1754 void oid_oidcat(int *t, int *s);
1755 int oid_oidcmp(int *o1, int *o2);
1756 int oid_oidlen(int *o);
1761 The OID module has been criticized - and perhaps rightly so
1762 - for needlessly abstracting the
1763 representation of OIDs. Other toolkits use a simple
1764 string-representation of OIDs with good results. In practice, we have
1765 found the interface comfortable and quick to work with, and it is a
1766 simple matter (for what it's worth) to create applications compatible
1767 with both ISO SR and Z39.50. Finally, the use of the
1768 <literal>/oident</literal> database is by no means mandatory.
1769 You can easily create your own system for representing OIDs, as long
1770 as it is compatible with the low-level integer-array representation
1777 <sect1 id="tools.nmem"><title>Nibble Memory</title>
1780 Sometimes when you need to allocate and construct a large,
1781 interconnected complex of structures, it can be a bit of a pain to
1782 release the associated memory again. For the structures describing the
1783 Z39.50 PDUs and related structures, it is convenient to use the
1784 memory-management system of the &odr; subsystem (see
1785 <xref linkend="odr.use"/>). However, in some circumstances
1786 where you might otherwise benefit from using a simple nibble memory
1787 management system, it may be impractical to use
1788 <function>odr_malloc()</function> and <function>odr_reset()</function>.
1789 For this purpose, the memory manager which also supports the &odr;
1790 streams is made available in the NMEM module. The external interface
1791 to this module is given in the <filename>nmem.h</filename> file.
1795 The following prototypes are given:
1799 NMEM nmem_create(void);
1800 void nmem_destroy(NMEM n);
1801 void *nmem_malloc(NMEM n, int size);
1802 void nmem_reset(NMEM n);
1803 int nmem_total(NMEM n);
1804 void nmem_init(void);
1805 void nmem_exit(void);
1809 The <function>nmem_create()</function> function returns a pointer to a
1810 memory control handle, which can be released again by
1811 <function>nmem_destroy()</function> when no longer needed.
1812 The function <function>nmem_malloc()</function> allocates a block of
1813 memory of the requested size. A call to <function>nmem_reset()</function>
1814 or <function>nmem_destroy()</function> will release all memory allocated
1815 on the handle since it was created (or since the last call to
1816 <function>nmem_reset()</function>. The function
1817 <function>nmem_total()</function> returns the number of bytes currently
1818 allocated on the handle.
1822 The nibble memory pool is shared amongst threads. POSIX
1823 mutex'es and WIN32 Critical sections are introduced to keep the
1824 module thread safe. Function <function>nmem_init()</function>
1825 initializes the nibble memory library and it is called automatically
1826 the first time the <literal>YAZ.DLL</literal> is loaded. &yaz; uses
1827 function <function>DllMain</function> to achieve this. You should
1828 <emphasis>not</emphasis> call <function>nmem_init</function> or
1829 <function>nmem_exit</function> unless you're absolute sure what
1830 you're doing. Note that in previous &yaz; versions you'd have to call
1831 <function>nmem_init</function> yourself.
1836 <sect1 id="tools.marc"><title>MARC</title>
1839 YAZ provides a fast utility that decodes MARC records and
1840 encodes to a varity of output formats. The MARC records must
1841 be encoded in ISO2709.
1844 #include <yaz/marcdisp.h>
1846 /* create handler */
1847 yaz_marc_t yaz_marc_create(void);
1849 void yaz_marc_destroy(yaz_marc_t mt);
1851 /* set XML mode YAZ_MARC_LINE, YAZ_MARC_SIMPLEXML, ... */
1852 void yaz_marc_xml(yaz_marc_t mt, int xmlmode);
1853 #define YAZ_MARC_LINE 0
1854 #define YAZ_MARC_SIMPLEXML 1
1855 #define YAZ_MARC_OAIMARC 2
1856 #define YAZ_MARC_MARCXML 3
1857 #define YAZ_MARC_ISO2709 4
1859 /* supply iconv handle for character set conversion .. */
1860 void yaz_marc_iconv(yaz_marc_t mt, yaz_iconv_t cd);
1862 /* set debug level, 0=none, 1=more, 2=even more, .. */
1863 void yaz_marc_debug(yaz_marc_t mt, int level);
1865 /* decode MARC in buf of size bsize. Returns >0 on success; <=0 on failure.
1866 On success, result in *result with size *rsize. */
1867 int yaz_marc_decode_buf (yaz_marc_t mt, const char *buf, int bsize,
1868 char **result, int *rsize);
1870 /* decode MARC in buf of size bsize. Returns >0 on success; <=0 on failure.
1871 On success, result in WRBUF */
1872 int yaz_marc_decode_wrbuf (yaz_marc_t mt, const char *buf,
1873 int bsize, WRBUF wrbuf);
1877 A MARC conversion handle must be created by using
1878 <function>yaz_marc_create</function> and destroyed
1879 by calling <function>yaz_marc_destroy</function>.
1882 All other function operate on a <literal>yaz_marc_t</literal> handle.
1883 The output is specified by a call to <function>yaz_marc_xml</function>.
1884 The <literal>xmlmode</literal> must be one of
1887 <term>YAZ_MARC_LINE</term>
1890 A simple line-by-line format suitable for display but not
1891 recommend for further (machine) processing.
1897 <term>YAZ_MARC_MARXML</term>
1900 The resulting record is converted to MARCXML.
1906 <term>YAZ_MARC_ISO2709</term>
1909 The resulting record is converted to ISO2709 (MARC).
1916 The actual conversion functions are
1917 <function>yaz_marc_decode_buf</function> and
1918 <function>yaz_marc_decode_wrbuf</function> which decodes and encodes
1919 a MARC record. The former function operates on simple buffers, the
1920 stores the resulting record in a WRBUF handle (WRBUF is a simple string
1924 <title>Display of MARC record</title>
1926 The followint program snippet illustrates how the MARC API may
1927 be used to convert a MARC record to the line-by-line format:
1928 <programlisting><![CDATA[
1929 void print_marc(const char *marc_buf, int marc_buf_size)
1931 char *result; /* for result buf */
1932 int result_len; /* for size of result */
1933 yaz_marc_t mt = yaz_marc_create();
1934 yaz_marc_xml(mt, YAZ_MARC_LINE);
1935 yaz_marc_decode_buf(mt, marc_buf, marc_buf_size,
1936 &result, &result_len);
1937 fwrite(result, result_len, 1, stdout);
1938 yaz_marc_destroy(mt); /* note that result is now freed... */
1948 <!-- Keep this comment at the end of the file
1953 sgml-minimize-attributes:nil
1954 sgml-always-quote-attributes:t
1957 sgml-parent-document: "yaz.xml"
1958 sgml-local-catalogs: nil
1959 sgml-namecase-general:t