Update of Humanities Sites

There is basic table code in some of the pages which is not being rendered, so I dug out some of my old XSLT for tables from ACH, and passed it over to Stew.

Then we got on to dealing with some annoying sorting issues. Names (of streets, people etc.) are sorted in a crude alphabetical manner, so (for instance) a name beginning with "St." sorts after "Soper" instead of before it. People's names are sorted based on first name.

As far as the people are concerned, the fix has to be made in the data, because there's no algorithm that can determine how to break up a name for searching. Melanie will add a <reg> element to all <persName> elements, and we'll sort on that. Before that could happen, though, we had to make <reg> available in the schema, so we had to retrieve Eric's ODD file and modify it to re-include that element, which he'd removed from the core module. That's now done, so Melanie can start adding <reg> elements.

For place names, the solution should have been simple enough, but we hit three major limitations: first, we can't use XSLT 2.0 because we're running under PHP, which relies on xsltproc; second, in many cases the separation of concerns is rather broken, because XQuery is spitting out HTML directly instead of there being an intermediary XSLT process; and third, it seems to be impossible to pass custom XQuery functions (as opposed to plain inline code) into eXist through the mechanism PHP is using, so an XQuery hack is unworkable.

The only practical solution was to modify the data, which in this case is a large non-TEI file which indexes places against coordinates on the map (INDEX1.xml). I wrote some XSLT 2 to process this file locally, in order to add a <sortKey> element for each <title> element, in which any instances of "The " at the beginning are moved to the end, "St. " is expanded, and the whole string is upper-cased. These are now hard-coded into the data, and are being used to sort the names. They're still displaying in their normal form ("St. Vedast"), but they're sorted based on the key ("SAINT VEDAST").

Working with the PHP interface is more difficult than working in Cocoon, because you can't easily hack into the middle of a pipeline and look at what you're getting; the XQuery and XSLT processing all take place inside a single PHP file, rather than a true pipeline, so it's harder to see what's happening in the middle. On balance, having some experience with both approaches, I'd say the Cocoon system is far superior, especially as it allows you to choose your XSLT processor at any point in any pipeline, so we can hook in Saxon 8 for XSLT 2 files whenever we need to.

Me too for this post.

Melanie asked about getting rid of extraneous spaces following instances of names in references, for example in HENS2.xml:
<ref type="internal" target="render_page.php?id=HENS2&n=12"><name type="person" key="ALLE2">Edward Alleyn</name></ref>

After much struggle by me and Martin looking through the XSLT, the php XQuery we eventually concluded that the problem must be a bug in the php or libxsl library. We were able to solve the problem by adding
<xsl:strip-space elements="tei:ref"/>
to render_page.xsl

I copied the front-end files for Agenda from the lang02 account to the lang account, checked the permissions were identical and a select sample of the actual files were identical.

The instance on lang02 works fine, except when there is a conflict with a current session from the lang account - in which case a php Warning of access denied to the session tmp file on the server appears on the page. The occasional problem is likely due to reuse of session variables arising from testing, and unlikely to occur in normal use - the lang02 instance hasn't failed before.

The instance on lang is suffering from something else: the index file includes a login file which creates a new session, logs in to the database, authenticates the user and populates the session array, then calls the agenda.php page. The agenda.php calls new session and creates a new db object (just as the instance in lang02 account does). However the difference is that the SESSION array has no values in the lang account, but does in the lang02 account. With no SESSION values, virtually none of the GUI of the agenda page is displayed.

After much testing and conversations with Clifton, I wrote to sys-admins to see if they could report anything about the lang account that might explain its behaviour, or anything about the php service that might explain any of the behaviour we're getting.