HCMC Blogs

The XUpdate task seemed to run pretty well, except for one file, B635AD04.xml, which has a whole sequence of transcribed enclosures; it seemed to lost its marbles on that one, so I fixed it myself. 1258 files were changed. I've now updated the XSLT and CSS so that the right bits appear in the right places.

Pat has pointed out that closers for letters and despatches have two kinds of content: the signature of the writer, and the name and location of the addressee. In JH's original print version, these were formatted on the right and left respectively. However, the XML structure we have doesn't really allow that, because all of the content is inside one <closer> tag; all that distinguishes the addressee is that his name and details are wrapped in a <name type="addressee"> tag. Because this tag is a child of the same <closer> that contains the writer's information (which is typically just text elements and linebreaks), it's a bit messy to format the two components as with one block on the right and the other on the left. It is possible using CSS, but IE7 doesn't handle the CSS correctly (specifically, it over-calculates a negative margin), so the address info is invisible in IE.

However, I don't think the problem is really one of formatting. The fact is that there are two distinct components at the bottom of the letter or despatch, and they should really be separate <closer> elements. This is a job for XUpdate.

This is the XUpdate code that is intended to fix the problem:

declare default element namespace "http://www.tei-c.org/ns/1.0";

for $closer in collection('/db/coldesp/correspondence/')//closer[child::name[@type='addressee']]
for $n in $closer/name[@type='addressee']
let $c2 := <closer>{
	$n
}</closer>
return <done xml:id="{$closer/ancestor::TEI/@xml:id}">{
		update insert $c2 following $closer,
		update delete $n
}
</done>

It's running right now against the whole db. Fingers crossed (and precautionary backup already done...).

Got some positive feedback from DB on my first shot at conversion -- we're on the right lines -- so I started looking at the second lot of files, and ended up adding quite a few extra replace operations and script tweaks to make them presentable. Processed both lots with the new Transformer sequence, and posted zip files for him to download. Transformer working well outside of the Delphi IDE, although I had a couple of out-of-memory errors on the largest block of files (277), when processing large files near the end, and doing other stuff in Windows. The errors were gracefully handled and reported, but I think we might need a GUI method for increasing memory usage.

First day on late duty this week.

Several new code libraries had been added to Transformer since the last release, and they were lacking header information, licensing info, descriptions for the Website, etc. The Website source code and requirements page, as well as the installer are now up to date for version 2, but the rest of the site will have to be updated before I can do a release. I need to do this (a beta, perhaps) within the next three weeks.

Working on DB's files, which are numerous and for which the processing is complicated, I found I really wanted to be able to cancel a batch operation, so I've repurposed the Progress form I wrote for Markin 4 to show how the batch is going, and enable the user to press a Cancel button and stop the process. This is a great improvement for large batches. The cancel flag is checked at the end of each replace or script operation, so as long as those operations are completing in good order, it's pretty snappy.

The problem of how to monitor and abort a frozen or looping script operation while it's happening still remains, though. I've been doing a lot more thinking and reading about this, and it seems likely that only something fairly aggressive such as TerminateProcess could do it. The script code would all have to run as a separate thread, and there would have to be a monitor thread with a timer, which was initiated when the process began, and which gave the user the option to kill a script process after a timeout had been reached without the thread terminating. That code could also check for the Cancelled flag, and kill a process when that was True but the process had been running for a (perhaps shorter) timeout. It'll take some work to get this implemented and tested. I'm still not sure there's a clean way to kill a process running in a C++ dll from Delphi without orphaning some resources.

Working on DB's hundreds of Waterloo Script files, as a way of stress-testing Transformer 2 and its script capabilities. I produced a batch of XHTML output (277 files) with most of the things that it makes sense to convert being handled in (I think) reasonable fashion, and posted a zip with the files where DB can get at them. Meanwhile, I'm going to take a subset of those files and make them the demo material for Transformer 2 for the DH2008 conference.

DZ sent a program, along with a revised schedule, for inclusion on the site, in the form of a WP document. Previously I've hand-coded the schedule, but that takes hours, so this time I tried a different approach:

• Export to XHTML from OpenOffice.
• Add header code from our site, hard-coded, inserted around the stylesheet created by OO.
• Add the PHP include for the menu (there's a gotcha here: the header inclusion is not well-formed, since its main div is closed in the menu inclusion).
• Edit and tweak till things look right.

This worked pretty well. Had to do a lot of tweaking for IE7, which seems to ignore ! important declarations, and had to remove a lot of unnecessary tags and styles, but it's quicker than starting from scratch.

Having received docs/images etc from the designers I have put together a fairly straightforward site using php.
The style will be difficult to duplicate perfectly but it's pretty close.
I have currently got index pages for each main section of the site, but I am still waiting on actual content.