mergekey and facets - for the server. These definitions serves as
default for services that don't have these given. For the meaning
of these settings refer to the
- <xref linkend="icu_chain">"icu_chain"</xref> element inside service.
+ <xref linkend="icuchain"/> element inside service.
</para>
</listitem>
</varlistentry>
</para>
</listitem>
</varlistentry>
+
+ <varlistentry>
+ <term id="facetrule">facetrule</term>
+ <listitem>
+ <para>
+ Specifies the ICU rule set to be used for normalizing
+ facets. If facetrule is omitted from metadata, the
+ rule set 'facet' is used.
+ </para>
+ </listitem>
+ </varlistentry>
<varlistentry>
<term>setting</term>
</varlistentry>
<varlistentry>
- <term id="icu_chain">icu_chain</term>
+ <term id="servicexslt" xreflabel="xslt">xslt</term>
+ <listitem>
+ <para>
+ Defines a XSLT stylesheet. The <literal>xslt</literal>
+ element takes exactly one attribute <literal>id</literal>
+ which names the stylesheet. This can be referred to in target
+ settings <xref linkend="pzxslt"/>.
+ </para>
+ <para>
+ The content of the xslt element is the embedded stylesheet XML
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term id="icuchain" xreflabel="icu_chain">icu_chain</term>
<listitem>
<para>
Specifies a named ICU rule set. The icu_chain element must include
Rule set 'relevance' is used to normalize
terms for relevance ranking. Rule set 'sort' is used to
normalize terms for sorting. Rule set 'mergekey' is used to
- normalize terms for making a mergekey and, finally, 'facet'
- is used to normalize facet terms (AKA termlists).
+ normalize terms for making a mergekey and, finally. Rule set 'facet'
+ is normally used to normalize facet terms, unless
+ <xref linkend="facetrule">facetrule</xref> is given for a
+ metadata field.
</para>
<para>
The icu_chain element must also include a 'locale'
<note>
<para>
- The following discussion of practical issues related to session and settings
- management are cast in terms of a user interface based on Ajax/Javascript
- technology. It would apply equally well to many other kinds of browser-based logic.
+ The following discussion of practical issues related to session
+ and settings management are cast in terms of a user interface based on
+ Ajax/Javascript technology. It would apply equally well to many other
+ kinds of browser-based logic.
</para>
</note>
<para>
- Typically, a Javascript client is not allowed to directly alter the parameters
- of a session. There are two reasons for this. One has to do with access
- to information; typically, information about a user will be stored in a
- system on the server side, or it will be accessible in some way from the server.
- However, since the Javascript client cannot be entirely trusted (some hostile
- agent might in fact 'pretend' to be a regular ws client), it is more robust
- to control session settings from scripting that you run as part of your
- webserver. Typically, this can be handled during the session initialization,
- as follows:
+ Typically, a Javascript client is not allowed to directly alter the
+ parameters of a session. There are two reasons for this. One has to do
+ with access to information; typically, information about a user will
+ be stored in a system on the server side, or it will be accessible in
+ some way from the server. However, since the Javascript client cannot
+ be entirely trusted (some hostile agent might in fact 'pretend' to be
+ a regular ws client), it is more robust to control session settings
+ from scripting that you run as part of your webserver. Typically, this
+ can be handled during the session initialization, as follows:
</para>
<para>
- Step 1: The Javascript client loads, and asks the webserver for a new Pazpar2
- session ID. This can be done using a Javascript call, for instance. Note that
- it is possible to submit Ajax HTTPXmlRequest calls either to Pazpar2 or to the
- webserver that Pazpar2 is proxying for. See (XXX Insert link to Pazpar2 protocol).
+ Step 1: The Javascript client loads, and asks the webserver for a
+ new Pazpar2 session ID. This can be done using a Javascript call, for
+ instance. Note that it is possible to submit Ajax HTTPXmlRequest calls
+ either to Pazpar2 or to the webserver that Pazpar2 is proxying
+ for. See (XXX Insert link to Pazpar2 protocol).
</para>
<para>
</para>
<para>
- Step 3: The webserver initializes a new Pazpar2 settings, and sets user-specific
- parameters as necessary, using the init webservice command. A new session ID is
- returned.
+ Step 3: The webserver initializes a new Pazpar2 settings, and sets
+ user-specific parameters as necessary, using the init webservice
+ command. A new session ID is returned.
</para>
<para>
- Step 4: The webserver returns this session ID to the Javascript client, which then
- uses the session ID to submit searches, show results, etc.
+ Step 4: The webserver returns this session ID to the Javascript
+ client, which then uses the session ID to submit searches, show
+ results, etc.
</para>
<para>
- Step 5: When the Javascript client ceases to use the session, Pazpar2 destroys
- any session-specific information.
+ Step 5: When the Javascript client ceases to use the session,
+ Pazpar2 destroys any session-specific information.
</para>
<refsect2>
<para>
Each file contains a root element named <settings>. It may
contain one or more <set> elements. The settings and set
- elements may contain the following attributes. Attributes in the set node
- overrides those in the setting root element. Each set node must
+ elements may contain the following attributes. Attributes in the set
+ node overrides those in the setting root element. Each set node must
specify (directly, or inherited from the parent node) at least a
target, name, and value.
</para>
multiple overlapping settings with the same name and target
value, the 'precedence' attribute determines what happens.
</para>
+ <para>
+ For Pazpar2 1.6.4 or later, the target ID may be user-defined, in
+ which case, the actual host, port, etc is given by setting
+ <xref linkend="pzurl"/>.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
</varlistentry>
<varlistentry>
- <term>pz:xslt</term>
+ <term id="pzxslt" xreflabel="pz:xslt">pz:xslt</term>
<listitem>
<para>
- Is a comma separated list of of files that specifies
+ Is a comma separated list of of stylesheet names that specifies
how to convert incoming records to the internal representation.
</para>
<para>
+ For each name, the embedded stylesheets (XSL) that comes with the
+ service definition are consulted first and takes precedence over
+ external files; see <xref linkend="servicexslt"/>
+ of service definition).
+ If the name does not match an embedded stylesheet it is
+ considered a filename.
+ </para>
+ <para>
The suffix of each file specifies the kind of tranformation.
Suffix "<literal>.xsl</literal>" makes an XSL transform. Suffix
"<literal>.mmap</literal>" will use the MMAP transform (described below).
<listitem>
<para>
Specifies a filter which allows Pazpar2 to only include
- records that meet a certain criteria in a result. Unmatched records
- will be ignored. The filter takes the form name, name~value, or name=value, which
+ records that meet a certain criteria in a result.
+ Unmatched records will be ignored.
+ The filter takes the form name, name~value, or name=value, which
will include only records with metadata element (name) that has the
- substring (~value) given, or matches exactly (=value). If value is omitted all records
- with the named
- metadata element present will be included.
+ substring (~value) given, or matches exactly (=value).
+ If value is omitted all records with the named metadata element
+ present will be included.
</para>
</listitem>
</varlistentry>
<term>pz:preferred</term>
<listitem>
<para>
- Specifies that a target is preferred, e.g. possible local, faster target. Using block=pref on show command
- will wait for all these targets to return records before releasing the block. If no target is preferred,
- the block=pref will identical to block=1, which release when one target has returned records.
+ Specifies that a target is preferred, e.g. possible local, faster
+ target. Using block=pref on show command will wait for all these
+ targets to return records before releasing the block.
+ If no target is preferred, the block=pref will identical to block=1,
+ which release when one target has returned records.
</para>
</listitem>
</varlistentry>
<term>pz:block_timeout</term>
<listitem>
<para>
- (Not yet implemented). Specifies the time for which a block should be released anyway.
+ (Not yet implemented).
+ Specifies the time for which a block should be released anyway.
</para>
</listitem>
</varlistentry>
</listitem>
</varlistentry>
- <varlistentry>
+ <varlistentry id="limitmap">
<term>pz:limitmap:<replaceable>name</replaceable></term>
<listitem>
<para>
</note>
</listitem>
</varlistentry>
+
+ <varlistentry id="pzurl">
+ <term>pz:url</term>
+ <listitem>
+ <para>
+ Specifies URL for the target and overrides the target ID.
+ </para>
+ <note>
+ <para>
+ <literal>pz:url</literal> is only recognized for
+ Pazpar2 1.6.4 and later.
+ </para>
+ </note>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="pzsortmap">
+ <term>pz:sortmap:<replaceable>field</replaceable></term>
+ <listitem>
+ <para>
+ Specifies native sorting for a target where
+ <replaceable>field</replaceable> is a sort criteria (see command
+ show). The value has to components separated by colon: strategy and
+ native-field. Strategy is one of <literal>z3950</literal>,
+ <literal>type7</literal>, <literal>cql</literal>,
+ <literal>sru11</literal>, or <literal>embed</literal>.
+ The second component, native-field, is the field that is recognized
+ by the target.
+ </para>
+ <note>
+ <para>
+ Only supported for Pazpar2 1.6.4 and later.
+ </para>
+ </note>
+ </listitem>
+ </varlistentry>
</variablelist>
-
+
</refsect2>
</refsect1>
projects / pazpar2-moved-to-github.git / blobdiff