Diffusion invenio-infoscience (maint-1.2) Browse

guide.html.wml
d5b36a574e3cmaint-1.2

guide.html.wml
View Options

This document is not UTF8. It was detected as ISO-8859-1 (Latin 1) and converted to UTF8 for display.

			## $Id$

			## This file is part of the CERN Document Server Software (CDSware).
			## Copyright (C) 2002, 2003, 2004, 2005, 2006 CERN.
			##
			## The CDSware is free software; you can redistribute it and/or
			## modify it under the terms of the GNU General Public License as
			## published by the Free Software Foundation; either version 2 of the
			## License, or (at your option) any later version.
			##
			## The CDSware is distributed in the hope that it will be useful, but
			## WITHOUT ANY WARRANTY; without even the implied warranty of
			## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
			## General Public License for more details.
			##
			## You should have received a copy of the GNU General Public License
			## along with CDSware; if not, write to the Free Software Foundation, Inc.,
			## 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA.

			#include "cdspage.wml" \
			title="BibFormat Admin Guide" \
			navtrail_previous_links="<a class=navtrail href=<WEBURL>/admin/<lang:star: index.*.html>>_(Admin Area)_</a> > <a class=navtrail href=<WEBURL>/admin/bibformat/>BibFormat Admin</a>" \
			navbar_name="admin" \
			navbar_select="bibformat-guide"

			<p>Version <: print generate_pretty_revision_date_string('$Id$'); :>

			<h2>Contents</h2>
			<strong>1. <a href="#1">Overview</a></strong><br>
			<strong>2. <a href="#2">Configuring BibFormat</a></strong><br>
			<strong>3. <a href="#3">Running BibFormat</a></strong><br>
			3.1 <a href="#2.1">From Web interface</a><br>
			3.2 <a href="#2.2">From the command-line interface</a><br>
			<strong>4. <a href="#4">Detailed Configuration Manual</a></strong><br>
			4.1 <a href="#4.1">About BibFormat</a><br>
			4.2 <a href="#4.2">How it works?</a><br>
			4.3 <a href="#4.3">A first look at the web configuration interface</a><br>
			4.4 <a href="#4.4">Mapping the input (OAI Extraction Rules)</a><br>
			4.5 <a href="#4.5">Defining output types: Behaviors</a><br>
			4.6 <a href="#4.6">Formats</a><br>
			4.7 <a href="#4.7">Knowledge bases (KBs)</a><br>
			4.8 <a href="#4.8">User Defined Functions (UDFs)</a><br>
			4.9 <a href="#4.9">Defining links</a><br>
			4.9.1 <a href="#4.9.1">EXTERNAL link conditions</a><br>
			4.9.2 <a href="#4.9.2">INTERNAL link conditions</a><br>
			4.9.3 <a href="#4.9.3">Example</a><br>
			4.10 <a href="#4.10">User management</a><br>
			4.11 <a href="#4.11">Evaluation Language Reference</a></br>

			<a name="1"></a><h2>1. Overview</h2>

			<p>The BibFormat admin interface enables you to specify how the
			bibliographic data is presented to the end user in the search
			interface and search results pages. For example, you may specify that
			titles should be printed in bold font, the abstract in small italic,
			etc. Moreover, the BibFormat is not only a simple bibliographic data
			<em>output formatter</em>, but also an automated <em>link
			constructor</em>. For example, from the information on journal name
			and pages, it may automatically create links to publisher's site based
			on some configuration rules.

			<a name="2"></a><h2>2. Configuring BibFormat</h2>

			<p>By default, a simple HTML format based on the most common fields
			(title, author, abstract, keywords, fulltext link, etc) is defined.
			You certainly want to define your own ouput formats in case you have a
			specific metadata structure.

			<p>Here is a short guide of what you can configure:

			<blockquote>
			<dl>

			<dt><a href="BEH_display.php">Behaviours</a>

			<dd>Define one or more output BibFormat behaviours. These are then
			passed as parameters to the BibFormat modules while executing
			formatting.

			<br><em>Example:</em> You can tell BibFormat that is has to enrich the
			incoming metadata file by the created format, or that it only has to
			print the format out.

			<dt><a href="OAIER_display.php">Extraction Rules</a>

			<dd>Define how the metadata tags from input are mapped into internal
			BibFormat variable names. The variable names can afterwards be used
			in formatting and linking rules.

			<br><em>Example:</em> You can tell that <code>100 $a</code> field
			should be mapped into <code>$100.a</code> internal variable that you
			could use later.

			<dt><a href="LINK_display.php">Link Rules</a>

			<dd>Define rules for automated creation of URI links from mapped
			internal variables.

			<br><em>Example:</em> You can tell a rule how to create a link to
			People database out of the <code>$100.a</code> internal variable
			repesenting author's name. (The <code>$100.a</code> variable was mapped
			in the previous step, see the Extraction Rules.)

			<dt><a href="LINK_FORMAT_display.php">File Formats</a>

			<dd>Define file format types based on file extensions. This will be
			used when proposing various fulltext services.

			<br><em>Example:</em> You can tell that <code>*.pdf</code> files will
			be treated as PDF files.

			<dt><a href="UDF_display.php">User Defined Functions (UDFs)</a>

			<dd>Define your own functions that you can reuse when creating your
			own output formats. This enables you to do complex formatting without
			ever touching the BibFormat core code.

			<br><em>Example:</em> You can define a function how to match and
			extract email addresses out of a text file.

			<dt><a href="FORMAT_display.php">Formats</a>

			<dd>Define the output formats, i.e. how to create the output out of
			internal BibFormat variables that were extracted in a previous step.
			This is the functionality you would want to configure most of the
			time. It may reuse formats, user defined functions, knowledge bases,
			etc.

			<br><em>Example:</em> You can tell that authors should be printed in
			italic, that if there are more than 10 authors only the first three
			should be printed, etc.

			<dt><a href="KB_display.php">Knowledge Bases (KBs)</a>

			<dd>Define one or more knowledge bases that enables you to transform
			various forms of input data values into the unique standard form on
			the output.

			<br><em>Example:</em> You can tell that <em>Phys Rev D</em> and
			<em>Physical Review D</em> are both the same journal and that these
			names should be standardized to <em>Phys Rev : D</em>.

			<dt><a href="test.php">Execution Test</a>

			<dd>Enables you to test your formats on your sample data file. Useful
			when debugging newly created formats.

			</dl>
			</blockquote>

			<p>To learn more on BibFormat configuration, you can consult the <a
			href="guide.html">BibFormat Admin Guide</a>.

			<a name="3"></a><h2>3. Running BibFormat</h2>

			<a name="3.1"></a><h3>3.1. From the Web interface</h3>
			<p>
			Run <a href="BIBREFORMAT_display.php">Reformat Records</a> tool.
			This tool permits you to update stored formats for bibliographic records.
			<br>
			It should normally be used after configuring BibFormat's
			<a href="BEH_display.php">Behaviours</a> and
			<a href="FORMAT_display.php">Formats</a>.
			When these are ready, you can choose to rebuild formats for selected
			collections or you can manually enter a search query and the web interface
			will accomplish all necessary formatting steps.
			<br>
			<em>Example:</em> You can request Photo collections to have their HTML
			brief formats rebuilt, or you can reformat all the records written by Ellis.

			<a name="3.2"></a><h3>3.2. From the command-line interface</h3>

			<p>Consider having an XML MARC data file that is to be uploaded into
			the CDSware. (For example, it might have been harvested from other
			sources and processed via <a href="../bibconvert/">BibConvert</a>.)
			Having configured BibFormat and its default output type behaviour, you
			would then run this file throught BibFormat as follows:

			<blockquote>
			<pre>
			$ bibformat < /tmp/sample.xml > /tmp/sample_with_fmt.xml
			</pre>
			</blockquote>

			that would create default HTML formats and would "enrich" the input
			XML data file by this format. (You would then continue the upload
			procedure by calling successively <a
			href="../bibupload/">BibUpload</a> and <a
			href="../bibwords/">BibWords</a>.)

			<p>Now consider a different situation. You would like to add a new
			possible format, say "HTML portfolio" and "HTML captions" in order to
			nicely format multiple photographs in one page. Let us suppose that
			these two formats are called <code>hp</code> and <code>hc</code> and
			are already loaded in the <code>collection_format</code> table.
			(TODO: describe how this is done via WebAdmin.) You would then
			proceed as follows: firstly, you would prepare the corresponding <a
			href="BEH_display.php">output behaviours</a> called <code>HP</code>
			and <code>HC</code> (TODO: note the uppercase!) that would not enrich
			the input file but that would produce an XML file with only
			<code>001</code> and <code>FMT</code> tags. (This is in order not to
			update the bibliographic information but the formats only.) You would
			also prepare corresponding <a href="FORMAT_display.php">formats</a>
			at the same time. Secondly, you would launch the formatting as
			follows:

			<blockquote>
			<pre>
			$ bibformat otype=HP,HC < /tmp/sample.xml > /tmp/sample_fmts_only.xml
			</pre>
			</blockquote>

			that should give you an XML file containing only 001 and FMT tags.
			Finally, you would upload the formats:

			<blockquote>
			<pre>
			$ bibupload < /tmp/sample_fmts_only.xml
			</pre>
			</blockquote>

			and that's it. The new formats should now appear in <a
			href="<WEBURL>">WebSearch</a>.

			<a name="4"></a><h2>4. Detailed Configuration Manual</h2>

			<p><small>What follows is a transcription of an old
			FlexElink Configuration Manual v0.3 (2002-07-31). The text suffers
			from missing screen snapshots, and the terminology may not be fully up-to-date
			at places.<!--FIXME-->
			</small>

			<a name="4.1"></a><h3>4.1. About BibFormat</h3>

			<p>BibFormat is a piece
			of software that is part of the CERN Document Server software (CDS, <a
			href="http://cdsweb.cern.ch/">http://cdsweb.cern.ch</a>).
			</p>

			<p>Its mission, in few
			words, is to provide a flexible mechanism to format the bibliographic records
			that are shown as a result of CDS Search user queries allowing the
			administrators or users customize the view of them. Besides, it offers the
			possibility of using a linking system that can generate automatically all the
			links included in the displayed records (fulltext access, electronic journals
			reference, etc) reducing considerably maintenance.</p>

			<p>To clarify this too
			formal definition, we'll try to illustrate the role of BibFormat inside the CDS
			Search module by showing the following figure. Please, note that this drawing
			is trying to show the main role that BibFormat plays in the CDS structure and
			it's quite simplified, but of course the underlying logic is a bit more
			complex.</p>

			<p><img src="./guide001.gif"></p>

			<p>[Fig. 0]</p>

			<p>As you can see, when a
			user query is received, Weblib determines which records from the database match
			it; then it ask BibFormat to format the obtained records. BibFormat looks at
			its rule repository and for each record determines which format has to be
			taken, applies the format specification and solves the possible links; gives
			all this (in a formatted way) back to Weblib and it makes a nice HTML page
			including the formatted results given by BibFormat among other info.</p>

			<p>The good point in all
			this is that anyone that has access to BibFormat rule repository is able to
			modify the final appearance of a query result in the CDS Search module without
			altering the logic of the search engine.</p>

			<p>In order to be able to
			modify this BibFormat rule repository, a web configuration interface is
			provided. Trough this paper, we'll try to explain (in a friendly way and form
			the user point of view) how to access this interface, how it's structured and
			how to configure BibFormat trough it to achieve desired results.</p>

			<a name="4.2"></a><h3>4.2. How it works?</h3>

			<p>We've outlined which is
			the role of BibFormat inside the CDS, so it's time now to have an overview of
			how it works and how it's organized. We'll try not to be very technical,
			however a few explanation about the BibFormat repository and architecture is
			needed to understand how it works.</p>

			<p>BibFormat, basically,
			takes some bibliographic records as input and produces a formatted & linked
			version of them as output. By "formatted" we mean that BibFormat can produce an
			output containing a transformed version of the input data (normally an HTML
			view); the good part is that you can entirely specify the transformation to
			apply. At the same time, by "linked" we mean that you can ask BibFormat to
			include (if necessary) inside this formatted version references to some
			Internet resources that are related to the data from some pre-configured rules.
			</p>

			<p>As an example, we could
			imagine that you'd want to see the resulting records from CDS Search queries to
			show their title in bold followed by their authors separated by comas. For
			achieving this you'll have to go to the BibFormat configuration interface and
			define a behavior for BibFormat in which you describe how to format incoming
			records:</p>

			<p>

			<table border cellspacing="0" width="100%">
			<tr>
			<td>
			<pre>

			"<b>" $title "</b>"
			forall($author){
			$author separator(", ")
			}

			</pre>
			</td>
			</tr>
			</table>

			<p align="center">Figure 1.-
			A very first <em>Evaluation Language</em> example</p>

			<p>Don't be scared!! It's a
			first approach to the way BibFormat allows you to describe formats. As you can
			see, BibFormat uses a special language that you'll have to learn if you want to
			be able to specify formats or links; it seems difficult (as much as a
			programming language) but you'll see that it's quite more easy than it seems at
			first sight.</p>

			<p>In the next figure, is
			shown how BibFormat works internally. When BibFormat is called, it receives a
			set of bibliographic records to format. It separates each record and translates
			it into a set of what we call "internal variables"; these "internal variables"
			are simply an internal representation of the bibliographic record; the
			important thing with them is that they will be available when you have to describe
			the formats. Once it has these "internal vars", the processor module looks into
			the behavior repository for that one (let's say format) you've asked BibFormat
			to apply (when BibFormat is called, you can indicate which of the
			pre-configured behaviors to apply; this allows it to have more than one
			behavior); inside this behavior you can specify which data you want to appear,
			how it has to appear, some links if they exist... in other words, the format
			(actually, it's something more than a format, it describes how BibFormat has to
			behave for a given input; that's why we refer to it as behavior). As we've already said, you can include links
			in a behavior specification; links are a special BibFormat feature that helps
			you to reduce the maintenance of your formats: you can include a link in
			several formats or behaviors.</p>

			<p>The picture below,
			describes all this explanation.</p>

			<p><img src="./guide003.jpg">

			<p>[Fig. 2]</p>

			<p>Summarizing, BibFormat can
			transform an input made up of bibliographic records in an HTML output (not only
			HTML but any text-based output) according to certain pre-configured
			specifications (behaviors) that you can entirely define using a certain
			language.</p>

			<p>Just to mention, currently
			BibFormat is working taking OAI MARC XML as format for input records, but it
			can be adapted to other ways of inputs (reading a database, function call, etc)
			with a little of development.</p>

			<a name="4.3"></a><h3>4.3. A first look at the web configuration interface</h3>

			<p>BibFormat can be
			configured through its configuration interface that is accessible via web. It's
			made up of a bunch of web pages that present you the main configuration aspects
			of BibFormat allowing you to change them. In this section we are going to have
			a first look at this web interface, how it's structured and its correspondence
			with BibFormat features.</p>

			<p>Before entering
			these web pages you'll be asked for your accessing username & password.
			Only certain users are allowed to access BibFormat WI; first you need a CDS
			account that you can create easily by using the standard CDS account manager;
			then you have to ask BibFormat administrator to give privileges to access the
			WI.</p>

			<p>. Once your password is accepted you'll access
			the configuration interface. You'll see that is quite simple: It's structured
			in different sections; each of them corresponds to a BibFormat feature and you
			can navigate through them by using a navigation bar that is always present on
			the left.</p>

			<p>[Fig. 3]</p>

			<p>Here you are a list
			of the different sections the interface offers you and their correspondence
			with BibFormat features:</p>

			<ul>
			<li><strong>Behaviors:</strong> This is the main section, the one you
			enter by default when you access the web interface. It contains definitions for
			the different pre-configured output types or behaviors that allow you to define
			how you want BibFormat to behave when each output type is selected. More information
			in chapter <em>Defining output types: Behaviors</em> of this manual.</li>

			<li><strong>OAI Extraction Rules:</strong> The input types and
			mapping rules for OAI MARC XML inputs are defined here. You'll find here the
			information about all the internal variables and their correspondence with the
			input XML tags. See chapter <em>Mapping the input</em> of this manual for more
			information.</li>

			<li><strong>Link Rules:</strong> Allows you to access the link rules
			repository for defining the way links are generated. See chapter <em>Defining
			Links</em> for a more detailed description about the BibFormat linking system.</li>

			<li><strong>UDFs:</strong> Presents you a list of all the User
			Defined Functions (UDFs) that you can use inside <em>Evaluation Language</em> (<em>EL</em>)
			statements that are used for specifying different configuration aspects.
			You'll also be able to modify or extend this list within this section.
			Everything about using UDFs and defining new ones in chapter <em>User Defined
			Functions (UDFs)</em>.</li>

			<li><strong>Formats:</strong> Another <em>EL</em> feature: You can
			define a certain piece of <em>EL</em> code under a name for re-using it whenever
			you want. See chapter <em>Formats</em>.</li>

			<li><strong>KBs:</strong> A complete management interface for <em>Knowledge
			Bases</em> (<em>KBs</em>); those <em>KBs</em> will also be available inside <em>EL</em>
			statements. See chapter <em>Knowledge Bases(Kbs)</em> for more specific
			information.</li>

			<li><strong>Execution Test:</strong> You'll be able to execute
			BibFormat from this section and view the results and some debug info in a web
			page. You have to specify an input data file (through a URL).</li>

			<li><strong>User management:</strong> Allows you to define which CDS
			users can access or not the BibFormat web interface.</li>

			</ul>

			<p>Each section has
			different particularities but the way of dealing with them follows a common
			line through the interface. However, each section with their common things and
			particular characteristics are treated in the following chapters of this
			manual.</p>

			<a name="4.4"></a><h3>4.4. Mapping the input (OAI Extraction Rules)</h3>

			<p>We have already spoken a bit about BibFormat <em>internal
			variables</em>. These are a key point to understand the BibFormat way of
			working. As you know, BibFormat takes some bibliographic records as input and,
			according to some pre-configured behavior, formats them into HTML, for example.
			The problem is that this input records can come in several formats: different
			XML conventions, database records, etc. For now, at CDS we only consider that
			the input comes in OAI MARC XML but for the near future we'll may be have to
			extend it to accept other input formats.</p>

			<p>That's the reason why <em>internal variables</em> appear; they
			provide a common way to refer to input data without relaying in any concrete
			format. In other words, we will define BibFormat links and behaviors referring
			to these <em>internal variables</em> and we'll have some rules that define how to
			map an input format to them, so we would be able to use any BibFormat defined
			behavior with any input that can be mapped to <em>internal variables</em>.</p>

			<p><img src="./guide004.gif"></p>

			<p>[Fig. 4]</p>

			<p>You shouldn't worry about this because is more in the
			development/administration side, but it's important to know where <em>internal
			variables</em> come from and what they refer to. Besides, for CDS we only
			consider the incoming data in OAI MARC XML format, so we'll talk only about
			this case.</p>

			<p><em>Internal variables</em> are quite a simple concept: It's just
			a label that represents some values from the input. Besides, a variable can
			have <em>fields</em> that are also labels that represent values from the input
			but that are related to other under the variable (e.g. You can have a variable
			that maps authors and another that maps authors home institutes independently;
			but if you want to have represent an author and his home institute you need to
			relate these two variables in some way). Variables and their fields also
			support multiple values.</p>

			<p>Focusing on OAI MARC XML, the concept of variable and field is
			already in the input structure.:</p>

			<ul>
			<li>Each occurrence of OAI MARC XML <em>varfield</em> element
			will correspond to a different variable value.</li>
			<li>Each occurrence of OAI MARC XML <em>subfield</em> inside
			a certain <em>varfield</em> element will correspond to a different field value of
			the variable that maps the <em>varfield</em>.</li>
			</ul>

			<p>So what we will have in BibFormat is a set of rules that tells a
			variable name to which <em>varfield</em> element corresponds and each variable
			field name which <em>subfield</em> element maps. Trough the web interface you'll
			be able to add or delete new fields to variables or variables themselves,
			you'll be able even to modify the mapping tags of variables (this way you can
			keep your formats independent of changes in the meaning of MARC tags).</p>

			<p>In the web interface, all this is located in <em>OAI Ext. Rules</em>
			section as you can see in the following figure:</p>

			<p>[Fig. 5]</p>

			<p>Let's illustrate how BibFormat maps a certain input to variables
			and fields with an example:</p>

			<p>We have this variable & field definition on BibFormat:</p>

			<p>

			<table border cellspacing='0' cellpadding='5'>
			<tr bgcolor='#e0e0e0'>
			<th align='center'>Var.<br>label</th>
			<th align='center'>Mapping tag</th>
			<th align='center'>Mult. V.</th>
			<th align='center'>Fields</th>
			</tr>
			<tr>
			<td align='center'>100</td>
			<td align='center'><varfield id="100" i1="" i2=""></td>
			<td align='center'>Yes</td>
			<td align='center'>

			<table border cellspacing='0'>
			<tr bgcolor='#e0e0e0'>
			<td align='center'>Field label</td>
			<td align='center'>Mapping tag</td>
			</tr>
			<tr>
			<td align='center'>a</td>
			<td align='center'><subfield label="a"></td>
			</tr>
			<tr>
			<td align='center'>e</td>
			<td align='center'><subfield label="e"></td>
			</tr>
			</table>

			</td>
			</tr>
			<tr>
			<td align='center'>909C0</td>
			<td align='center'><varfield id="909" i1="C" i2="0"></td>
			<td align='center'>No</td>
			<td>

			<table border cellspacing='0'>
			<tr bgcolor='#e0e0e0'>
			<td align='center'>Field label</td>
			<td align='center'>Mapping tag</td>
			</tr>
			<tr>
			<td align='center'>b</td>
			<td align='center'><subfield label="b"></td>
			</tr>
			</table>

			</td>
			</tr>
			</table>

			<p>

			<p>And then a record like the following arrives as input:</p>

			<p>

			<table border cellspacing="0" width="100%">
			<tr>
			<td>
			<pre>
			<oai_marc>
			<varfield id="037" i1="" i2="">
			<subfield label="a">SCAN-0009119</subfield>
			</varfield>
			<varfield id="100" i1="" i2="">
			<subfield label="a">Racah, Giulio</subfield>
			</varfield>
			<varfield id="100" i1="" i2="">
			<subfield label="a">Guignard, G</subfield>
			<subfield label="e">editor</subfield>
			</varfield>
			<varfield id="909" i1="C" i2="0">
			<subfield label="b">11</subfield>
			</varfield>
			<varfield id="909" i1="C" i2="0">
			<subfield label="b">12</subfield>
			</varfield>
			</oai_marc>
			</pre>
			</td>
			</tr>
			</table>

			<p>The result of the mapping would be like this:</p>

			<p>

			<table border cellspacing='0' cellpadding='5' width="60%">
			<col width="25%">
			<col width="25%">
			<col width="25%">
			<col width="25%">
			<tr bgcolor='#e0e0e0'>
			<th align='center' colspan='4'>Variable "100"</th>
			</tr>
			<tr>
			<td align='center' bgcolor='#e0e0e0'>Value# 0</td>
			<td> </td>
			<td align='center' bgcolor='#e0e0e0'>Field "a" value</td>
			<td align='center'><samp>Racah, Giulio</samp></td>
			</tr>
			<tr>
			<td align='center' rowspan='2' bgcolor='#e0e0e0'>Value# 1</td>
			<td align='center' rowspan='2'> </td>
			<td align='center' bgcolor='#e0e0e0'>Field "a" value</td>
			<td align='center'><samp>Guignard, G</samp></td>
			</tr>
			<tr>
			<td align='center' bgcolor='#e0e0e0'>Field "e" value</td>
			<td align='center'><samp>editor</samp></td>
			</tr>
			</table>

			<p>

			<table border cellspacing='0' cellpadding='5' width="60%">
			<col width="25%">
			<col width="25%">
			<col width="25%">
			<col width="25%">
			<tr bgcolor='#e0e0e0'>
			<th align='center' colspan='4'>Variable "909C0"</th>
			</tr>
			<tr>
			<td align='center'>Value# 0</td>
			<td align='center'> </td>
			<td align='center'>Field "b" value</td>
			<td align='center'><samp>12</samp></td>
			</tr>
			</table>

			<p>Notice how <em>varfield 037</em> is not considered because there
			isn't an entry in the BibFormat configuration. Also notice how the values are
			created: if "allow multiple values" is set to "Yes" each occurrence of a <em>varfield</em>
			element determines a new value (variable "100"); in other case, the last value
			is taken as single value for the variable (variable "909C0").</p>

			<a name="4.5"></a><h3>4.5. Defining output types: Behaviors</h3>

			<p>Now that we already know how internal variables are structured
			and what they represent in the input, it's time to have a look at how to
			configure BibFormat to transform that input data mapped into variables into
			HTML results (although any text-based output could be generated).</p>

			<p>When BibFormat is asked to format a bunch of bibliographic
			records, it is also necessary to specify which <em>output type</em> it has to
			use. This output type is a string that identifies a pre-configured set of
			conditions and actions that tells BibFormat how to behave with the given input
			data (that's why the terms <em>output type</em> and <em>behavior</em> are used
			indifferently along this document).</p>

			<p>BibFormat can have several pre-configured behaviors each one
			identified by a different label. There are two different types of behaviors
			(you can choose the behavior type when you define it):</p>

			<ol>
			<li>Normal:
			Consists in a behavior that outputs exactly the result of its evaluation.</li>
			<li>Input Erich (only for XML inputs): It echoes each xml record
			from the input inserting the behavior result just before the xml closing
			element of the record.</li>
			</ol>

			<p>Each behavior contains an ordered list of conditions; a
			condition can contain zero or more associated actions (actions are ordered
			inside a condition). A condition is a behavior item described by an <em>Evaluation
			Language</em> expression that gives as result "TRUE" or "FALSE". An action is an
			<em>Evaluation Language</em> (<em>EL</em>) statement that produces any output.</p>

			<p>When BibFormat is called to format a set of input records with a
			given behavior label, it looks for the behavior conditions. It evaluates their <em>EL</em>
			in order and when one of them produces "TRUE" as result, it looks for their
			associated actions. Then BibFormat evaluates the actions in the specified order
			and concatenates their result.</p>

			<p>By using different conditions you can specify alternative
			formats inside a behavior (imagine that you want to format a record differently
			depending on its base number); it's true that you could also reach this
			solution by using <em>EL IF</em> statements, but it's more clear, efficient and
			re-usable (you can change one condition without touching the rest or you can
			give it more priority than others, that means give it the chance to be
			evaluated before others, by changing its apply order).</p>

			<p>Actions are used for specifying the format itself or the actions
			you want to carry on with in case the condition is accomplished.</p>

			<p>Through the web interface you can define new output types or
			modify the ones that already exist. The use is quite easy: you just have to
			select the link in the desired item with the operation you want to do over it.</p>

			<p>[Fig. 6]</p>

			<p>Let's have a look at a simple example to illustrate how to
			define behavior that fit our needs:</p>

			<p>Imagine a typical case where you want to format bibliographic
			records but depending on their base number you want to apply different formats.
			Whenever a record from base 27 (standards) arrives we want only to show its
			title and the standard numbers, in other case a default format will be applied
			in which the title and authors are shown. We'll assume CDS variable notation
			and that the input rules are defined properly.</p>

			<p>We are going to define a new NORMAL behavior for this new
			situation, let's call it <em>SIMPLE</em>. In it we'll need two conditions to be
			defined: one for applying the default format and another one for the 27-base
			special one. The base number comes in variable 909C0.b, so the conditions would
			be based on this variable content.</p>

			<p>The result behavior should be defined like this:</p>

			<p>

			<table border cellspacing='0' width="60%">
			<tr>
			<th align='center' colspan='2' bgcolor='#a0a0a0'>SIMPLE<small>(NORMAL)</small></th>
			</tr>
			<tr>
			<td bgcolor='#e6e6e6'>10</td>
			<td bgcolor='#e6e6e6'>$909C0.b="27"</td>
			</tr>
			<tr>
			<td colspan='2'>
			<pre>

			"<b>"$245.a"</b>"
			forall($0248.a){
			rep_prefix(" - ") $0248.a separator("; ")
			}

			</pre>
			</td>
			</tr>
			<tr>
			<td bgcolor='#e6e6e6'>50</td>
			<td bgcolor='#e6e6e6'>""=""</td>
			</tr>
			<tr>
			<td colspan='2'>
			<pre>

			"<b"$245.a"</b>"
			forall($100.a){
			rep_prefix(" - Authors:") $100.a separator("; ")
			}

			</pre>
			</td>
			</tr>
			</table>

			<p>

			<p>Some explanations on this example are needed:</p>

			<ul>
			<li>As you can see we have defined two conditions: one for
			the 27-format and another for the default format. The point that is important
			is the order in which we put the conditions: For each record in the input the
			special one is evaluated first (because it has a lower evaluation number, 10)
			and if the condition is true the format will be applied; in case the base is
			not 27 the default condition is evaluated and because its condition <em>EL</em> code
			is always true the default will be used to format the record.</li>

			<li>Don't worry too much about the action code because it's
			quite trivial. There are some "strange" things like the use of functions <em>rep_prefix</em>
			and <em>separator</em>. These are special <em>UDFs</em> that have a special
			behavior inside a FORALL statement:

			<ul>
			<li><em>rep_prefix</em>: Prints the string argument only when we are in the
			first iteration of a <em>FORALL</em>. In order words, put the prefix of the
			string which is to be generated by the <em>FORALL</em> statement.</li>

			<li><em>Separator</em>: Prints the string argument in every <em>FORALL</em>
			iteration but not in the last one.</li>
			</ul>
			</li>
			</ul>

			<a name="4.6"></a><h3>4.6. Formats</h3>

			<p><em>Formats</em> are a special construction that BibFormat <em>Evaluation
			Language</em> (<em>EL</em>) offers. It allows you to group under an identifier
			some <em>EL</em> code and after you can call it from every <em>EL</em> statement.</p>

			<p>You can manage these formats using the web interface. It is
			quite easy to do so: When you access the <em>Formats</em> section it will present
			you a list with all the format identifiers that are already defined and a small
			documentation about what's the format for. From there you can see the whole <em>EL
			</em>code by using the link <em>[Code]</em>. You can add a new format by using the
			set of input boxes that you'll find at the end of the page. Also delete and
			modify operations are possible for already defined formats.</p>

			<p>[Fig. 7]</p>

			<p><strong><u>Note:</u></strong> When defining formats,
			one has to pay attention not to use "recursive" format calls (either direct or
			indirect); this can lead to execution problems. For example, imagine that we
			have a format called "ex 1" that has a call for itself:</p>

			<blockquote>
			<table border cellspacing='0' width="60%">
			<tr>
			<td align='center'>Format "ex_1"</td>
			</tr>
			<tr>
			<td align='center'>
			<pre>
			"hello world"
			format("ex_1")
			</pre>
			</td>
			</tr>
			</table>
			</blockquote>

			<p>this is a "direct" recursive call; you
			should never have these kind of calls as the web interface should warn you if
			it finds these kind of troubles. However, "indirect" calls are not detected by
			the web interface, so you have to care about them. One example of "indirect"
			recursion:</p>

			<p>

			<blockquote>
			<table border cellspacing='0' width="60%">
			<tr>
			<td align='center'>Format "ex_1"</td>
			</tr>
			<tr>
			<td align='center'>
			<pre>
			"hello world"
			format("ex_2")
			</pre>
			</td>
			</tr>
			</table>
			</blockquote>

			<a name="4.7"></a><h3>4.7. Knowledge bases (KBs)</h3>

			<p>This is yet another special feature provided by BibFormat <em>Evaluation
			Language</em>. In a few words, this allows you to map one string value to
			another according to a pre-stored set of key values that map to other values
			(the knowledge bases). All the knowledge bases are identified by a label that
			has to be unique (among other KBs identifiers); remember that identifiers are
			not case-sensitive.</p>

			<p>These sets of values, normally lived in a file, but with this
			new development there was the need to have an easy KB management that was
			integrated in BibFormat. For this reason, you can manage KBs from the BibFormat
			configuration interface: section <em>KBs</em>.</p>

			<p>When accessing to <em>KBs</em> section, the list of all the KBs
			identifiers defined will be displayed. Below it you'll find a set of controls
			to add new KBs; the use of these controls is as usual along the interface but
			there's something a bit special: Normally, you shouldn't fill in the input box
			that asks you for the <em>Knowledge base table name</em>; all the knowledge base
			data is handled by a database in which each KB corresponds to a DB table; this
			input box gets the internal table name for that KB; normally the KB manager
			will generate it for you so you shouldn't need to use it.</p>

			<p>[Fig. 8]</p>

			<p>Each KB has a link for accessing the list of values that it
			contains. If you click on it, a new window will show you the list of current
			values (key and mapped ones) and a very easy interface to add new values or to
			delete existing ones (KB values are case sensitive).</p>

			<p>[Fig. 9]</p>

			<a name="4.8"></a><h3>4.8. User Defined Functions (UDFs)</h3>

			<p>The use of <em>User Defined Functions</em> (<em>UDFs</em>) is one of
			the more powerful features of BibFormat <em>Evaluation Language</em> (<em>EL</em>).
			The idea is that inside <em>EL</em> you can use operations or functions over
			strings; normally a large number of different string transformations are needed
			when talking about formatting but we cannot pretend implement all this
			operations inside <em>EL</em> because it's in constant growing and new needs
			appear all the time. For dealing with this problem, BibFormat defines a
			mechanism that allows you to use define as much functions (<em>UDFs</em>) as you
			want and use them inside any <em>EL</em> statement.</p>

			<p>These functions are identified by a unique name and they receive
			data (over which they do operations) by parameters. These functions are defined
			in a programming language (PHP) and therefore good knowledge of this language
			is needed.</p>

			<p>BibFormat offers a complete UDF management through the <em>UDFs</em>
			web interface section. There you'll see a complete list of all defined <em>UDFs</em>
			with their identifier, parameters and a small documentation about what the UDF
			does. You can also add, delete or modify <em>UDFs</em> or even have a look at the
			PHP code of an already defined function (there you'll be able to launch small
			tests over the defined functions).</p>

			<p>[Fig. 10]</p>

			<p>The definition of these functions should be reserved to
			administrators and some particularities have to be taken into account when
			defining <em>UDFs</em>:</p>

			<ul>
			<li>When you want to add or modify a <em>UDF</em> you are
			asked for the parameter list; you have to enter the parameter names separated
			by comas. Ex: You want to define a new function for prefixing a given string
			with another, so you need two parameters (one for the string which is going to
			be prefixed, let's name it <em>str</em>, and another one for the prefix itself,
			let's name it <em>prefix</em>); you should enter them in the parameter input box
			like this: <em>prefix, str</em></li>

			<li>The order in which you specify the parameters when
			defining a function is the order in which they have to be passed to the <em>UDF</em>
			from an <em>EL</em> statement.</li>

			<li>When defining the PHP code of a function, there are
			some important things to consider:

			<ul>
			<li>The result of a function has to be a string.</li>

			<li>The parameters are available inside the PHP code as
			variables with the parameter name.</li>

			<li>The result of the function has to be defined by a PHP
			result clause giving the resulting string.</li>

			<li>Make sure the PHP code is correct (there's no way to
			know if the code is correct from BibFormat and it won't tell you if it is).</li>

			<li>There are some special variables available inside the
			PHP definition:

			<ul>
			<li>$FIRST_ITERATION: Is equal to "1" when we are in the first iteration
			of an <em>EL FORALL</em> statement. "0" in other case. If the call is made outside
			a <em>FORALL</em> is set to "1".</li>

			<li>$LAST_ITERATION: Just the opposite case.</li>
			</ul>

			<p>With these two
			variables you can define <em>FORALL</em> special functions like a function to
			print a separator.</p>
			</li>
			</ul>
			</li>
			</ul>

			<a name="4.9"></a><h3>4.9. Defining links</h3>

			<p>As we've already said, BibFormat is not only a formatter but it
			also provides a link manager but, what do we mean by 'link manager'? The idea
			is to have a set of rules that describe how to generate a link using certain
			data; if the link can be generated from those rules, then the link manager can
			check different things (i.e. see if the link is valid, if it's a link to a file
			it can check if the file exists and in which formats it exists, etc) and
			finally return the solved link. In other words, if you have a set of
			bibliographic records that can contain a certain link and that link can be
			coded in the link manager rules, you don't need to store each link in each
			bibliographic record, you just use the link manager to generate them
			dynamically; like this, you only have to maintain a small set of rules and not
			thousands of static links in records.</p>

			<p>BibFormat allows you to configure different <em>link definitions</em>
			each of them identified by a unique name; each of these <em>link definitions</em>
			have some associated <em>parameters</em> which are the information passed to the
			rules defined for it. Then, when you call the link manager to solve a link
			(from an <em>EL</em> statement, for example) you'll have to specify the
			identifier of the <em>link definition</em> you want to be used and the value for
			each of the parameters used by that <em>link definition</em> (always string
			values). The link manager will retrieve the rules associated to the <em>link
			definition</em> specified and will interpret those rules using the given
			parameter values, informing you if the link was generated correctly and result
			(the solved link).</p>

			<p>BibFormat provides this mechanism and through the web interface
			you can access to the rule repository for having a look at what are the
			available <em>link definitions</em>, define new link rules or maintain already
			defined ones. When adding or modifying a <em>link definition</em> you'll have to
			specify the parameters, please remember to separate them by using comas.</p>

			<p>[Fig. 10]</p>

			<p><em>Link definitions</em> are structurally quite similar to
			behaviors: Although there can be different types of them (as we'll see later),
			a <em>link definition</em> is made up of one or more conditions and each of these
			conditions can have one or more actions that tell how the link has to be built
			in case its condition is accomplished. In general, link rules (this includes
			conditions and actions) have a particular structure and they are described in <em>Evaluation
			Language</em> (<em>EL</em>) with one restriction: <em>EL LINK</em> statement
			cannot be used. Each group of conditions-actions of a link definition can be of
			a different <em>solving type</em> (actually, when you create a new link
			definition, its <em>solving type</em> its asked; this is just because all
			conditions that will be created for that link definition will have the selected
			<em>solving type</em> as default; but you can change it afterwards having a
			"mixed" <em>link definition</em>). Their structure and way the link manager interprets
			them will depend in their <em>solving type</em>. Currently, there you can define
			link conditions of two different <em>solving types</em>: EXTERNAL or INTERNAL. A
			more detailed explanation about each type is given later.</p>

			<p>As we've said a link definition is made up of various link
			conditions. When a solving for a concrete <em>link definition</em> is asked, the
			link manager retrieves all link conditions associated to it. Then it takes the
			first of them (following the <em>evaluation order</em> - the lower is the
			evaluation order number, the first the condition is considered), it evaluates
			its <em>EL</em> code with the parameter values passed and if the result is "TRUE"
			associated actions are executed, the link is returned and the solving process
			finishes. In case a condition fails, it looks for the next one. If all the
			conditions fail then the link manager returns that the link couldn't be solved.
			This is the general behavior of the link manager, but the way of determining if
			a link has been solved or not and the link building depends on the condition <em>solving
			type</em>.</p>

			<a name="4.9.1"></a><h4>4.9.1. EXTERNAL link conditions</h4>

			<p>This is the simplest way of solving links. It's intended to be
			used when you want to generate a link that points to an external resource
			(normally a web page). In this case the link condition is composed by only one
			action that will be evaluated if the associated condition is "TRUE". When a
			condition of this type is evaluated "TRUE" and the action is executed, the
			result of the action is given as the solved link and the link manager finishes.</p>

			<p>[Fig. 11]</p>

			<a name="4.9.2"></a><h4>4.9.2. INTERNAL link conditions</h4>

			<p>This condition solving type is intended to be used when you want
			to link to a document which is a file (inside or outside your file system) and
			that can be in different file formats.</p>

			<p>This case is a bit more complex than the previous one, so we'll
			go step-by-step explaining differences and special features:</p>

			<ul>
			<li>An INTERNAL condition has a <em>base file path</em> and a
			<em>base URL</em> associated. The <em>base file path</em> is the string that will
			be used as prefix when looking for a file generated by the actions associated
			to that condition. On the other hand, the <em>base URL</em> will be a string to
			which the link string (resulting from the actions) will be added (i.e. if the <em>base
			file path</em> of a condition is <code>/tmp/docs</code>
			and the <em>base URL</em> is <code>http://doc.cern.ch/</code>,
			if the condition is true and the result of the actions is <code>test.pdf</code>, the file path the link manager
			will have to check will be <code>/tmp/docs/test.pdf</code>
			and, if the file exists, the generated link will be <code>http:/doc.cern.ch/test.pdf</code>)</li>

			<li>Any condition of this type can several associated <em>file
			formats</em>. This is a new concept that is only used for INTERNAL condition
			solving. A <em>file format</em> is simply a set of file extensions that are
			grouped under an identifier. Then, you can associate a <em>file format</em>
			identifier with a link condition. When the condition is true the link manager
			will combine each result from the condition actions with the associated file
			formats to check the existence of a file of any format; this means that when an
			action is evaluated, the link manager takes the file extensions of each
			associated file format identifier and checks if the <em>file base path</em> +
			resulting action string + file extension exists in the file system.</li>

			<li>One condition of this type can have more than one
			associated action. Each of its actions describes an alternative way of building
			the file path. When a condition of this type is evaluated to "TRUE", the link
			manager retrieves its actions (following actions <em>apply order</em>) and
			evaluates the first one; with the action result it builds the file path in this
			way: <em>file base path</em> + resulting action string, and then combines this
			string with each of the <em>file extensions</em>. If any of the combination
			exists in the file system, the link is generated (if there are more than one
			file format combination that exist, the link variable will have multiple values
			containing the different links); if not, it starts the same process with the
			next action. If any of the actions drive to a existing file, the link is not
			generated.</li>

			<li>When calling the link manager from a <em>EL</em>
			statement (see chapter <em>Evaluation Language Reference</em>), if the link is
			solved we'll be able to access to a special internal variable that contains as
			value the resulting link. In the INTERNAL condition links, we have said that
			this variable can contain multiple values in case the link manager finds
			different file formats. In this case, there's another extension that consists
			in having some special variable fields containing special values for each value
			in the <em>LINK</em> variable and to which you can access when the link is solved;
			here's a table detailing the different variable LINK fields which are defined
			when a INTERNAL condition link is solved:</li>
			</ul>

			<blockquote>
			<table border cellspacing='0'>
			<tr>
			<th bgcolor='#a0a0a0'>Field name</th>
			<th bgcolor='#a0a0a0'>Value that contains</th>
			</tr>
			<tr>
			<th align='left'>url</th>
			<td>The same value as the LINK variable: The solved URL.</td>
			</tr>
			<tr>
			<th align='left'>file</th>
			<td>Contains the local full path to the file the solved URL points to.</td>
			</tr>
			<tr>
			<th align='left'>format_id</th>
			<td>Contains the file format id string</td>
			</tr>
			<tr>
			<th align='left'>format_desc</th>
			<td>Contains the file format description string (this
			is defined for each file format)</td>
			</tr>
			</table>
			</blockquote>

			<a name="4.9.3"></a><h4>4.9.2 Example</h4>

			<p>As the link generation is quite a complex topic (specially when
			talking about INTERNAL linking) we'll try to illustrate it with a simple
			example.</p>

			<p>Let's imagine we want to create a new link definition for
			generating full-text access to the documents that are archived on a document
			server (a file system which contains document's electronic versions). These
			documents are organized systematically depending in three characteristics that
			are included in the bibliographic records: BASE, CATEGORY and ID. When the base
			corresponds to "CERNREP" then the files are archived below directory <code>/pub/www/home/cernrep/</code>
			and can be stored following two different criteria that depend on the CATEGORY
			and ID values; the documents are all HTML. However, if the base is "PREPRINT"
			and the CATEGORY is either "HEP-TH" or "HEP-PH" they are stored under directory
			<code>/archive/electronic\|/pub/www/home/</code> following a certain criteria; in this
			case the documents can be in several file formats: PDF, Postscript, MS Word.</p>

			<p>Of course, we want only the link to be created if the files
			corresponding to the bibliographic records exist.</p>

			<p>So we start creating a new link definition that we'll call <em>FULLTEXT</em>.
			It will receive three parameters that are the information we need for
			generating this kind of links: BASE, CATEGORY and ID. We select INTERNAL as
			solving type as default and then we fill it the base file path and url with
			some default values (these values are not important, they will be copied by
			default to the conditions we are going to create afterwards).</p>

			<p>[Fig. 12]</p>

			<p>Then we create a condition for the first possibility: when BASE
			is "CERNREP". We select INTERNAL as link condition because we want to link to a
			file and we want to check its existence and we fill in the base file path and
			URL with the corresponding values. Then we assign the file format types and we
			enter the file archiving criteria as different actions.</p>

			<p>[Fig. 13]</p>

			<p>For the other possibility we proceed in the same way by adapting
			the definition to the requirements; we'll have something like this as result:</p>

			<p>[Fig. 14]</p>

			<p>Once we have finished the link definition, we can insert links
			of this type from a BibFormat behavior, for example. Let's imagine we have
			included a piece of <em>EL</em> code like this in a behavior because we want to
			insert a link to the full-text documents of any record:</p>

			<p>

			<table border cellspacing="0" width="100%">
			<tr>
			<td>
			<pre>

			link("FULLTEXT",$base, $category, $id)
			{
			"Fulltext: "
			forall($link){
			"<a href=\"" $link.url "\">" $link.format_desc "</a>"
			separator " - "
			}
			}

			</pre>
			</td>
			</tr>
			</table>

			<p>This <em>EL</em> statement will include the string "Fulltext: "
			followed by a link to all the documents found for the values of internal
			variables $base, $category, $id separated by " - ".</p>

			<p><a name="4.10"></a><h3>4.10. User management</h3>

			<p>The BibFormat web interface (WI) comes with a security mechanism
			which allows you to define which users can access the WI. BibFormat doesn't
			have a user management incorporated; instead it uses CDS user schema (as is a
			part of CDS). So if you are not registered as CDS user and you want to have
			access to BibFormat WI, first thing to do is to register in CDS through the
			standard procedure (for example via the CDS Search interface you can access the
			CDs account management system).</p>

			<p>BibFormat WI access policy is rather simple: it keeps a list of
			CDS users that can access the WI. Then if someone tries to access any part of
			the WI, the system will ask the user to identify him as CDS user. If the CDS
			login is successful and the user is in BibFormat's access list, then the user
			will gain access to the WI.</p>

			<p>There's a section in the WI which allows you to define which CDS
			users will have access to the WI. The use is rather simple: You can add CDS
			users to the access list by specifying either their CDS user id or their CDS
			login; then you can delete a CDS uses from the access list by simply selecting
			the link "delete" for the corresponding user.</p>

			<p>[Fig. 15]</p>

			<p>When you install BibFormat for the first time and you access to
			the WI you'll see that no login or password is asked. The security mechanism
			doesn't get activate until at least one user is added to the BibFormat's access
			list. So if you don't want to limit the access to BibFormat WI keep the access
			list without any user in.</p>

			<a name="4.11"></a><h4>4.11. Evaluation Language Reference</h4>

			<p>In this section we'll present a more or less formal definition
			of the <em>Evaluation Language</em> (EL); although we are using some formal
			methods to describe it we'll also make a quick explanation about the elements
			that made up the language and how to combine them to arrive to desired results.
			</p>

			<p>Just below you can find the EL definition, expressed in terms of
			EBNF (<em>Extended Backus-Naur Form</em>) notation. We have used capital letters
			to express non-terminal elements and non-capital/bold characters for the
			terminal ones. There's one remark to make: Whenever you find the mark
			<small><code>[REX]</code></small> after
			any definition, it means that we have used a regular expression just before in
			order to express a set of non-terminals.</p>

			<p>

			<table border cellspacing="0" width="100%">
			<tr>
			<td>
			<pre>

			SENTENCE ::= TERM {<strong>&&</strong> TERM \| <strong>\|\|</strong> TERM}

			TERM ::= FACTOR {<strong>=</strong> FACTOR \| <strong>!=</strong> FACTOR \| FACTOR}

			FACTOR ::= [<strong>!</strong>] BASIC

			BASIC ::= VARIABLE \| LITERAL \| FUNCTION \| <strong>(</strong> SENTENCE <strong>)</strong> \| FORALL \|
			IF \| FORMAT \| LINK \| COUNT \| KB

			VARIABLE ::= <strong>$</strong> STRING [<strong>.</strong> STRING]

			LITERAL ::= <strong>"([^"] \| \")*"</strong> <small>[REX]</small>

			FUNCTION ::= STRING <strong>(</strong> [ SENTENCE {<strong>,</strong> SENTENCE} ] <strong>)</strong>

			FORALL ::= <strong>forall (</strong> VARIABLE [<strong>,</strong> LITERAL] <strong>) {</strong> SENTENCE <strong>}</strong>

			IF ::= <strong>if(</strong> SENTENCE <strong>) {</strong> SENTENCE <strong>}</strong> [<strong>else {</strong> SENTENCE <strong>}</strong>]

			FORMAT ::= <strong>format(</strong> SENTENCE <strong>)</strong>

			LINK ::= <strong>link(</strong> SENTENCE <strong>,</strong> [SENTENCE {<strong>,</strong> SENTENCE}] <strong>) {</strong> SENTENCE <strong>}</strong>
			[<strong>else {</strong> SENTENCE <strong>}</strong>]

			COUNT ::= <strong>count(</strong> VARIABLE <strong>)</strong>

			KB ::= <strong>kb(</strong> SENTENCE <strong>)</strong>

			STRING ::= <strong>[a-zA-Z0-9_]</strong> <small>[REX]</small>

			</pre>
			</td>
			</tr>
			</table>

			<p>

			<p>This is just a formal way of describing the language, but don't
			worry if you don't understand it very well because just below these lines we'll
			try to describe it in a more informal way.</p>

			<p>To begin with, you should know that EL is a language designed to
			work with strings (a string is a collection of characters) but it has also some
			logic and comparison operations. One important thing you have to be aware of is
			that in EL blank spaces, tabulators or carriage returns have no more meaning
			than separator for elements of the language; that means that between two basic
			elements you can have as many spaces or carriage returns as you want.</p>

			<p>One of the basic elements of the language is what we call <em>LITERALS</em>.
			These things represent constant string values; they are delimited by a pair of
			double quote (") symbols surrounding the string you want to express. Everything
			you put inside the double quotes will be considered as it is, so inside a
			literal several spaces or carriage have meaning (it's the only case). If you
			want to express a double quote symbol inside a literal you have to <em>escape</em>
			it using \.</p>

			<p>Some examples of literals:</p>

			<ul>
			<li>If you want to represent the string <em>hello</em>,
			inside the EL you'll have to use <code>"hello"</code>.</li>

			<li>For the string <em>hello "big"      man</em>, the representation in EL is <code>"hello \"big\"      man"</code>
			(notice the escape characters and that spaces have meaning).</li>

			<li><em>Let's see \""</em> string has to be expressed in this
			way <code>"Let's see \\\"\""</code>.</li>
			</ul>

			<p>Another important basic element of the language is <em>VARIABLES</em>.
			These elements represent string data from the input to which you can refer
			inside of the language (and is considered also as a string). Variables are defined
			in advance by the administrator (or even users) so you have to know which of
			them you have access to. Additionally, variables can contain <em>FIELDS</em> that
			are simply other input values that are grouped under a variable because they
			have some kind of relationship between them (for example, you could have a
			variable for the information about the author and fields like name, born place,
			etc for it). If you want to know more about variables and their correspondence
			with the input you can look at the <em>Mapping the Input</em> section. The way of
			expressing a variable in EL is by a dollar symbol followed by any letter,
			number or underscore; variables are case-insensitive. To refer to any field of
			a variable, you simply put a dot followed by the field name (which is also made
			up of any character, number or underscore).</p>

			<p>Some examples about variables and fields:</p>

			<ul>
			<li>Imagine you have a variable which contains the author
			information and which is called <em>author</em>, to represent in EL you would
			have to write <code>"Author: " $100.a</code>. In every place
			that $author appears BibFormat will consider the value defined for it from the
			current input record.</li>

			<li>Then you know that the field <em>name</em> of variable <em>author</em>
			contains the author full name and you want to refer to it inside an EL
			statement, so you'd write <code>$author.name</code>.</li>

			<li>If we speak about CDS configuration, variable and field
			names correspond to MARC 21 tag & indicator names; so to refer to the main
			title of a bibliographic record we should use variable <em>245</em> field <em>b</em>,
			in EL terms: <code>$245.b</code>.</li>
			</ul>

			<p>Now that we know basic elements of the language we can start
			thinking about how to combine them. The most important (and unique) string
			operation is concatenation: adding strings. This operation is implicit to the
			language, so we just put language elements one before another, and the representation
			result will be the result of the basic elements one after another.</p>

			<p>Some samples:</p>

			<ul>
			<li>To represent the constant string <em>Author:</em>
			followed by the name of the author of the input record you should write <code>"Author: " $100.a</code> (it's supposed CDS
			configuration in which MARC 21 notation is used; authors correspond to variable
			100 field a).</li>

			<li>You want to output the title in bold (always HTML
			speaking) followed by the author in normal chars separated of the title by char
			/: <code>"<b>" $245.b "</b>/" $100.a</code></li>
			</ul>

			<p>These two, literals and variables, are only basic elements of
			the EL. You can combine them using concatenation to get new strings. But, of
			course, there are some more operations you can apply over strings: UDFs (<em>User
			Defined Functions</em>). We'll also name these elements as functions, because
			they are that: functions or operations to be applied over strings; when talking
			about strings we include basic elements or resulting string from applying any
			operations. A UDF has a name that identifies it uniquely and needs to get some information
			that we call <em>parameters</em>. A UDF gives another string as result depending
			on the parameter values (always strings). So to represent a function in EL you
			need its name followed by an open parenthesis, the parameter values separated
			by comas and a closing parenthesis. There's a list of UDF you can look at
			through the interface but this list can be extended to fit your needs (look at <em>UDFs</em>
			section of this manual).</p>

			<p>Some examples:</p>

			<ul>
			<li>You want to ensure that the title of a bibliographic
			record is always going to be in capital letters; good, there's a function
			called <em>upper</em> that takes one parameter and gives as result the parameter
			transformed in capital letters. You have to write the call like this: <code>upper($245.b)</code>.</li>

			<li>You want only the 3 first chars of an author name to
			appear in capital letters. We've seen there's a function for uppercasing a
			string but there's another one, called <em>copy</em> that gets a sub string from
			a string passed as first parameter from the char position indicated by the 2<sup>nd</sup>
			parameter and with the length given by the 3<sup>rd</sup> one: <code>copy(
			upper($100.a), "0", "3")</code>.</li>
			</ul>

			<p>As you can see, these UDFs are very powerful because you can
			concatenate their result with another element (literal, variable or even
			function) and the parameters can be basic elements or expressions. We can
			extend this ensuring that any element or expression of the EL that gives as
			result a string value can be combined with other EL expressions or elements.</p>

			<p>Another very useful feature of EL is the possibility to use <em>KWONLEDGE
			BASES</em> (KBs). A KB is just a set of key values that map (one-to-one) another
			set of values; may be knowledge bases isn't a very appropriate name because
			they are more like translation tables. BibFormat offers tools to create and
			maintain KBs that can be used in the EL afterwards (see chapter <em>KBs
			management</em> in this manual). You can see KB invocation as a special function
			(the syntax for calling it is the same) with name <em>kb</em> and that takes two
			parameters: one for indicating the KB name (BibFormat can handle several KBs)
			and another one for the key value to translate. The result is the mapped KB
			value or an empty string if it doesn't exist as a key value in the specified
			KB. A typical example is when you have months with numbers and you want to
			translate them into month names; you could have a KB that maps all the month
			numbers to month names and then call it like this <code>kb("MONTH", $m)</code>.</p>

			<p>Now let's move to <em>FORMATS</em>. Formats are some <em>EL</em>
			code which is grouped under a label (a name) and that can be used in any other
			EL statement. BibFormat allows the user to define as many formats as he wants
			and identify each of them with a simple name. In few words, formats allow you
			to reuse EL code; within a format you can put any EL code (even other format
			calls) and all the variable values are completely available. Again, a format call in EL follows the same
			convention as functions: the word <em>format</em> followed by the format name (a
			string) between parenthesis. When you call a format is like if the EL code
			define inside that format was pasted, as it is in the place you make the call.</p>

			<p>Example: Imagine you have to write the title of a bibliographic
			records with a certain format, let's say in bold and red; but this formatted
			title you are going to use it in several places. So can take advantages of EL
			formats and define a format called <em>TITLE</em> that contains the code <code>"<font color=\"red\"><b>" $245.b
			"</b></font>"</code>. Once this is done, you could use it to format
			records by printing their title in that way and their author after it:
			<code>format("TITLE") "/" $100.a</code>. The good thing
			is that if some day you decide to change the title formatting you'd only need
			to modify the <em>TITLE</em> format definition and not all the places where you
			show the title.</p>

			<p>At this point, you have seen basic elements and operations with
			EL. You may think that is powerful enough to express your formatting work, but
			there are more complex situations that you'll have to face. We have tried to
			design the EL to be easy enough but with the next advanced structures,
			sometimes, can arrive to be a bit complex.</p>

			<p>All these basic elements and operations are quite OK. But there
			are sometimes where you want to compare expressions and decide what to do
			depending on the result of the comparison. For this purpose, EL has an IF
			statement and a few comparison and logic operators built in (don't forget that
			any functionality needed can be achieved by defining new UDFs; EL gives basic
			operations to provide this possibility). Let's go step by step: First let's
			talk about the set of operators that can be used in a comparison:</p>

			<ol>
			<li>Comparison operators: Equal and non-equal (=, !=). They take
			two operators that have to be strings and produce a logic (true or false)
			value.</li>

			<li>Logical operators: AND, OR and NOT (&&, \|\|, !). All of
			them have to be used over logical values, taking two operators AND and OR, and
			one operator NOT.</li>
			</ol>

			<p>All of them are right associative (except NOT which is unary
			left-associative) and their precedence goes like this (more to less): NOT,
			(EQUAL, NON-EQUAL), (AND, OR). These operators cannot be used anywhere, only
			inside statements that expect a logic value as result, in other words, inside
			condition statements.</p>

			<p>The IF structure is quite easy to learn: First we indicate the
			word <em>IF</em> followed by a condition statement surrounded by parenthesis;
			then a EL statement into braces can be specified, this statement will be
			executed only if the condition was true; optionally, we can add an <em>ELSE</em>
			word followed by another EL statement into braces, that will only be triggered
			if the IF condition was not true.</p>

			<p>Let's have a look at some examples:</p>

			<ul>
			<li>I want the title of a record to appear followed by the
			constant <em>Author:</em> and its author afterwards. But it could be nice if the
			constant string appeared only if the record has author:
			<pre>
			format("TITLE") if($100.a!="") { "Author: " $100.a }
			</pre>
			</ul>

			<p>BibFormat is not only an EL processor. Among others, it contains
			a link solver that contains it's own rule repository in order to be able to
			automatically solve links (see chapter Link solver of this manual). EL has one
			special structure for asking the link solver for some links and including them
			in the formatted version of the bibliographic record. This way links are easy
			to maintain (you modify the rules independently from where the link is being
			used) and as re-usable as formats or UDFs. Links are identified by a label and
			need some information to be passed as parameters; then an EL statement has to
			be specified which will be effective only if the link is solved and inside
			which, you'll have access to an special variable, named <em>LINK</em>, which
			contains the solved link among other information (see chapter Link solver for
			more information about which values are accessible); additionally, an else
			statement can be added (following the same syntax as in the IF construction)
			that will be effective only if the link can't be solved by the Link solver.</p>

			<p>Example:</p>

			<ul>
			<li>We are with our typical example of the simple format
			that contains the title and the author, but now we want the author to be linked
			to the search. Supposing that a this kind of link is already defined under the
			label "AUTHOR_SEARCH" we should proceed like this:
			<pre>
			format("TITLE") "/"
			link("AUTHOR_SEARCH", $100.a)
			{ "<a href=\""$link "\">"$100.a"</a>"}
			</pre>
			</li>
			</ul>

			<p>The next step when talking about EL components is to deal with
			multiple values. Life is no so easy and, of course, and a bibliographic record
			can have more than one author or can have a related document which is in more
			than one format and that has to be linked. In other words, BibFormat supports
			having variables and fields with multiple values (see chapter <em>Mapping input</em>),
			consequently a way of applying an EL statement over all the values of a
			variable or a field would be quite useful. <em>FORALL</em> is our construction!!
			It allows you to specify a variable or a field followed by a EL statement
			(between braces) that will be applied for every value of the variable or the
			field; any reference to the iteration variable inside the <em>FORALL</em> EL
			statement will be related to the current iteration variable value (if you refer
			to a variable that has multiple values outside a <em>FORALL</em> the first value
			is considered). One limitation is that you shouldn't nest <em>FORALL</em>
			statements, in other words, never put a <em>FORALL</em> inside another one. This
			construction let's you also limit the number of times you want to iterate over
			a variable or field by adding a literal with the number of iterations.</p>

			<p>Some examples:</p>

			<ul>
			<li>Let's continue refining our simple format; now we have
			to consider that there can be more than one author for one bibliographic
			record, so we want to show all of them with the link included, of course.
			<pre>

			format("TITLE") "/"
			forall($100.a)
			{
			link("AUTHOR_SEARCH", $100.a)
			{ "<a href=\""$link "\">"$100.a"</a>"}
			}
			</pre>
			</li>

			<li>Although this <em>FORALL</em> construction could seem not
			very useful, it's used a lot when defining formats or behaviors. Quite often
			you will have the case where you want only some EL piece of code to be
			effective if a certain variable or field exist; <em>FORALL</em> can also be used
			in that situation and it has to be said that is the most comfortable way of
			doing it. Imagine the case you want the title, the constant string "Author: "
			followed by the authors of a bibliographic record; but you don't want the
			constant <em>"</em>Author: " to appear if there's no author at all. You could use
			something like this:
			<pre>

			format("TITLE") " - "
			forall($100.a)
			{
			rep_prefix("Author: ") $100.a " "
			}
			</pre>

			As you can see we are
			using a new function: <em>rep_prefix</em>. In fact this is an UDF which prints
			the string passed as parameter only once at the beginning inside a <em>FORALL</em>
			statement. But the interesting thing here is the <em>FORALL</em> application.</li>
			</ul>

			<p>Finally, there's still one EL special function: <em>COUNT</em>.
			Due to certain special situations or strange input data in the variables,
			sometimes is useful to know how many values contain a variable or a field. So
			this function, simply takes a variable or field as argument and returns a
			string with the number of values that contains; if the value returned is 0,
			that means that no value is in the variable, what means that variable doesn't
			exist or there weren't any values mapped from the input.</p>

			<p>Examples:</p>

			<ul>
			<li>As this is the last example, let's do it a bit more
			complicated: Continuing with our very well known simple format, we want all the
			authors of the record appear if there are less than 10, in any other case we
			want only the first one to appear followed by the string "et al.". We'll also
			use a function called <em>GT</em> which returns a non-empty string if the first
			parameter is greater than the second one.
			<pre>

			format("TITLE") "/"
			if(gt(count($100.a), "10")!="")
			{ $100.a "et al." }
			else
			{
			forall($100.a)
			{
			link("AUTHOR_SEARCH", $100.a)
			{ "<a href=\""$link "\">"$100.a"</a>"}
			}
			}
			</pre>
			</li>
			</ul>

R3600/modules/bibformat/doc/admin/guide.html.wmld5b36a574e3cmaint-1.2

guide.html.wmlView Options

R3600/modules/bibformat/doc/admin/guide.html.wml
d5b36a574e3cmaint-1.2

guide.html.wml
View Options