X-Git-Url: http://jsfdemo.indexdata.com/?a=blobdiff_plain;f=doc%2Fpazpar2_conf.xml;h=4e0498045f270929025dd6d93d18e24c94e9c004;hb=e954f104fba0c6ef9142f09042e0b7e7f73d7388;hp=6deafa28ee008f4b10f1df061b31cbe67025cb1c;hpb=bb1af0d3e894c72d2392108890cb20db173f9f13;p=pazpar2-moved-to-github.git
diff --git a/doc/pazpar2_conf.xml b/doc/pazpar2_conf.xml
index 6deafa2..4e04980 100644
--- a/doc/pazpar2_conf.xml
+++ b/doc/pazpar2_conf.xml
@@ -8,7 +8,7 @@
%common;
]>
-
+
Pazpar2
@@ -31,22 +31,323 @@
DESCRIPTION
-
+
+ The pazpar2 configuration file, together with any referenced XSLT files,
+ govern pazpar2's behavior as a client, and control the normalization and
+ extraction of data elements from incoming result records, for the
+ purposes of merging, sorting, facet analysis, and display.
+
+
+
+ The file is specified using the option -f on the pazpar2 command line.
+ There is not presently a way to reload the configuration file without
+ restarting pazpar2, although this will most likely be added some time
+ in the future.
+
+
+ FORMAT
+
+ The configuration file is XML-structured. It must be valid XML. All
+ elements specific to pazpar2 should belong to the namespace
+ "http://www.indexdata.com/pazpar2/1.0" (this is assumed in the
+ following examples). The root element is named 'pazpar2'. Under the
+ root element are a number of elements which group categories of
+ information. The categories are described below.
+
+
+ server
+
+ This section governs overall behavior of the client. The data
+ elements are described below.
+
+
+
+ listen
+
+
+ Configures the webservice -- this controls how you can connect
+ to pazpar2 from your browser or server-side code. The
+ attributes 'host' and 'port' control the binding of the
+ server. The 'host' attribute can be used to bind the server to
+ a secondary IP address of your system, enabling you to run
+ pazpar2 on port 80 alongside a conventional web server. You
+ can override this setting on the command lineusing the option -h.
+
+
+
+
+
+ proxy
+
+
+ If this item is given, pazpar2 will forward all incoming HTTP
+ requests that do not contain the filename 'search.pz2' to the
+ host and port specified using the 'host' and 'port'
+ attributes. This functionality is crucial if you wish to use
+ pazpar2 in conjunction with browser-based code (JS, Flash,
+ applets, etc.) which operates in a security sandbox. Such code
+ can only connect to the same server from which the enclosing
+ HTML page originated. Pazpar2s proxy functionality enables you
+ to host all of the main pages (plus images, CSS, etc) of your
+ application on a conventional webserver, while efficiently
+ processing webservice requests for metasearch status, results,
+ etc.
+
+
+
+
+
+ service
+
+
+ This nested element controls the behavior of pazpar2 with
+ respect to your data model. In pazpar2, incoming records are
+ normalized, using XSLT, into an internal representation (see
+ the retrievalprofile secion.
+ The 'service' section controls the further processing and
+ extraction of data from the internal representation, primarily
+ through the 'metdata' sub-element.
+
+
+
+ metadata
+
+
+ One of these elements is required for every data element in
+ the internal representation of the record (see
+ . It governs
+ subsequent processing as pertains to sorting, relevance
+ ranking, merging, and display of data elements. It supports
+ the following attributes:
+
+
+
+ name
+
+
+ This is the name of the data element. It is matched
+ against the 'type' attribute of the 'metadata' element
+ in the normalized record. A warning is produced if
+ metdata elements with an unknown name are found in the
+ normalized record. This name is also used to represent
+ data elements in the records returned by the
+ webservice API, and to name sort lists and browse
+ facets.
+
+
+
+
+ type
+
+
+ The type of data element. This value governs any
+ normalization or special processing that might take
+ place on an element. Possible values are 'generic'
+ (basic string), 'year' (a range is computed if
+ multiple years are found in the record). Note: This
+ list is likely to increase in the future.
+
+
+
+
+ brief
+
+
+ If this is set to 'yes', then the data element is
+ includes in brief records in the webservice API. Note
+ that this only makes sense for metadata elements that
+ are merged (see below). The default value is 'no'.
+
+
+
+
+ sortkey
+
+
+ Specifies that this data element is to be used for
+ sorting. The possible values are 'numeric' (numeric
+ value), 'skiparticle' (string; skip common, leading
+ articles), and 'no' (no sorting). The default value is
+ 'no'.
+
+
+
+
+ rank
+
+
+ Specifies that this element is to be used to help rank
+ records against the user's query (when ranking is
+ requested). The value is an integer, used as a
+ multiplier against the basic TF*IDF score. A value of
+ 1 is the base, higher values give additional weight to
+ elements of this type. The default is '0', which
+ excludes this element from the rank calculation.
+
+
+
+
+ termlist
+
+
+ Specifies that this element is to be used as a
+ termlist, or browse facet. Values are tabulated from
+ incoming records, and a highscore of values (with
+ their associated frequency) is made available to the
+ client through the webservice API. The possible values
+ are 'yes' and 'no' (default).
+
+
+
+
+ merge
+
+
+ This governs whether, and how elements are extracted
+ from individual records and merged into cluster
+ records. The possible values are: 'unique' (include
+ all unique elements), 'longest' (include only the
+ longest element (strlen), 'range' (calculate a range
+ of values across al matching records), 'all' (include
+ all elements), or 'no' (don't merge; this is the
+ default);
+
+
+
+
+
+
+
+
+
+
+
+
+
+ queryprofile
+
+ At the moment, this directive is ignored; there is one global
+ CCL-mapping file which governs the mapping of queries to Z39.50
+ type-1. This file is located in etc/default.bib. This will change
+ shortly.
+
+
+
+ retrievalprofile
+
+ Note: In the present version, there is a single retrieval
+ profile. However, in a future release, it will be possible to
+ associate unique retrieval profiles with different targets, or to
+ generate retrieval profiles using XSLT from the ZeeRex description of
+ a target.
+
+
+
+ The following data elements are recognized for the retrievalprofile
+ directive:
+
+
+
+ requestsyntax
+
+
+ This element specifies the request syntax to be used in queries. It only
+ makes sense for Z39.50-type targets.
+
+
+
+
+ nativesyntax
+
+
+ This element specifies the native syntax and encoding of the
+ result records. The default is XML. The following attributes
+ are defined:
+
+
+ name
+
+
+ The name of the syntax. Currently recognized values are
+ 'iso2709' (MARC), and 'xml'.
+
+
+
+
+ format
+
+
+ The format, or schema, to be expected. Default is
+ 'marc21'.
+
+
+
+
+ encoding
+
+
+ The encoding of the response record. Typical values for
+ MARC records are 'marc8' (general MARC-8), 'marc8s'
+ (MARC-8, but maps to precomposed UTF-8 characters, more
+ suitable for use in web browsers), 'latin1'.
+
+
+
+
+ mapto
+
+
+ Specifies the flavor of MARCXML to map results to.
+ Default is 'marcxml'. 'marcxchange' is also possible, and
+ useful for Danish DANMARC records.
+
+
+
+
+
+
+
+
+
+
- OPTIONS
-
-
+ EXAMPLE
+ Below is a working example configuration:
+
+
- EXAMPLES
-
-
+
+
+
- FILES
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+ marc21
+
+
+
+
+
+]]>
+
+
+