HCMC Blogs

Trying to get the MoEML build working by the end of the week.

We need to get to a point where the XHTML5 is valid so that we can browse the results on Jenkins. Found a few remaining issues in the data, including combining diacritics detached from their original char, so I've added a Schematron rule for that. Fixed some XSLT bugs, and I'm now at a point where I think only novel errors from Stow are likely to be thrown up. Waiting for the long build process to complete now, to see the latest crop of errors.

There's no actual data in the check db to work with yet, so today I've just written some XSLT to create title-based views of the data suitable for comparison, and build those forms into the build process so they're easy to work with. When I have some real data next week I'll be able to do the comparisons.

This week I'm tasked with writing an automated comparison of the data in the Maple Ridge check database against the live db. The first stage in this was adding the Check db to the processing which:

• dumps it nightly in XML through a cron job on Grape (see previous posts)
• processes it in the same way as the other two dbs to create a more usable view, then a lot-based view
• adds the results to the downloadable products

I'll now start working on the comparison code.

Out for one hour in the morning, stayed late for two. Pushing forward with MoEML static build.

I've gone through the original primary_source.xsl and general.xsl to transfer and/or adapt all the remaining templates that I believe we need for the static build, integrating them all into the single xhtml5 mode, and trying to avoid distinguishing between them too much. At this point documents are building happily and looking not-too-bad, but there are still invalidities (some in bornDigital docs, caused by the introduction of templates from primary source), and also I think there are changes that need to be made to the chapter-splitting Stow code to make sure that the base style info for the page width etc. is imported from the parent document into every chapter. Getting there, though. Another few days...

On late duty.

I've been gradually setting permissions throughout the folder hierarchy as they turn out to be necessary, and I think we've now reached a situation where WP is working, and the remaining problems are due to paths set up to point locally in the original install. BS is working on that now.

Ported the Agas Map code from XQuery to XSLT, and wrote some additional JavaScript to handle the changes in configuration required for embedding. This now appears to be working well, and I've also added a new feature to all pages, on the left bar: a link to "Map this document on the Agas Map", which highlights all the places mentioned in the document on the Agas Map. This is distinct from the embedded map of a single location that comes up at the top of the page for location files. I've also got the Agas Map JSON being built as part of the static build, which I think means that our entire product for the static build is fresh every time and internally coherent.

Note Meanings

To Be Added. : Cemetery identified and needs to be added to canonical (see blog post)

Unclear. : Unsure which record this entry belongs to or cannot find cemetery that corresponds to the name with the correct person buried there.

Cannot Find Record. : Cannot find the entry that lists this burial location

Notes

There is no Woodland Cemetery in Saskatoon, Saskatchewan, only a Woodlawn Cemetery and the Woodlawn Cemetery has burial records for people whose notes say they were buried at Woodland Cemetery. This confusion between Woodlawn and Woodland is common in several other cemetery name transcriptions as well.

In cases of very common cemetery names i.e. Woodlawn, the Commonwealth War Graves Commission lists cemeteries as Town Name (Common Name) Cemetery, a style I have adapted when adding cemeteries to canonical with the same common name.

Abbreviations

R.C. = Roman Catholic

FG = Find a Grave
CWGC = Commonwealth War Graves Commission