</para>
</listitem>
</varlistentry>
-
+
<varlistentry>
- <term>relevance / sort / mergekey / facet</term>
+ <term>icu_chain</term>
<listitem>
<para>
Specifies character set normalization for relevancy / sorting /
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 "relevance" element inside service.
+ of these settings refer to the
+ <xref linkend="icuchain"/> element inside service.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>relevance / sort / mergekey / facet</term>
+ <listitem>
+ <para>
+ Obsolete. Use element icu_chain instead.
</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>
</listitem>
</varlistentry>
-
+
<varlistentry>
- <term>relevance</term>
+ <term id="icuchain" xreflabel="icu_chain">icu_chain</term>
<listitem>
<para>
- Specifies ICU tokenization and transformation rules
- for tokens that are used in Pazpar2's relevance ranking.
- The 'id' attribute is currently not used, and the 'locale'
- attribute must be set to one of the locale strings
+ Specifies a named ICU rule set. The icu_chain element must include
+ attribute 'id' which specifies the identifier (name) for the ICU
+ rule set.
+ Pazpar2 uses the particular rule sets for particular purposes.
+ 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. 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'
+ attribute which must be set to one of the locale strings
defined in ICU. The child elements listed below can be
in any order, except the 'index' element which logically
belongs to the end of the list. The stated tokenization,
</varlistentry>
<varlistentry>
+ <term>relevance</term>
+ <listitem>
+ <para>
+ Specifies the ICU rule set used for relevance ranking.
+ The child element of 'relevance' must be 'icu_chain' and the
+ 'id' attribute of the icu_chain is ignored. This
+ definition is obsolete and should be replaced by the equivalent
+ construct:
+ <screen>
+ <icu_chain id="relevance" locale="en">..<icu_chain>
+ </screen>
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term>sort</term>
<listitem>
<para>
- Specifies ICU tokenization and transformation rules
- for tokens that are used in Pazpar2's sorting. The contents
- is similar to that of <literal>relevance</literal>.
+ Specifies the ICU rule set used for sorting.
+ The child element of 'sort' must be 'icu_chain' and the
+ 'id' attribute of the icu_chain is ignored. This
+ definition is obsolete and should be replaced by the equivalent
+ construct:
+ <screen>
+ <icu_chain id="sort" locale="en">..<icu_chain>
+ </screen>
</para>
</listitem>
</varlistentry>
<listitem>
<para>
Specifies ICU tokenization and transformation rules
- for tokens that are used in Pazpar2's mergekey. The contents
- is similar to that of <literal>relevance</literal>.
+ for tokens that are used in Pazpar2's mergekey.
+ The child element of 'mergekey' must be 'icu_chain' and the
+ 'id' attribute of the icu_chain is ignored. This
+ definition is obsolete and should be replaced by the equivalent
+ construct:
+ <screen>
+ <icu_chain id="mergekey" locale="en">..<icu_chain>
+ </screen>
</para>
</listitem>
</varlistentry>
<listitem>
<para>
Specifies ICU tokenization and transformation rules
- for tokens that are used in Pazpar2's facets. The contents
- is similar to that of <literal>relevance</literal>.
+ for tokens that are used in Pazpar2's facets.
+ The child element of 'facet' must be 'icu_chain' and the
+ 'id' attribute of the icu_chain is ignored. This
+ definition is obsolete and should be replaced by the equivalent
+ construct:
+ <screen>
+ <icu_chain id="facet" locale="en">..<icu_chain>
+ </screen>
</para>
</listitem>
</varlistentry>
merge="longest" rank="2"/>
<metadata name="subject" merge="unique" termlist="yes" rank="3"/>
<metadata name="url" merge="unique"/>
- <relevance>
- <icu_chain id="relevance" locale="el">
- <transform rule="[:Control:] Any-Remove"/>
- <tokenize rule="l"/>
- <transform rule="[[:WhiteSpace:][:Punctuation:]] Remove"/>
- <casemap rule="l"/>
- </icu_chain>
- </relevance>
+ <icu_chain id="relevance" locale="el">
+ <transform rule="[:Control:] Any-Remove"/>
+ <tokenize rule="l"/>
+ <transform rule="[[:WhiteSpace:][:Punctuation:]] Remove"/>
+ <casemap rule="l"/>
+ </icu_chain>
<settings src="mysettings"/>
<timeout session="60"/>
<service>
<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>
<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>