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
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.