Dynamic XML on the Australian e-Humanities Gateway

Sten Christensen, Humanities Librarian, University of Sydney Library [HREF1] , NSW, 2006. Email: s.christensen@library.usyd.edu.au

Michael Roper, Programmer, SETIS [HREF2], University of Sydney Library, Email: mroper@library.usyd.edu.au

Abstract

The Australian e-Humanities Gateway [HREF3] was set up under the auspices of the Australian e-Humanities Network which is a partnership between the Australian Academy of the Humanities [HREF4], the University of Sydney Library, the Research Institute for Humanities and Social Sciences (RIHSS)[HREF5] and the The Centre for Literary and Linguistic Computing (CLLC) -University of Newcastle [HREF6].

The Gateway has been designed as a reference point for those involved in or seeking information about projects and events concerned with the use of digital resources in humanities disciplines in Australia. Its central component is a searchable database containing details of current projects in the e-Humanities field across a broad spectrum of disciplines in Australian universities. This paper breifly describes the Gateway, its history and some of the technology behind it.

Introduction

The Australian e-Humanities Gateway was established as a reference point for those involved in or seeking information about projects and events concerned with the use of digital resources in humanities disciplines in Australia.

It is an initiative of the Australian e-Humanities Network, a group funded by the Australian Research Council, including representatives from the Australian Academy of the Humanities, the University of Sydney and the University of Newcastle, in order to develop links between current activities in the e-Humanities field and form bases for future projects.

Original Set up

The Gateway is made up of a number of components including an online forum for those interested in the area of "digital humanities", a news and events section, information on training offered and information on "going digital". The central component of the Gateway is a searchable database containing details of current projects in the e-Humanities field across a broad spectrum of disciplines throughout Australia. Individuals are encouraged to submit details of their project for inclusion in the database, acceptance being subject to a review process by the Network.

Originally the data was stored as a "flat XML file using a customized version of the Dublin Core DTD for "Expressing Simple Dublin Core in RDF/XML" (Beckett, Miller, and Brinkley 2002) [HREF 7]. This was indexed and made searchable via the OT (Open Text) search facility available in the Scholarly Electronic Text and Image Service of the University of Sydney Library

Review Process.

All projects in the database are peer reviewed. Anyone can suggest a project and information is received either via a form on the Gateway site, by email or "word of mouth". Projects for consideration are referred to the Australian Academy of the Humanities for review that, if accepted, will then be entered into the database. At the time of writing the e-Humanities Network is working on a draft collection policy.

New Structure and how it works

The second phase of the Gateway involved redevelopment the database to achieve the following:

1. Faster information retrieval
2. Remote data entry
3. Creation of an extensible, modular base

A 4 tier web architecture was developed to meet these goals. The first tier is the Apache web server. The second tier is AxKit, an Apache server application. The third tier consists of a number of Perl objects that access the fourth tier: a MySQL database. AxKit uses XML in the form of XSP (eXtensible Server Pages - a way of dynamically generating XML), XSLT, and Taglibs to respectively specify the content, style, and logic of the application. It then co-ordinates the interaction of these three aspects of the application using a simple pipeline processing model discussed below.

Example of the data output process:

The data sits in a MySQL database. All processing is conducted on a pipeline model, a process where by " … each stage has a specific purpose and can be designed and tested independently of others" (Slaymaker 2002)[HREF8]. Processing is handled by AxKit using mod perl that is either embedded in the xsp page or by snippets of xml logic in the form of a taglib which is .."a way of encoding logic and dynamic content in to pages without including raw "native" code (Perl, Java, COBOL; any of the popular Web programming languages) in the page" (Slaymaker 2002)[HREF8]

When searching the database the user completes a web form encoded in xsp (The user does not see this). The form is then passed through the Apache server and once submitted is then processed by AxKit which calls for scripts handled by the taglibs and transformations handled by the use of eXtensible Style Sheets Transformation (XSLT), a language for transforming XML documents (W3C 2003)[HREF9]

Diagram of the query process and sample code

<?xml-stylesheet href="NULL" type="application/x-xsp"?> <?xml-stylesheet href="/stylesheets/dr_result_item.xsl" type="text/xsl"?> <xsp:page xmlns:xsp="http://apache.org/xsp/core/v1" xmlns:param ="http://axkit.org/NS/xsp/param/v1" xmlns:dr="http://ehum.library.usyd.edu.au/xsp/taglibs/digitalresource/v1" language="Perl"> <page> <dr:selectbyid> <dr:id_val> <param:id/></dr:id_val> <dr:user>publicusername <dr:password>publicpassword</dr:password> </dr:selectbyid> </page> </xsp:page>

The results are then passed back as xsp pages (mainly taglibs) again transformed using XSLT and passed to the client through the Apache server.

Input of data is handled much the same way however authentication is more of an issue and is handled by Apache AuthCookie , a standard mod-perl authentication module.

The Pipeline Process

The pipeline processing model that AxKit uses is advantageous for a number of reasons. Firstly it is easier for someone from a non programming back ground to understand what is happening. Secondly, the process can be broken up into stages and these can be changed to suit our requirements. By separating the content from the style and the programming logic we can maintain the same data structure yet change the process at certain points should we, for example, want to change the way we out put the data.

The Dublin Core