Format statements introduce document metadata into text marked up in HTML. Additional control is provided by {If} and {Or} statements. These concepts are imported from computer programming languages but are no more difficult that formulas in a spreadsheet, which is familiar territory for many non-programmers. The structure of an Excel if expression is the same as Greenstone's: Excel's If( test,value-if-true,value-if-false) corresponds to Greenstone's { If}{ test,value-if-true,value-if-false}. Unlike Excel, in Greenstone such statements are intermingled with HTML-tagged text, and the role of the curly brackets is to allow the runtime system to sift them out. The {Or} statement is logically unnecessary, providing a syntactic convenience in certain situations: everything it can do can also be done with a more verbose combination of { If}s.

In writing, lists are usually organized vertically, so the most commonly customized format statements are for VLists—vertical lists (see Format features in Section 10.4). Here are some common patterns.

If a VList format statement starts with a <td> tag, it is assumed to be a row in a table. Greenstone automatically encloses it with <tr> … </tr> tags and encloses the entire table with <table> … </table>. Basic control over document items is provided by

This generates a two-column table, with a link to the document in the first column and title metadata in the second. The original source document—or anything else—could be added in an extra column:

Note that link, icon, srclink, and so on are actually treated as extracted metadata—they are generated by Greenstone and associated with each document. The Librarian interface presents names for extracted metadata as beginning with the prefix ex. However, this prefix is omitted internally: Greenstone assumes extracted metadata by default when it encounters unqualified metadata names like link, icon, and srclink.

Another pattern introduced in Chapter 10 is the use of image thumbnails instead of the icon that is automatically generated by [ icon]:

Note the similarity with the first of the two examples above. Exactly the same effect can be achieved by replacing the first table cell (i.e., line 1) above by this more complicated version:

In fact, behind the scenes the ImagePlugin sets thumbicon metadata to something equivalent to this expression (it also sets ThumbWidth and ThumbHeight metadata for the thumbnail image). While thumbnail images are common enough to warrant thumbicon metadata as a convenient shorthand, a huge variety of other associated files might be bound to a document, and this more explicit technique shows how to link to such files.

In the excerpt above, the src attribute with value _httpassocdir_/[assocfilepath]/[Thumb] creates a URL for the associated image. The image plug-in sets up the thumbnail using Greenstone's generic mechanism for a document's associated files. The macro _httpassocdir_ gives the name of the folder where Greenstone places associated files (in fact, this is the folder <collectionname>/index/assoc); within this file area, assocfilepath metadata gives the name of the associated-file folder for this document; and Thumb metadata gives the name of the actual thumbnail image. The same pattern can be used to construct < a href=…> hyperlinks to associated files. There is a range of plug-ins in Greenstone that set up associated files following this pattern, varying only the last part: the metadata name (or perhaps explicit filename) used for the actual resource associated with the document.

Another useful pattern encountered in Section 10.4 (Formatting exercise 1) is

The first cell is the same as in the first example above. The second uses the variable numleafdocs in two different roles. Its first occurrence tests whether the variable has a value, in order to determine which of the two branches of the If to take. The metadata numleafdocs is only set at internal nodes of a hierarchy (e.g., bookshelves in a classifier), and gives the total number of leaves below this node, which is printed in parentheses by the second occurrence above. In either case, the title is printed: the extracted title [Title] for internal nodes, which is set to the metadata value corresponding to that node; and the Dublin Core title [dc.Title] for leaf nodes (i.e., documents).

When format statements become overly complicated, they can often be simplified by going back to the source documents and assigning metadata that supports what you want to present. For example, if different types of document need to be presented in different ways (article, paper, book, …), you could define a metadata value, say dc.Format, that specifies the type. If different types are in different folders in the input material, this can be quickly done by assigning metadata in the Librarian interface at the folder level. This metadata is not necessarily presented to the user, rather it is used as internal metadata that helps simplify the logic of If statements.

