Index: /documented-examples/trunk/gsarch-e/resources/collectionConfig.properties
===================================================================
--- /documented-examples/trunk/gsarch-e/resources/collectionConfig.properties	(revision 36474)
+++ /documented-examples/trunk/gsarch-e/resources/collectionConfig.properties	(revision 36475)
@@ -13,7 +13,7 @@
 description1=<h3>How the collection works</h3><p>The Greenstone Archives collection uses the <i>Email</i> plugin, which parses files in email formats. In this case, there is a file per month per mailing list, and each file contains many email messages. The <i>Email</i> plugin splits these into individual documents, and produces <i>Title</i>, <i>Subject</i>, <i>From</i>, <i>FromName</i>, <i>FromAddr</i>, <i>Date</i>, <i>DateText</i>, <i>InReplyTo</i>, and optionally <i>Headers</i>, metadata.</p>
 
-description2=<p>The collection configuration file, <tt>etc/collectionConfig.xml</tt> specifies &lt;importOption name="groupsize" value="200"/&gt;. This groups documents together into groups of 200. Email collections typically have many small documents, and grouping them together prevents Greenstone's internal file structures from becoming bloated and occupying more disk space than necessary. Notice that the <i>Email</i> plugin first splits the input files up into individual Emails, then <i>groupsize</i> groups them together again. This allows the collection designer to control what is going on.</p>
+description2=<p>The collection configuration file, <tt>etc/collectionConfig.xml</tt> specifies <i>&lt;importOption name="groupsize" value="200"/&gt;</i>. This groups documents together into groups of 200. Email collections typically have many small documents, and grouping them together prevents Greenstone's internal file structures from becoming bloated and occupying more disk space than necessary. Notice that the <i>Email</i> plugin first splits the input files up into individual Emails, then <i>groupsize</i> groups them together again. This allows the collection designer to control what is going on.</p>
 
-description3=<p>The <i>indexes</i> line specifies 3 searchable indexes, which can be seen by clicking beside the word "Messages" on the <tt>search page</tt> to reveal a drop-down menu. The first (called <i>Messages</i>) is created from the document text, while the others are formed from <i>From</i> and <i>Subject</i> metadata.</p>
+description3=<p>The <i>indexes</i> line specifies 3 searchable indexes, which can be seen by clicking beside the word "Messages" on the <a href="library/collection/gsarch-e/search/TextQuery">search page</a> to reveal a drop-down menu. The first (called <i>Messages</i>) is created from the document text, while the others are formed from <i>From</i> and <i>Subject</i> metadata.</p>
 
 description4=<p>There are three classifiers, based on <i>Subject</i>, <i>FromName</i>, and <i>Date</i> metadata. The <i>AZCompactList</i> classifier used for the first two is like <i>AZList</i> but generates a bookshelf for duplicate items, as illustrated <tt>with classifier browser CL1</tt>. This is represented by a tree structure whose nodes are either leaf nodes, representing documents, or internal nodes. A metadata item called numleafdocs gives the total number of documents below an internal node. The format statement for the first classifier, called <i>CL1Vlist</i>, checks whether this item exists. If so the node must be an internal one, in which case it is labeled by its <i>Title</i>. Otherwise the node's label starts with the <i>Subject</i> which links to the document, then gives <i>FromName</i> metadata, with a link to "Search by Sender", followed by the <i>DateText</i>.</p>
Index: /documented-examples/trunk/isis-e/resources/collectionConfig.properties
===================================================================
--- /documented-examples/trunk/isis-e/resources/collectionConfig.properties	(revision 36474)
+++ /documented-examples/trunk/isis-e/resources/collectionConfig.properties	(revision 36475)
@@ -37,5 +37,5 @@
 description1=<h3>How the collection works</h3><p>The collection configuration file, <tt>etc/collectionConfig.xml</tt> specifies the ISISPlugin plugin, which processes CDS/ISIS databases. These databases have several files, but ISISPlugin uses just three: CDS.fdt (where CDS is the name of the database), containing the field names used in the database, CDF.xrf (a cross-reference file), and CDS.mst, containing the actual records. Whenever ISISPlugin encounters an ".mst" file, it looks for the corresponding ".fdt" and ".xrf" files. In this case the plugin has been given an <i>input_encoding</i> argument because some entries in the database contain extended characters (in a form that was used in early versions of the DOS operating system). It has also been given a subfield separator argument, whose purpose is explained below. The <i>-OIDtype incremental</i> plugin option was used to give identifiers that are consistent across different operating systems (which may not happen with HASH identifiers), so that we can link to a document in this description.</p>
 
