Scandinavian-Canadian Studies

For light relief, added the following tweaks to the metadata display for articles:

• 0.7 opacity. This allows the map graphic to show through a little, and it works on Opera and Firefox (IE7 doesn't seem to support it).
• Rounded top corners on the tabs. This is CSS3 which isn't yet implemented, but FF has a -moz- prefixed version which works, and apparently Webkit does too. Works on FF.

Worked on the issue described in the preceding post. After several hours, I finally figured this one out: the problem was in the ajax.js library (or at least, it was possible to solve it by tweaking that library -- not actually the same thing!).

This library originally used encodeURIComponent() all over the place to prepare strings for submission through HTTP to the server, for XQuery searching; however, although this worked on Mustard with an older version of Cocoon, the net result on the Lettuce setup was to encode the UTF8 octets instead of the Unicode characters. Replacing encodeURIComponent() with escape() seems to have solved this problem, but it's a bit unsatisfactory, because it's not clear what lies at the root of the difference between the two situations. Both documents seem to be served in exactly the same way with the same headers. The escape() function may not work as expected with characters above 255. Nevertheless, we have a handle on the issue now.

This is an important breakthrough, because it means we can now go ahead and port other projects to the new Lettuce setup (including the Mariage project and the Moses dictionary). Both of these require working Unicode searching, so their ports were stalled until the problem was fixed.

Completed 11/01/07: Page was not retrieving any data at all; fixed that, but then I was faced with the same accursed character encoding problem as previously, with the author name "Jääskeläinen". The name should be converted to url-encoded form for submission to the XQuery, but the encoding process seems to go wrong; what's submitted is not what we would expect, and not what we get on the old Mustard setup. This is annoying; spent an hour trying to debug it, but no joy. I'll have to come back to this.

This is the plan worked out with Greg to handle the moving of ScanCan from the old to the new eXist:

1. DONE: Get a scancan user created on the TAPoR system.
2. DONE: Put the project materials into scancan's home directory, in a subdir called webapps.
3. DONE: Set up a sitemap system so that cocoon/projects/scancan/ brings up the site.
4. Fix outstanding bugs which are not working in the new system. (Tasks will be created for these.) Meanwhile, update both eXist databases with any new articles which are marked up, so the old site stays current.
5. Once the new system is working completely, have sysadmin create a virtual host for it (http://scancan.uvic.ca/)
6. Once the virtual host is working, take down the old site, and replace it with a redirect through its sitemap pointing to the virtual host.

This will make it easy for us to test out different Cocoon/eXist setups using the same materials and data, and yet keep a steady URL functioning all the time.

Spent some time preparing a new branch of ScanCan which will work on the new version of Cocoon/eXist on the Lettuce server (which uses eXist 1.1.1). Reasons for porting the project include:

1. This eXist version has KWIC-style search results, which will make implementing a decent search page much easier.
2. It handles large and complex documents.
3. It has range indexes which will speed searches and queries.

I made required changes to the XQuery pages (mainly namespace URLs and a change to a key function name), and I'm currently waiting for Cocoon to be functional before I can test the results; there are other changes that may need to be made, but we won't know until we can test.

Cleaned up and tweaked the final code, and changed the XML links on the site itself so that P5 is shown instead of P4. Had some back-and-forth with the TEI list about how to encode email addresses (there is no formal method in P5), and reported a bug in one of the TEI conversion stylesheets to James Cummings.

I was initially trying to create an xmlns attribute on the root element. This turns out to be the wrong approach. I found confirmation of this on the mulberrytech xslt list and xslt FAQ:

"What you can't do is to use xsl:attribute name="xmlns:xyz". Namespaces are not attributes."
http://www.stylusstudio.com/xsllist/200501/post30340.html

"xmlns is NOT an attribute"
http://www.stylusstudio.com/xsllist/200408/post50470.html

"namespace attributes show up on the namespace axis, not on the attribute axis."
http://www.dpawson.co.uk/xsl/sect2/N5536.html#d6682e2140

Jeni Tennison suggests that
[quote]
To create an html element with no prefix and in the XHTML namespace, you need to declare the XHTML namespace as the default namespace within your stylesheet:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/1999/xhtml">
[/quote]
http://www.dpawson.co.uk/xsl/sect2/N5536.html#d6682e1669

Following this approach, I added the TEI namespace to the root of the stylesheet. Initially, I figured this wasn't working (looking at the document in Firefox, as it was rendered by Cocoon), and I hacked around for ages trying to figure out why there was no xmlns attribute; eventually I realized that you have to view the source of the page to see it, because in its default rendering of an XML document with no style, Firefox suppresses the xmlns attribute!

Worked all day to write XSLT to convert the P4 in this project to P5. There are two purposes to this:

1. Provide P5 source XML on the site, for future-proofing.
2. Create P5 articles we can use when working on a future publishing project.

Began by looking at the sample fragments on the TEI Wiki; their approach is to string together lots of tiny stylesheets which each deal in detail with one item or element. That's too complicated for our situation, where our P4 is quite simple.

Built my own stylesheet from scratch, and finally got all articles validating against a P5 schema created from ROMA. In the process I found and fixed some inconsistencies in the original article markup (mainly ambiguous date formats).

Then I added a pipeline to the sitemap to generate the P5 output for any article. All works OK, except that the final stage in the pipeline, which should add an xmlns attribute to the root element, just doesn't work. I've read around all the relevant lists and sites, followed every suggestion I can find, and tried both XSLT 2.0 and 1.0, but nothing seems to work; there's just no way to add that xmlns attribute to the root of the document. I'll have to post a couple of questions on the gmane XSLT list and on the TEI list and see if anyone can come up with an answer. But this is quite a minor problem.

Next, we add links to the site to view the P5, and test conversion of the teiCorpus document for a full volume to P5.

Set up the blog for ScanCan. I'm the only member at the moment; next time I meet with John Tucker I'll see whether he wants to post as well.