client-side, into RPN which may be passed to the server.
This is useful for servers that don't themselves
support CQL, for which <function>ZOOM_query_cql</function> is useless.
- `conn' is used only as a place to stash diagnostics if compilation
+ 'conn' is used only as a place to stash diagnostics if compilation
fails; if this information is not needed, a null pointer may be used.
The CQL conversion is driven by option <literal>cqlfile</literal> from
connection conn. This specifies a conversion file (e.g. pqf.properties)
</para>
<para>
The &asn; module is located in sub directory <filename>z39.50</filename>.
- There you'll find C files that implements encoders and decoders for the
+ There you'll find C files that implement encoders and decoders for the
Z39.50 types. You'll also find the protocol definitions:
<filename>z3950v3.asn</filename>, <filename>esupdate.asn</filename>,
and others.
<xref linkend="odr.use"/> for details). When you use
<function>odr_malloc()</function>, you can release all of the
allocated data in a single operation, independent of any pointers and
- relations between the data. <function>odr_malloc()</function> is based on a
- "nibble-memory"
+ relations between the data. The <function>odr_malloc()</function> function
+ is based on a "nibble-memory"
scheme, in which large portions of memory are allocated, and then
gradually handed out with each call to <function>odr_malloc()</function>.
The next time you call <function>odr_reset()</function>, all of the
Z_<type> *zget_<type>(ODR o);
</synopsis>
<para>
- eg.:
+ e.g.:
</para>
<synopsis>
Z_InitRequest *zget_InitRequest(ODR o);
<literal>octet_aligned</literal> arm of the union.
</para>
<para>
- Some servers return ASN.1 structured data values (eg. database
+ Some servers return ASN.1 structured data values (e.g. database
records) as BER-encoded records placed in the
<literal>octet-aligned</literal> branch of the EXTERNAL CHOICE.
The ASN-module will <emphasis>not</emphasis> automatically decode
Z_ext_typeent *z_ext_gettypebyref(const oid *oid);
</screen>
<para>
- Can be used to retrieve information about the known, external data
- types. The function return a pointer to a static area, or NULL, if no
+ can be used to retrieve information about the known, external data
+ types. The function returns a pointer to a static area, or NULL, if no
match for the given direct reference is found. The
<literal>Z_ext_typeent</literal>
is defined as:
</para>
<para>
If you want to <emphasis>send</emphasis> EXTERNALs containing
- ASN.1-structured values in the occtet-aligned branch of the CHOICE, this
+ ASN.1-structured values in the octet-aligned branch of the CHOICE, this
is possible too. However, on the encoding phase, it requires a somewhat
involved juggling around of the various buffers involved.
</para>
<title>Introduction</title>
<para>
&yaz; uses a very simple implementation of
- <ulink url="&url.soap;">SOAP</ulink> that only,
- currenly, supports what is sufficient to offer SRU SOAP functionality.
+ <ulink url="&url.soap;">SOAP</ulink> that only
+ (currently) supports what is sufficient to offer SRU SOAP functionality.
The implementation uses the
<ulink url="&url.libxml2.api.tree;">tree API</ulink> of
libxml2 to encode and decode SOAP packages.
</para>
<para>
The <literal>fault</literal> and <literal>soap_error</literal>
- arms represent both a SOAP fault - struct
+ arms both represent a SOAP fault - struct
<literal>Z_SOAP_Fault</literal>. Any other generic
(valid) package is represented by <literal>Z_SOAP_Generic</literal>.
</para>
When decoding, the <function>z_soap_codec</function>
inspects the XML content
and tries to match one of the services namespaces of the
- supplied handlers. If there is a match a handler function
+ supplied handlers. If there is a match. a handler function
is invoked which decodes that particular SOAP package.
If successful, the returned <literal>Z_SOAP</literal> package will be
of type <literal>Z_SOAP_Generic</literal>.
Member <literal>no</literal> is
- set the offset of handler that matched; <literal>ns</literal>
- is set to namespace of matching handler; the void pointer
+ set the offset of the handler that matched; <literal>ns</literal>
+ is set to namespace of the matching handler; the void pointer
<literal>p</literal> is set to the C data structure assocatiated
with the handler.
</para>
<para>
- When a NULL namespace is met (member <literal>ns</literal> bwlow),
+ When a NULL namespace is met (member <literal>ns</literal> below),
that specifies end-of-list.
</para>
<para>
Z_SOAP_fun f;
} Z_SOAP_Handler;
</synopsis>
- The <literal>ns</literal> is namespace of service associated with
- handler <literal>f</literal>. <literal>client_data</literal>
- is user-defined data which is passed to handler.
+ The <literal>ns</literal> is the namespace of the service associated with
+ handler <literal>f</literal>. The <literal>client_data</literal>
+ is user-defined data which is passed to the handler.
</para>
<para>
The prototype for a SOAP service handler is:
is a libxml2 tree node pointer (<literal>xmlNodePtr</literal>)
and is a pointer to the <literal>Body</literal> element
of the SOAP package. The <parameter>handler_data</parameter>
- is an opaque pointer to a C definitions associated with the
- SOAP service. <parameter>client_data</parameter> is the pointer
+ is an opaque pointer to C definitions associated with the
+ SOAP service. The <parameter>client_data</parameter> is the pointer
which was set as part of the <literal>Z_SOAP_handler</literal>.
- Finally, <parameter>ns</parameter> the service namespace.
+ Finally, <parameter>ns</parameter> is the service namespace.
</para>
</sect1>
<sect1 id="soap.srw">
Please observe that data of type xsd:string is represented
as a char pointer (<literal>char *</literal>). A null pointer
means that the element is absent.
- Data of type xsd:integer is representd as a pointer to
+ Data of type xsd:integer is represented as a pointer to
an int (<literal>int *</literal>). Again, a null pointer
- us used for absent elements.
+ is used for absent elements.
</para>
<para>
The SearchRetrieveResponse has the following definition.
} Z_SRW_searchRetrieveResponse;
</synopsis>
The <literal>num_records</literal> and <literal>num_diagnostics</literal>
- is number of returned records and diagnostics respectively and also
+ is number of returned records and diagnostics respectively, and also
correspond to the "size of" arrays <literal>records</literal>
and <literal>diagnostics</literal>.
</para>
<title>Supporting Tools</title>
<para>
In support of the service API - primarily the ASN module, which
- provides the pro-grammatic interface to the Z39.50 APDUs, &yaz; contains
+ provides the programmatic interface to the Z39.50 APDUs, &yaz; contains
a collection of tools that support the development of applications.
</para>
<sect1 id="tools.query">
</para>
<note>
<para>
- The PQF have been adopted by other parties developing Z39.50
+ The PQF has been adopted by other parties developing Z39.50
software. It is often referred to as Prefix Query Notation
- PQN.
</para>
</note>
<para>
The PQF is defined by the pquery module in the YAZ library.
- There are two sets of function that have similar behavior. First
+ There are two sets of functions that have similar behavior. First
set operates on a PQF parser handle, second set doesn't. First set
- set of functions are more flexible than the second set. Second set
+ of functions are more flexible than the second set. Second set
is obsolete and is only provided to ensure backwards compatibility.
</para>
<para>
A PQF parser is created and destructed by functions
<function>yaz_pqf_create</function> and
<function>yaz_pqf_destroy</function> respectively.
- Function <function>yaz_pqf_parse</function> parses query given
+ Function <function>yaz_pqf_parse</function> parses the query given
by string <literal>qbuf</literal>. If parsing was successful,
a Z39.50 RPN Query is returned which is created using ODR stream
<literal>o</literal>. If parsing failed, a NULL pointer is
Error information for bad queries can be obtained by a call to
<function>yaz_pqf_error</function> which returns an error code and
modifies <literal>*msg</literal> to point to an error description,
- and modifies <literal>*off</literal> to the offset within last
- query were parsing failed.
+ and modifies <literal>*off</literal> to the offset within the last
+ query where parsing failed.
</para>
<para>
The second set of functions are declared as follows:
a sub-query. The attribute type-value pair is packed in one string:
an attribute type, an equals sign, and an attribute value, like this:
<literal>@attr 1=1003</literal>.
- The type is always an integer but the value may be either an
+ The type is always an integer, but the value may be either an
integer or a string (if it doesn't start with a digit character).
- A string attribute-value is encoded as a Type-1 ``complex''
+ A string attribute-value is encoded as a Type-1 "complex"
attribute with the list of values containing the single string
specified, and including no semantic indicators.
</para>
<screen>
@prox <replaceable>exclusion</replaceable> <replaceable>distance</replaceable> <replaceable>ordered</replaceable> <replaceable>relation</replaceable> <replaceable>which-code</replaceable> <replaceable>unit-code</replaceable>
</screen>
- in which the meanings of the parameters are as described in in
+ in which the meanings of the parameters are as described in
the standard, and they can take the following values:
<itemizedlist>
<listitem>
or
<literal>k</literal>
(the unit-code parameter is taken from the well-known list
- of alternatives described in below) or
+ of alternatives described below) or
<literal>private</literal>
or
<literal>p</literal>
- (the unit-code paramater has semantics specific to an
+ (the unit-code parameter has semantics specific to an
out-of-band agreement such as a profile).
</para>
</formalpara>
</listitem>
<listitem>
<para>
- which-code is ``known'', so the standard unit-codes are used
+ which-code is "known", so the standard unit-codes are used
</para>
</listitem>
<listitem>
<literal>dylan</literal> and <literal>zimmerman</literal> must
both occur in the record, in that order, differing in position
by three or fewer words (i.e. with two or fewer words between
- them.) The query would find ``Bob Dylan, aka. Robert
- Zimmerman'', but not ``Bob Dylan, born as Robert Zimmerman''
+ them.) The query would find "Bob Dylan, aka. Robert
+ Zimmerman", but not "Bob Dylan, born as Robert Zimmerman"
since the distance in this case is four.
</para>
</example>
access point
2038 indicates West Bounding Coordinate and
2030 indicates East Bounding Coordinate,
- so the query is for areas extending from -114 degrees
- to no more than -109 degrees.
+ so the query is for areas extending from -114 degrees longitude
+ to no more than -109 degrees longitude.
</para>
</example>
</sect3>
<title>CCL Syntax</title>
<para>
The CCL parser obeys the following grammar for the FIND argument.
- The syntax is annotated by in the lines prefixed by
+ The syntax is annotated using lines prefixed by
<literal>--</literal>.
</para>
<screen>
singlechar#mask
</screen>
<para>
- Assuming that the qualifiers <literal>ti</literal>,
- <literal>au</literal>
- and <literal>date</literal> are defined we may use:
+ Assuming that the qualifiers <literal>ti</literal>
+ and <literal>au</literal>
+ and <literal>date</literal> are defined, we may use:
</para>
<screen>
ti=self portrait
</para>
<para>
where <replaceable>qualifier-name</replaceable> is the name of the
- qualifier to be used (eg. <literal>ti</literal>),
+ qualifier to be used (e.g. <literal>ti</literal>),
<replaceable>type</replaceable> is attribute type in the attribute
set (Bib-1 is used if no attribute set is given) and
<replaceable>val</replaceable> is attribute value.
The <replaceable>type</replaceable> can be specified as an
- integer or as it be specified either as a single-letter:
+ integer, or as a single-letter:
<literal>u</literal> for use,
- <literal>r</literal> for relation,<literal>p</literal> for position,
- <literal>s</literal> for structure,<literal>t</literal> for truncation
+ <literal>r</literal> for relation, <literal>p</literal> for position,
+ <literal>s</literal> for structure,<literal>t</literal> for truncation,
or <literal>c</literal> for completeness.
The attributes for the special qualifier name <literal>term</literal>
are used when no CCL qualifier is given in a query.
<entry>
Use attribute (1). Common use attributes are
1 Personal-name, 4 Title, 7 ISBN, 8 ISSN, 30 Date,
- 62 Subject, 1003 Author), 1016 Any. Specify value
+ 62 Subject, 1003 Author, 1016 Any. Specify value
as an integer.
</entry>
</row>
<entry><literal>t=</literal><replaceable>value</replaceable></entry>
<entry>
Truncation attribute (5). Values: 1 right, 2 left,
- 3 left& right, 100 none, 101 process #, 102 regular-1,
+ 3 left and right, 100 none, 101 process #, 102 regular-1,
103 regular-2, 104 CCL.
</entry>
</row>
<row>
<entry><literal>s=al</literal></entry>
<entry>
- Each token in the term is ANDed. (and-list).
+ Each token in the term is ANDed (and-list).
This does not set the structure at all.
</entry>
</row>
<row><entry><literal>s=ol</literal></entry>
<entry>
- Each token in the term is ORed. (or-list).
+ Each token in the term is ORed (or-list).
This does not set the structure at all.
</entry>
</row>
</row>
<row><entry><literal>r=o</literal></entry>
<entry>
- Allows ranges and the operators greather-than, less-than, ...
+ Allows ranges and the operators greater-than, less-than, ...
equals.
This sets Bib-1 relation attribute accordingly (relation
ordered). A query construct is only treated as a range if
<row><entry><literal>r=omiteq</literal></entry>
<entry>
This will omit relation=equals (@attr 2=3) when r=o / r=r
- is used. This is useful for servers that somehow breaks
+ is used. This is useful for servers that somehow break
when an explicit relation=equals is used. Omitting the
relation is usually safe because "equals" is the default
behavior. This tweak was added in YAZ version 5.1.2.
</row>
<row><entry><literal>t=b</literal></entry>
<entry>
- Allows term to be both left&right truncated.
+ Allows term to be both left-and-right truncated.
If term is of the form <literal>?x?</literal>, the
resulting term is <literal>x</literal> and trunctation is
- set to both left&right.
+ set to both left and right.
</entry>
</row>
<row><entry><literal>t=x</literal></entry>
<entry>
Allows masking anywhere in a term, thus fully supporting
# (mask one character) and ? (zero or more of any).
- If masking is used, trunction is set to 102 (regexp-1 in term)
+ If masking is used, truncation is set to 102 (regexp-1 in term)
and the term is converted accordingly to a regular expression.
</entry>
</row>
<entry>
Allows masking anywhere in a term, thus fully supporting
# (mask one character) and ? (zero or more of any).
- If masking is used, trunction is set to 104 (Z39.58 in term)
+ If masking is used, truncation is set to 104 (Z39.58 in term)
and the term is converted accordingly to Z39.58 masking term -
actually the same truncation as CCL itself.
</entry>
<literal>ti</literal>
sets the use-attribute to 4. <literal>au</literal> sets the
use-attribute to 1.
- When no qualifiers are used in the query the structure-attribute is
+ When no qualifiers are used in the query, the structure-attribute is
set to free-form-text (105) (rule for <literal>term</literal>).
The <literal>date</literal> sets the relation attribute to
the relation used in the CCL query and sets the use attribute
<para>
which takes the CCL profile (<literal>bibset</literal>) and query
(<literal>str</literal>) as input. Upon successful completion the RPN
- tree is returned. If an error occur, such as a syntax error, the integer
+ tree is returned. If an error occurs, such as a syntax error, the integer
pointed to by <literal>error</literal> holds the error code and
<literal>pos</literal> holds the offset inside query string in which
the parsing failed.
int cql_parser_stdio(CQL_parser cp, FILE *f);
</synopsis>
The functions <function>cql_parser_stream</function> and
- <function>cql_parser_stdio</function> parses a CQL query
+ <function>cql_parser_stdio</function> parse a CQL query
- just like <function>cql_parser_string</function>.
The only difference is that the CQL query can be
fed to the parser in different ways.
<sect3 id="cql.tree">
<title>CQL tree</title>
<para>
- The the query string is valid, the CQL parser
+ If the query string is valid, the CQL parser
generates a tree representing the structure of the
CQL query.
</para>
<synopsis>
struct cql_node *cql_parser_result(CQL_parser cp);
</synopsis>
- <function>cql_parser_result</function> returns the
+ <function>cql_parser_result</function> returns
a pointer to the root node of the resulting tree.
</para>
<para>
error-code and sets the string-pointer at
<literal>*addinfop</literal> to point to a string containing
additional information about the error that occurred: for
- example, if the error code is 15 (``Illegal or unsupported context
- set''), the additional information is the name of the requested
+ example, if the error code is 15 ("Illegal or unsupported context
+ set"), the additional information is the name of the requested
context set that was not recognised.
</para>
<para>
Typically, the RPN specifies an equivalent use attribute.
</para>
<para>
- For terms not bound by an index the pattern
+ For terms not bound by an index, the pattern
<literal>index.cql.serverChoice</literal> is used.
Here, the prefix <literal>cql</literal> is defined as
<literal>http://www.loc.gov/zing/cql/cql-indexes/v1.0/</literal>.
<listitem>
<para>
This pattern specifies how a CQL relation is mapped to RPN.
- <replaceable>pattern</replaceable> is name of relation
+ The <replaceable>pattern</replaceable> is name of relation
operator. Since <literal>=</literal> is used as
separator between CQL pattern and RPN, CQL relations
including <literal>=</literal> cannot be
<listitem>
<para>
This pattern specifies how a CQL structure is mapped to RPN.
- Note that this CQL pattern is somewhat to similar to
+ Note that this CQL pattern is somewhat similar to
CQL pattern <literal>relation</literal>.
The <replaceable>type</replaceable> is a CQL relation.
</para>
<para>
Conversion from CQL to XCQL is trivial and does not
require a mapping to be defined.
- There three functions to choose from depending on the
+ There are three functions to choose from depending on the
way you wish to store the resulting output (XML buffer
containing XCQL).
<synopsis>
void cql_to_xml_stdio(struct cql_node *cn, FILE *f);
</synopsis>
Function <function>cql_to_xml_buf</function> converts
- to XCQL and stores result in a user supplied buffer of a given
+ to XCQL and stores the result in a user-supplied buffer of a given
max size.
</para>
<para>
<function>cql_to_xml</function> writes the result in
- a user defined output stream.
+ a user-defined output stream.
<function>cql_to_xml_stdio</function> writes to a
a file.
</para>
</para>
<para>
An OID can either be declared as a automatic variable or it can
- allocated using the memory utilities or ODR/NMEM. It's
+ be allocated using the memory utilities or ODR/NMEM. It's
guaranteed that an OID can fit in <literal>OID_SIZE</literal> integers.
</para>
<example id="tools.oid.bib1.1"><title>Create OID on stack</title>
</example>
<para>
And OID may also be filled from a string-based representation using
- dots (.). This is achieved by function
+ dots (.). This is achieved by the function
<screen>
int oid_dotstring_to_oid(const char *name, Odr_oid *oid);
</screen>
</para>
<example id="tools.oid.bib1.2"><title>Using oid_oiddotstring_to_oid</title>
<para>
- We can fill the Bib-1 attribute set OID easier with:
+ We can fill the Bib-1 attribute set OID more easily with:
<screen>
Odr_oid bib1[OID_SIZE];
oid_oiddotstring_to_oid("1.2.840.10003.3.1", bib1);
</para>
</example>
<para>
- We can also allocate an OID dynamically on a ODR stream with:
+ We can also allocate an OID dynamically on an ODR stream with:
<screen>
Odr_oid *odr_getoidbystr(ODR o, const char *str);
</screen>
- This creates an OID from string-based representation using dots.
+ This creates an OID from a string-based representation using dots.
This function take an &odr; stream as parameter. This stream is used to
allocate memory for the data elements, which is released on a
subsequent call to <function>odr_reset()</function> on that stream.
<example id="tools.oid.bib1.3">
<title>Using odr_getoidbystr</title>
<para>
- We can create a OID for the Bib-1 attribute set with:
+ We can create an OID for the Bib-1 attribute set with:
<screen>
Odr_oid *bib1 = odr_getoidbystr(odr, "1.2.840.10003.3.1");
</screen>
</para>
<para>
OIDs can be copied with <function>oid_oidcpy</function> which takes
- two OID lists as arguments. Alternativly, an OID copy can be allocated
- on a ODR stream with:
+ two OID lists as arguments. Alternatively, an OID copy can be allocated
+ on an ODR stream with:
<screen>
Odr_oid *odr_oiddup(ODR odr, const Odr_oid *o);
</screen>
</para>
<para>
A YAZ database handle is of type <literal>yaz_oid_db_t</literal>.
- Actually that's a pointer. You need not think deal with that.
+ Actually that's a pointer. You need not deal with that.
YAZ has a built-in database which can be considered "constant" for
most purposes.
- We can get hold that by using function <function>yaz_oid_std</function>.
+ We can get hold of that by using function <function>yaz_oid_std</function>.
</para>
<para>
All functions with prefix <function>yaz_string_to_oid</function>
<title>Standard OIDs</title>
<para>
All the object identifers in the standard OID database as returned
- by <function>yaz_oid_std</function> can referenced directly in a
+ by <function>yaz_oid_std</function> can be referenced directly in a
program as a constant OID.
Each constant OID is prefixed with <literal>yaz_oid_</literal> -
followed by OID class (lowercase) - then by OID name (normalized and
Z39.50 PDUs and related structures, it is convenient to use the
memory-management system of the &odr; subsystem (see
<xref linkend="odr.use"/>). However, in some circumstances
- where you might otherwise benefit from using a simple nibble memory
+ where you might otherwise benefit from using a simple nibble-memory
management system, it may be impractical to use
<function>odr_malloc()</function> and <function>odr_reset()</function>.
For this purpose, the memory manager which also supports the &odr;
allocated on the handle.
</para>
<para>
- The nibble memory pool is shared amongst threads. POSIX
+ The nibble-memory pool is shared amongst threads. POSIX
mutex'es and WIN32 Critical sections are introduced to keep the
module thread safe. Function <function>nmem_init()</function>
- initializes the nibble memory library and it is called automatically
+ initializes the nibble-memory library and it is called automatically
the first time the <literal>YAZ.DLL</literal> is loaded. &yaz; uses
function <function>DllMain</function> to achieve this. You should
<emphasis>not</emphasis> call <function>nmem_init</function> or
and implemented in <filename>src/log.c</filename>.
Due to name clash with syslog and some math utilities the logging
interface has been modified as of YAZ 2.0.29. The obsolete interface
- is still available if in header file <filename>yaz/log.h</filename>.
+ is still available in header file <filename>yaz/log.h</filename>.
The key points of the interface are:
</para>
<screen>
passed to <function>yaz_log_init_level</function> for it to take effect.
</para>
<para>
- Each module should check what log bits it should be used, by calling
+ Each module should check what log bits should be used, by calling
<function>yaz_log_module_level</function> with a suitable name for the
- module. The name is cleared from a preceding path and an extension, if any,
+ module. The name is cleared of a preceding path and an extension, if any,
so it is quite possible to use <literal>__FILE__</literal> for it. If the
name has been passed to <function>yaz_log_mask_str</function>, the routine
returns a non-zero bitmask, which should then be used in consequent calls
<literal>malloc, nmem, odr, eventl</literal> for internal
debugging of yaz itself.
Of course, any program using yaz is welcome to define as many new
- ones, as it needs.
+ ones as it needs.
</para>
<para>
By default the log is written to stderr, but this can be changed by a call
<para>
YAZ provides a fast utility for working with MARC records.
Early versions of the MARC utility only allowed decoding of ISO2709.
- Today the utility may both encode - and decode to a varity of formats.
+ Today the utility may both encode - and decode to a variety of formats.
</para>
<synopsis><![CDATA[
#include <yaz/marcdisp.h>
by calling <function>yaz_marc_destroy</function>.
</para>
<para>
- All other function operate on a <literal>yaz_marc_t</literal> handle.
+ All other functions operate on a <literal>yaz_marc_t</literal> handle.
The output is specified by a call to <function>yaz_marc_xml</function>.
The <literal>xmlmode</literal> must be one of
<variablelist>
<listitem>
<para>
A simple line-by-line format suitable for display but not
- recommend for further (machine) processing.
+ recommended for further (machine) processing.
</para>
</listitem>
</varlistentry>
<term>YAZ_MARC_JSON</term>
<listitem>
<para>
- <ulink url="&url.marc_in_json;">MARC-in_JSON</ulink> format.
+ <ulink url="&url.marc_in_json;">MARC-in-JSON</ulink> format.
</para>
</listitem>
</varlistentry>
The actual conversion functions are
<function>yaz_marc_decode_buf</function> and
<function>yaz_marc_decode_wrbuf</function> which decodes and encodes
- a MARC record. The former function operates on simple buffers, the
+ a MARC record. The former function operates on simple buffers, and
stores the resulting record in a WRBUF handle (WRBUF is a simple string
type).
</para>
<para>
Applications like
Pazpar2 uses XSLT to convert an XML encoded MARC record to an internal
- representation. This conversion mostly check the tag of a MARC field
+ representation. This conversion mostly checks the tag of a MARC field
to determine the basic rules in the conversion. This check is
- costly when that is tag is encoded as an attribute in MARCXML.
+ costly when that tag is encoded as an attribute in MARCXML.
By having the tag value as the element instead, makes processing
many times faster (at least for Libxslt).
</para>
A control field is encoded as element <literal>c</literal> concatenated
with the tag value of the control field if the tag value
matches the regular expression <literal>[a-zA-Z0-9]*</literal>.
- If the tag value do not match the regular expression
+ If the tag value does not match the regular expression
<literal>[a-zA-Z0-9]*</literal> the control field is encoded
as element <literal>c</literal> and attribute <literal>code</literal>
will hold the tag value.
- This rule ensure that in the rare cases where a tag value might
- result in a non-wellformed XML YAZ encode it as a coded attribute
+ This rule ensures that in the rare cases where a tag value might
+ result in a non-well-formed XML, then YAZ will encode it as a coded attribute
(as in MARCXML).
</para>
<para>
- The control field content is the the text value of this element.
+ The control field content is the text value of this element.
Indicators are encoded as attribute names
- <literal>i1</literal>, <literal>i2</literal>, etc.. and
+ <literal>i1</literal>, <literal>i2</literal>, etc. and
corresponding values for each indicator.
</para>
</listitem>
A data field is encoded as element <literal>d</literal> concatenated
with the tag value of the data field or using the attribute
<literal>code</literal> as described in the rules for control fields.
- The children of the data field element is subfield elements.
+ The children of the data field element are subfield elements.
Each subfield element is encoded as <literal>s</literal>
concatenated with the sub field code.
The text of the subfield element is the contents of the subfield.
- Indicators are encoded as attributes for the data field element similar
+ Indicators are encoded as attributes for the data field element, similar
to the encoding for control fields.
</para>
</listitem>
The Retrieval facility is driven by an XML configuration. The
configuration is neither Z39.50 ZeeRex or SRU ZeeRex. But it
should be easy to generate both of them from the XML configuration.
- (unfortunately the two versions
- of ZeeRex differ substantially in this regard).
+ (Unfortunately the two versions
+ of ZeeRex differ substantially in this regard.)
</para>
<sect2 id="tools.retrieval.format">
<title>Retrieval XML format</title>
<listitem>
<para>
Defines the name of the retrieval format. This can be
- any string. For SRU, the value, is equivalent to schema (short-hand);
+ any string. For SRU, the value is equivalent to schema (short-hand);
for Z39.50 it's equivalent to simple element set name.
For YAZ 3.0.24 and later this name may be specified as a glob
expression with operators
<listitem>
<para>
Defines the URI schema name of the retrieval format. This can be
- any string. For SRU, the value, is equivalent to URI schema.
+ any string. For SRU, the value is equivalent to URI schema.
For Z39.50, there is no equivalent.
</para>
</listitem>
</para>
<para>
The attributes, <literal>name</literal> and <literal>syntax</literal>
- may be specified for the <literal>backend</literal> element. These
+ may be specified for the <literal>backend</literal> element. The
semantics of these attributes is equivalent to those for the
<literal>retrieval</literal>. However, these values are passed to
the "backend".
</para>
<para>
- The <literal>backend</literal> element may includes one or more
+ The <literal>backend</literal> element may include one or more
conversion instructions (as children elements). The supported
conversions are:
<variablelist>
Format of input. Supported values are
<literal>marc</literal> (for ISO2709), <literal>xml</literal>
(MARCXML/MarcXchange) and <literal>json</literal>
- (<ulink url="&url.marc_in_json;">MARC-in_JSON</ulink>).
+ (<ulink url="&url.marc_in_json;">MARC-in-JSON</ulink>).
</para>
</listitem>
</varlistentry>
<literal>marc</literal> (ISO2709),
<literal>marcxhcange</literal> (for MarcXchange),
or <literal>json</literal>
- (<ulink url="&url.marc_in_json;">MARC-in_JSON </ulink>).
+ (<ulink url="&url.marc_in_json;">MARC-in-JSON </ulink>).
</para>
</listitem>
</varlistentry>
<example id="tools.retrieval.marcxml">
<title>MARCXML backend</title>
<para>
- SRW/SRU and Solr backends returns records in XML.
+ SRW/SRU and Solr backends return records in XML.
If they return MARCXML or MarcXchange, the retrieval module
can convert those into ISO2709 formats, most commonly USMARC
(AKA MARC21).
</para>
<para>
In SRU/Solr, however, the model is different. Here, sorting is specified
- during the the search operation. Note, however, that SRU might
+ during the search operation. Note, however, that SRU might
perform sort as separate search, by referring to an existing result-set
in the query (result-set reference).
</para>
<sect2>
<title>Using the Z39.50 sort service</title>
<para>
- yaz-client and the ZOOM API supports the Z39.50 sort facility. In any
+ yaz-client and the ZOOM API support the Z39.50 sort facility. In any
case the sort sequence or sort critiera is using a string notation.
This notation is a one-line notation suitable for being manually
- entered or generated and allows for easy logging (one liner).
+ entered or generated, and allows for easy logging (one liner).
For the ZOOM API, the sort is specified in the call to ZOOM_query_sortby
function. For yaz-client the sort is performed and specified using
the sort and sort+ commands. For description of the sort criteria notation
critieria is specified along with the search query.
</para>
<para>
- The sort is triggered by the presence of type 7 and the value of type 7
+ The sort is triggered by the presence of type 7, and the value of type 7
specifies the
<ulink url="http://www.loc.gov/z3950/agency/asn1.html#SortKeySpec">
sortRelation
- </ulink>
+ </ulink>.
The value for type 7 is 1 for ascending and 2 for descending.
For the
<ulink url="http://www.loc.gov/z3950/agency/asn1.html#SortElement">
only the generic part is handled. If generic sortKey is of type
sortField, then attribute type 1 is present and the value is
sortField (InternationalString). If generic sortKey is of type
- sortAttributes, then the attributes in list is used . generic sortKey
+ sortAttributes, then the attributes in the list are used. Generic sortKey
of type elementSpec is not supported.
</para>
<para>
<sect1 id="facets">
<title>Facets</title>
<para>
- YAZ supports facets for in Solr, SRU 2.0 and Z39.50 protocols.
+ YAZ supports facets in the Solr, SRU 2.0 and Z39.50 protocols.
</para>
<para>
Like Type-1/RPN, YAZ supports a string notation for specifying
<function>yaz_pqf_parse_facet_list</function>.
</para>
<para>
- For ZOOM C the facets are given by option "facets"
- For yaz-client it is used for the facets command.
+ For ZOOM C the facets are given by option "facets".
+ For yaz-client it is used for the 'facets' command.
</para>
<para>
The grammar of this specification is as follows:
</literallayout>
The notation is inspired by PQF. The string following '@attr'
- may not include blanks and is of the form
+ must not include blanks and is of the form
<replaceable>type</replaceable><literal>=</literal><replaceable>value</replaceable>,
where <replaceable>type</replaceable> is an integer and
<replaceable>value</replaceable> is a string or an integer.
<row>
<entry>1</entry>
<entry>
- Field-name. This is often a string, eg "Author", "Year", etc.
+ Field-name. This is often a string, e.g. "Author", "Year", etc.
</entry>
</row>
<row>
releasing little bits of memory. Rather than managing the individual,
small bits of space, the system maintains a free-list of larger chunks
of memory, which are handed out in small bits. This scheme is
- generally known as a <emphasis>nibble memory</emphasis> system.
+ generally known as a <emphasis>nibble-memory</emphasis> system.
It is very useful for maintaining short-lived constructions such
as protocol PDUs.
</para>
The <replaceable>stream_close</replaceable> handler is optional and
if NULL for the function is provided, it will not be invoked.
The <replaceable>stream_write</replaceable> takes the ODR handle
- as parameter, the user defined handle, a type
+ as parameter, the user-defined handle, a type
<literal>ODR_OCTETSTRING</literal>, <literal>ODR_VISIBLESTRING</literal>
which indicates the type of contents is being written.
</para>
</para>
<para>
To make things a little easier, an alternative is given for string
- types that are not expected to contain embedded NULL characters (eg.
+ types that are not expected to contain embedded NULL characters (e.g.
VisibleString):
</para>
<synopsis>
null-terminates C strings.
</para>
<para>
- Functions are provided for the derived string types, eg:
+ Functions are provided for the derived string types, e.g.:
</para>
<synopsis>
int odr_visiblestring(ODR o, char **p, int optional,
</synopsis>
<para>
The opaque type <literal>Odr_bitmask</literal> is only suitable for
- holding relatively brief bit strings, eg. for options fields, etc.
+ holding relatively brief bit strings, e.g. for options fields, etc.
The constant <literal>ODR_BITMASK_SIZE</literal> multiplied by 8
gives the maximum possible number of bits.
</para>
projects / yaz-moved-to-github.git / blobdiff