-description2=<p>Like the <i>bibliography collection</i>, this collection incorporates a <tt>form-based search interface</tt> that allows fielded searching. This is specified by the line <i>format SearchTypes "form,plain"</i> in the configuration file; the <i>plain</i> argument ensures that there is a plain textual full-text search feature as well (which can be selected from the <tt>Preferences</tt> page). The <i>&lt;importOption name="groupsize" value="100"/&gt;</i> line in the <tt>collectionConfig.xml</tt> file puts documents together into groups of 100 (as explained in the <i>bibliography collection</i>).</p>
+description2=<p>Like the <a href="library/collection/bibtex-e/page/about">bibliography collection</a>, this collection incorporates a <a href="library/collection/isis-e/search/FieldQuery">form-based search interface</a> that allows fielded searching. This is specified by the line <i>format SearchTypes "form,plain"</i> in the configuration file; the <i>plain</i> argument ensures that there is a plain textual full-text search feature as well (which can be selected from the <a href="library/page/pref">Preferences</a> page). The <i>&lt;importOption name="groupsize" value="100"/&gt;</i> line in the <tt>collectionConfig.xml</tt> file puts documents together into groups of 100 (as explained in the <a href="library/collection/bibtex-e/page/about">bibliography collection</a>).</p>
 
 description3=<p>Some fields in CDS/ISIS databases have subfields. For example, in this case the <i>Imprint</i> field has subfields <i>Imprint.a</i> for place, <i>Imprint.b</i> for publisher and <i>Imprint.c</i> for date. For each field and subfield, ISISPlugin generates a metadata element -- in this case there will be metadata called <i>Imprint^a</i>, <i>Imprint^b</i> and <i>Imprint^c</i>. (There could be a field called just <i>Imprint</i>, although in this case there is not.) ISISPlugin also generates a metadata element called <i>Imprint^all</i> that gives all subfields concatenated together, separated by the character string that was specified as a plugin argument (in this case ", ").</p>
@@ -43,5 +43,5 @@
 description4=<p>The designer of this collection has decided to create searchable indexes on all the <i>^all</i> metadata fields, as well as one on <i>text</i> which makes the raw records searchable too. Of course, the designer could have created searchable indexes on any of the subfields instead -- or as well.</p>
 
-description5=<p>There are two browsing classifiers, an <i>AZList</i> based on <i>Title</i> metadata and an <i>AZCompactList</i> based on <i>Keyword</i> metadata. Recall that the <i>AZCompactList</i> classifier is like <i>AZList</i> but generates a bookshelf for duplicate items. The <i>VList</i> format specification applies to both the search results list and the <i>Title</i> classifier, while the <i>CL2VList</i> puts the number of documents associated with each keyword as described in the <i>MARC example collection</i>. In Greenstone, and in CDS/ISIS, any metadata item can have several different values. The <i>VList</i> specification <nobr><i>sibling(All'; ')</i></nobr> gathers together all the values, separated (in this case) by semicolon.</p>
+description5=<p>There are two browsing classifiers, an <i>AZList</i> based on <i>Title</i> metadata and an <i>AZCompactList</i> based on <i>Keyword</i> metadata. Recall that the <i>AZCompactList</i> classifier is like <i>AZList</i> but generates a bookshelf for duplicate items. The <i>VList</i> format specification applies to both the search results list and the <i>Title</i> classifier, while the <i>CL2VList</i> puts the number of documents associated with each keyword as described in the <a href="library/collection/marc-e/page/about">MARC example collection</a>. In Greenstone, and in CDS/ISIS, any metadata item can have several different values. The <i>VList</i> specification <nobr><i>sibling(All'; ')</i></nobr> gathers together all the values, separated (in this case) by semicolon.</p>
 
-description6=<p>The <i>DocumentContent</i> format specification incorporates the same mechanism for hiding and showing raw records as explained for the <i>Bibliography collection</i>, using the <i>DocumentHeading</i> to show the formatted record and <i>DocumentText</i> to show (or hide) the original database entry.</p>
+description6=<p>The <i>DocumentContent</i> format specification incorporates the same mechanism for hiding and showing raw records as explained for the <a href="library/collection/bibtex-e/page/about">Bibliography collection</a>, using the <i>DocumentHeading</i> to show the formatted record and <i>DocumentText</i> to show (or hide) the original database entry.</p>