Greenstone macros control the structure of all Web pages generated; they also provide language-independent interfaces. Figure 12.1 gives an artificial excerpt that illustrates how macros are defined and used. Macro definitions usually comprise a name flanked by underscores, and a definition placed within braces { … }. Lines beginning with the hash character (#) are comments. A second form of definition is for macros with arguments (see below). Macro definitions contain a mix of plain text, HTML, and references to other macros. For conciseness, the definitions in Figure 12.1 are short. In practice they often span 20 lines or more, indented to improve readability. Macros do not contain references to metadata values like [dc.Title], because macro definitions are not bound to particular documents.

Macros are grouped into packages, and an inheritance scheme is used to determine which definitions are in effect at any given time. This allows the content generated for a page to be embedded within a global formatting style. For instance, most pages have a standard header and footer that enclose page-specific content. Figure 12.1 shows a baseline page defined in the Global package, whose _content_ macro is not intended to be seen. It is overridden by the immediately following query package that generates a page inviting users to enter search terms and perform queries.

Macros can include parameters interposed in square brackets between name and content. These are known as page parameters because they control the overall generation of a page, and they are expressed as [ x=y], which gives parameter x the value y. The _header_ macro in Figure 12.1 uses the page parameter l, which determines the interface language. Another parameter (not shown in this example) is v, which controls whether images are used in the interface. A precedence ordering for page parameters is built into the macro language to resolve conflicting definitions.

Figure 12.1 gives versions of the _header_ macro in English, French, and Spanish. They set the parameter l to the two-letter international standard abbreviation (ISO 639), enabling the system to present the appropriate version when the page is generated. If a macro has no definition for a given language, the parameter is simply omitted, which in standard Greenstone produces an English version because this is the most complete and up-to-date language for the interface. However, it is easy to change the default. It is specified in the main configuration file (see Configuration files in Section 11.2) using the cgiarg option, specifying (for French) cgiarg shortname=l argdefault=fr.

The macro language has its own version of the If statement _If_—an example appears in Figure 12.1's _content_ macro. In this case it uses the macro _cgiargqb_ to determine whether to display a normal query box or a large one on the search page. The value of _cgiargqb_ is set at runtime by the Greenstone system; its value is ultimately determined by the user's setting on the Preferences page, which can be controlled through a pull-down menu that offers the choice of query style as single line or large. Choosing large causes the Web page to set the HTML form field qb to large, which in turn leads the runtime system to set _cgiargqb_ to large. Several other system-defined macros have values that are determined at runtime—for example, the number of documents returned by a search. We return to this point below.

The final macro definition in Figure 12.1, _matches_, illustrates the use of arguments. If invoked by _matches_(5), this generates the text 5 document(s) matched your query. An If statement could be added to separate the singular and plural cases, rather than resorting to the clumsy “document(s)” —but that is not the point this part of the figure is looking to demonstrate. Notice the use of _1 _ in the macro definition to refer to the first argument passed in when the macro is invoked. The pattern continues with _2 _ for the second argument (if required), and so on; and _matches_(5,3) would be used for a two-argument macro. It is, however, not normal to call a macro with fixed numeric arguments such as 5 and 3. Values set by the runtime system (such as _numdocs_) or metadata from a document are more common.

Figure 12.1 is artificial in both content and layout. Although macro definitions from different packages can be mixed together in a single file, as here, this is not the norm. Usually, different files control the layout of different pages, such as about.dm, query.dm, and home.dm for the Greenstone About, Query, and Home pages. There are two exceptions to this convention. One is a collection-specific macro file called extra.dm, which contains any macros defined in the Macros section of the Librarian interface's Format panel. Another is the set of macros containing textual language fragments, which are grouped into files by language ( english.dm, french.dm, and so on). In fact, each language has two files, for example english.dm and english2.dm, the former containing phrases used in the core Greenstone system and the latter containing those in auxiliary subsystems. The distinction is made to avoid overwhelming translators and to help them focus on the text used most often.

The standard Greenstone Reader's interface is built entirely out of macros. It is an excellent source of additional examples of how to use them.

Table 12.1 lists three values defined in Greenstone's site configuration file ( gsdlsite.cfg, Section 11.2) that are set as macros _httpprefix_, _httpweb_, and _gwcgi_. The purpose of these values is to map Greenstone into the Web server's space, with increasing levels of refinement. Greenstone is usually installed in a single folder in the file system (say greenstone-2.83), which is mapped to a unique prefix in the Web server's configuration file that is also recorded in _httpprefix_. For example, setting it to /greenstone would be a good choice. If a more up-to-date version of Greenstone were installed later, this could be placed in a new folder on the file system, collections moved across as needed, and the Web server's configuration file altered to map /greenstone to the new location.

The _httpweb_ macro specifies how the root area for supporting files such as images, CSS, and JavaScript in Greenstone is mapped to the Web server's space. By default, the folder web, located in the folder where Greenstone is installed, forms the root, with sub-folders for images, style and script. Continuing the configuration example from before, having set _httpprefix_ to /greenstone, _httpweb_ would need to be set to /greenstone/web. In fact, on this occasion it can be omitted as this is its default value. The macro _gwcgi_ provides the URL for accessing the digital library. The norm is to leave this undefined, in which case, for the configuration being described, the library's URL is  /greenstone/cgi-bin/library.cgi.

These three macros are fundamental to Greenstone's operation, and numerous definitions in the macro files are based upon them. Table 12.2 shows some macros that are often used for defining other macros and in format statements. The upper entries define partial URLs that pinpoint general areas within the installation from which full URLs can be formed. The lower part gives fully formed URLs that can be used directly to link to pages like a collection's Preferences or Query page.

Other macros dictate what goes into pages. We have already seen that the overall structure is controlled by _header_, _content_, and _footer_. Table 12.3 summarizes useful macros that splice in further information, be it graphics, text, or anything else that can be embedded into HTML—such as JavaScript. For example, _pagescriptextra_ is used in the design patterns below to introduce JavaScript functions that extend Greenstone's functionality by improving how items are presented. The lower part of the table gives macros that are set by the runtime system. For example, _navigationbar_ can only be defined once the collection's indexing and browsing structures have been determined.

Another kind of macro definition that is set by the runtime system takes the form _cgiarg…_, where the ellipsis gives the name of an argument in the URL. We met this in Section 10.6 when switching between images and text in a collection of paged images. It is a useful way to incorporate new functionality. There are no setup requirements—nothing has to be done in advance to declare a new variable. Greenstone sets a macro of the form _cgiarg…_ for every CGI argument in the URL, and macro files can immediately start using these to access the variable. As a result, macros can change what is presented to the user. This is how Greenstone was extended to support the display of HTML documents as realistic books (Figure 3.5).

How can you add extra pages to a Greenstone collection? As you already know, the Greenstone home page is created by macros in the file home.dm. It starts with the phrase package home followed by several macro definitions, the most important being _content_, which supplies the page content. There are no definitions for _header_ or _footer_ macros, so the default definitions in the Global package will be used. The end result is to sandwich the new _content_ definition between the standard header and footer (see Section 12.1 for more details). You can repeat this pattern of defining new macro packages and populating them with macro definitions yourself, inventing new package names as you see fit.

We will describe how to add the page in Figure 12.2a, which gives contact details and photos of the three authors of the book, to either a Greenstone digital library site or an individual collection. Figure 12.2b shows the macro file that generates it. It shows the home page of each author as a hyperlink, and each one's e-mail address, hyperlinked using mailto to launch the user's mail client. The telephone numbers are formatted by a Skype plug-in that was installed in the browser used for the snapshot: it links values it thinks are telephone numbers to Skype and automatically dials when they are clicked. (As Figure 12.2a illustrates, it includes heuristics to suppress this for fax numbers.)

These macro definitions are placed in a package called contact, specified in the new file contact.dm. Lines 10–31 define the _content_ macro, which is made more readable (and maintainable) using a set of support macros, defined above it. Points of interest include:

Line 3. The _pagetitle_ macro gives the text that appears in the Web browser's title. It overrides the default defined in the Global package that displays the name of the collection.

Line 5. The _homepage_ macro takes the user's login name as an argument and generates the home page URL in the University of Waikato Computer Science Department.

Lines 7–8. The _email_ macro takes an e-mail name (which does not have to be the same as the user's login name) as an argument and generates a full address. The @ symbol in the e-mail address is specified using its HTML entity form & #64; in an attempt to defeat spammers from automatically ripping this information from the Web page. The _esubject_ macro defines the text How to build a digital library (encoded for inclusion in a URL using %20 to represent spaces) and is paired with the _email_ macro so that if a user clicks on the hyperlink his or her e-mail client will automatically populate the subject line with this text.

To link this new page into the digital library, two things must be done. First, the new macro package must be made visible to the Greenstone software. Second, one or more links to it must be embedded into an existing page. Macro definitions can be added to collections by placing them in a file called extra.dm in the collection's macros folder or by pasting them into the Macros tab of the Librarian interface's Format panel, which accomplishes exactly the same thing. This file is read automatically. Alternatively, the file contact.dm could be placed in Greenstone's top-level macros folder, in which case its name must be added to the main configuration file (Section 11.2; see also the end of Section 10.4). It is a good idea to use separate files for significant changes, making things easier to manage in the long run.

The second step, adding a link, can be done using the _httppagex_( x) macro in Table 12.2. For instance, this line could be added to the _content_ macro in home.dm:

This would make the new page with contact details available from the digital library's home page.

As noted, Greenstone automatically picks up the file extra.dm in a collection's macros folder and associates it with that collection. This is also true for other macro files. If desired, you can copy standard files such as query.dm and about.dm into the collection's macros folder and customize them: the definitions included there will override the site-wide definitions. (Note, however, that Greenstone only picks up standard macro files whose names appear in the main configuration file.) If you wanted to put the same information on the About page of an individual collection, you could copy about.dm into the collection's macros folder and add the above line to its _content_ macro. Delete all the other macros, because they are no different than the original definitions.

Format statements allow you to manipulate how things are presented. However, there are limits to what they can accomplish. For example, although they can include conditional tests ( If statements), they cannot perform numeric calculations or manipulate strings. If you want to add two metadata values together and test the result, you will need to use JavaScript. This design pattern illustrates the use of JavaScript through two examples that take raw data and display it on the Web page in a more readable form.

The first shows file sizes using KB and MB for large values. The second displays dates in a way that respects local conventions, determined by the locale set in the user's operating system. Both use the JavaScript document.write("….") function to inject fresh text at that point into an HTML document. JavaScript must be embedded in <script>…</script> tags to ensure that it is not interpreted as HTML. The whole thing can be placed directly into a format statement, but as soon as the JavaScript exceeds a couple of lines (which is invariably the case) it makes more sense to define a function, place it in a macro file, and call it from within the format statement using JavaScript. Greenstone already embeds a set of JavaScript functions into the pages generated. Extra functions can be included in this set by defining the macro _pagescriptextra_ (listed in Table 12.3), and that is what we use here.

Figure 12.3 defines two functions to accomplish these tasks: format_filesize() on lines 5–17 and format_date() on lines 19–29. The snapshot associated with the next design pattern (Figure 12.4a) shows the result. In the snapshot, a video is playing, and in the last two lines of the metadata tabulated below you can see the file size of the video, 7 MB (rounded to the nearest megabyte and hyperlinked to download the file), and its release date, Wednesday, 20 December 2006, which has been reformatted from the internal Greenstone value of 20061220. The format statement that produces the “Download size” table cells, for instance, simply calls the format_filesize() function in JavaScript:

Points of interest in Figure 12.3 include

Lines 10, 13. Some ambiguity surrounds the values used for kilobytes and megabytes. Is a kilobyte 1000 or 1024 bytes? Is a megabyte 1000 or 1024 kilobytes? We have used 1024 here.

Lines 21–23. The built-in JavaScript function substr() extracts a substring: the first argument is the start position and the second is the length of the substring.

Lines 25–26. The built-in JavaScript Date object has a member function toLocaleDateString(), which converts dates to the appropriate format.

JavaScript uses curly braces { … } for grouping, but they are reserved characters in Greenstone's macro language. Consequently they are “escaped” by prefixing them with a backslash () in order to pass through unaltered to the Web browser's JavaScript interpreter. Underscore is also a reserved character, and is also escaped (for example, in format\_filesize).

Figure 12.4a demonstrates a video collection whose DocumentText format statement has been customized to stream video into the open source Flowplayer, a Flash-based utility giving a similar experience to YouTube. Over a dozen configuration parameters are needed to set this up, and they would be unwieldy and difficult to manage in a format statement. They can be more conveniently laid out in a macro definition (and decomposed into smaller macros, if desired). But there is a snag—it is necessary to refer to metadata values associated with the video document and, as mentioned previously, this cannot be done directly in macro files.

Figure 12.4b shows how to achieve the best of both worlds by defining a macro to which the metadata values are passed as parameters. It generates the HTML <object> … </object> element shown in Figure 12.4c, which is exactly what is needed to play the video. Most of the code in Figure 12.4b (lines 8–32) defines a Greenstone macro called _videoplayer_ that generates this HTML. This macro has two arguments, _1_ and _2_; they are used on line 28 and represent metadata values that are needed to construct the video file's URL. The macro is called from the format statement as follows:

The arguments are two metadata values, [ assocfilepath] and [ streamablevideo]. The former is defined for any document that has associated files (such as the video) and provides the name of the folder in which they are stored—in fact, we encountered it in the thumbnail format statement in Section 12.1. The latter metadata is generated by the plug-in that processed the video file, and provides its filename within the associated file directory. These two metadata values are combined with the _baseurl_ macro defined in Figure 12.4b (line 3) to yield the complete URL of the video. This is then set as the value of the videoFile configuration field in the HTML <object>. The result is the line near the end of Figure 12.4c that reads

This macro file is not only easier to create and maintain than embedding all this directly in a format statement, but is in a convenient form to share with other collections and others with Greenstone installations.

When a Web page is rendered in a browser, it takes the form of a tree structure in memory that encapsulates the sequencing and nesting of HTML elements. This tree forms an important component of the Document Object Model (DOM), and can be manipulated with JavaScript to dynamically alter what the Web browser displays, usually in conjunction with associated cascading style sheets (CSS). The term “tree” is used in its computer science sense to refer to an abstract structure that is hierarchically composed (as in Figure 11.1).

Figure 12.5 shows an abridged version of the DOM for the introductory HTML example in Chapter 4 (Figure 4.6). HTML elements map to nodes in the tree: nested elements are children of the parent tag that encloses them; sequential elements (such as the < title> and two < meta> tags at the top left) are siblings, ordered left to right at the same level, with the same parent. Text within an element, such as text to be italicized, also forms a node, shown in the figure as #text.

DOM, a World Wide Web Consortium specification, is the key to dynamic HTML. In addition to its hierarchical structuring of HTML elements, it includes methods to access the width and height of the browser window and to determine whether or not x and y scrollbars are in effect and what their positions are—and it includes ways of changing these values. What we see here is just the tip of the iceberg.

As we have seen, some nifty effects can be created using DOM manipulation. They give Web pages an interactive feel—for example, users can open and close sections of tables without reloading the page. But these adjustments can use only information stored in the page when it was first generated or information provided by the user when interacting with it. AJAX adds the ability to communicate with the server that produced the page. This greatly extends the range of what is possible:

For example, AJAX could be used to support a more responsive form of query refinement or faceted browsing, avoiding the expense of reloading pages when users narrow the focus of their search. Less data is transmitted overall because the server need only provide information about matching documents that have not already been sent.

Our first example below returns to the Depositor, Greenstone's institutional repository system, and shows how AJAX is used to support the checksum feature. A surprisingly short piece of JavaScript is needed to effect such a radical change in how the Web is used. The second example is a digital music stand that is integrated into Greenstone. Rather than going into technical details, we focus on the bigger picture and describe the role that AJAX plays.

Our solution has been to create a new version of the software with the express intention that it constitute a framework for innovative research. We named it Greenstone3 to differentiate it from the production version described in this book, retrospectively dubbed Greenstone2 to coincide with the version number we had already been using. Extensive backward-compatibility was built in right from the start—Greenstone is the digital analog of the physical library building, and you don't have to rewrite the books or card catalogs when libraries move to new premises! Consequently, Greenstone3 can run collections built for earlier versions of Greenstone without any modification whatsoever. Other goals include different levels of customization, software modularity, dynamic services, distributed architecture, future compatibility, integrated documentation, self-describing modules, and integration into the computing environment.

Greenstone3 is a service-based architecture. A network of modules that provide these services communicate with each other via XML messages, which can optionally be set up to communicate in a distributed fashion using the Simple Object Access Protocol (SOAP) described in Section 7.4. Messages can be customized at any point using XSL transformations (mentioned in Section 4.4). Dynamically loadable Web services are layered on top of the communication channel. A “describe-yourself” call is a mandatory fixture that allows services to be discovered in a heterogeneous world of communicating applications; it also assists future compatibility.

From a research viewpoint, Greenstone3 has been a resounding success. We have used it to investigate such things as dynamic text mining, query visualization, alerting services, spatial searching, ontologies, and many more. We are capitalizing on the contents of digital libraries to automate the production and delivery of practice exercises for students who are learning English. We are exploring the role of AJAX in digital libraries to create richly interactive interfaces—for example, it is used for the Koru knowledge-based information retrieval system described in Section 9.3. This research tests the ability to provide future compatibility, because the rise of AJAX postdates Greenstone3's design.

Greenstone3 is an open source project and is under active development. However, demands from users for further enhancements to Greenstone2 have drawn more heavily on our time than we had foreseen when we embarked upon the re-implementation.

Greenstone3 was envisaged purely as a research framework: its use would require IT skills. It has achieved many of its goals—for example, it is now far easier for external projects to build upon the digital library core, as in the examples mentioned above. By and large, these external projects develop new or enhanced functionality that augments the document searching, browsing, and access already provided. Some projects, notably ones utilizing AJAX, produce new Web-browser interfaces that issue requests to the digital library infrastructure and manipulate the XML messages that are returned. Others develop standalone applications (using the programming language and toolkit that suit their needs) that integrate with the infrastructure at as deep a level as required. In applications that run on the same computer as the digital library system, the communication protocol can be bypassed in favor of direct procedure calls using an application programming interface.

We have found that maintaining two independent versions of the software—in particular, ensuring backward-compatibility when new and enhanced features are still being added to Greenstone2—stretches our resources too thinly. Consequently, we are now developing Greenstone3 to the point that, by default, users will find its installation and operation indistinguishable from those of Greenstone2. For example, the original Greenstone3 was installed by obtaining the code from a software repository and compiling it for your machine. Now, however, it uses Greenstone2's cross-platform installation wizard, which allows end users to install it easily. Greenstone's interface translations into different languages have been migrated to Greenstone3. Enhancements have been made to the default services so that what readers see through a Web browser can be matched, step for step, with what they already experience with Greenstone2. Automated regression testing helps minimize the problem of checking for undesired side effects of recently committed changes. Workshop and tutorial material have been tested to ensure that they work equally well with Greenstone3.

In terms of ingesting documents into a collection, we now utilize Greenstone2's exporting ability, which was originally designed to facilitate interoperability, to output to the registered METS profile utilized by Greenstone3. Greenstone2's collection-building code was upgraded to parse Greenstone3 configuration files, which allows the Librarian interface to operate equally well with either version. Overall, this pattern of gradually moving the two code bases closer together seems to be working well. For example, the realistic book facility illustrated in Figure 3.5 was originally planned for Greenstone3 alone. However, it turned out that an extra optional CGI parameter could be introduced into Greenstone2 that made it generate XML in the Greenstone3 document format, which allowed the work to be “back ported” to Greenstone2 and used in any existing collection.

There is one area where Greenstone3 still differs radically from Greenstone2, and that is in the format statements and macro language described in this chapter. They are based on XSL transformations, a mechanism that is more powerful but, unfortunately, even more difficult to use. However, XSL transformations can more readily support automatic construction of format statements and macros. We are designing an interactive editor for Greenstone digital library pages that will eventually render format statements and macros obsolete—much to the relief of users. However, this is a major undertaking, which is why we have based this book on Greenstone2 rather than the newer version. From the user's point of view, all other changes when upgrading to Greenstone3 will be invisible. In fact, you might like to download it (from www.greenstone.org/greenstone3-home) and see for yourself.

Looking to the future, our overarching goal is to broaden the realms in which digital libraries are utilized. We are now focusing on multimedia and enhancing Greenstone to incorporate content-based analysis for images, audio, and video, with particular specializations to newspapers, music, and maps. We foresee an extension mechanism as the key to managing this ever-widening and diversifying spectrum of research-inspired functionality, and we will produce an administration tool that facilitates general maintenance of an installation along with the ability to download and incorporate particular extensions.

We believe that digital libraries are a key aspect of civil society. Their importance grows with every passing day. People are beginning to recognize the dangers of relying on one or two giant universal search engines for access to our society's treasure-house of information—which constitutes our entire literary, scientific, and cultural heritage. What the world needs, we believe, are focused collections of information, created and curated by people with an intellectual stake in their contents. We mean digital libraries, built by librarians!

We are proud and very pleased that the Greenstone Digital Library Software is playing a part in this international endeavor. Year by year, its technical strength grows and its rate of adoption increases. Yet this success has come at a price: although we are at heart a research group, we feel obliged to provide support for the growing user base of our production system—particularly in developing countries. This final section has given an insight into the development processes of the Greenstone software and conveyed our approach to the difficult problem of reconciling the production values of stability and reliability with a vigorous research framework of innovation in digital library software.