Map Of London

After some discussion with CB, we reversed an earlier decision to allow the automatic detection of quotes long enough to be rendered as blockquotes, because it proved to be impractical; position of punctuation is going to be different depending on whether the quote is rendered as a block or not, so an automated system is not likely to do a reliable job of rendering. We've now settled on the use of <cit> as a method of triggering blockquote rendering, and a Schematron constraint which warns you if you have a quote which is over 186 characters but doesn't have a <cit> parent.

Also fixed a bug in the display of head elements in popup bios.

SM reported an SVN conflict, which took me a good while to figure out. It turned out to be caused by her having made a very minor edit to her file (adding a comment to mark where she was up to) after committing the file last week. Then when I made changes on Monday, my changes were against the old version, and SVN complained when she tried to do a checkout. Advised moving the local copy somewhere else, then updating, and re-inserting the comment.

Added svn property blocks to the heads of all the XML files. Reminder to self on how to set the relevant properties on all XML files:

find * -type f -name '*.xml' -exec svn propset svn:keywords "LastChangedRevision LastChangedBy Id LastChangedDate HeadURL" {}  \;

Used XSLT to process the simplest 90-odd bylines into respStmts, to form the basis for manual conversion of the remaining ones.

This post contains info gathered as part of preparation for the conversion of all our rather raggedy <byline> elements into proper <respStmt> elements.

The following documents all contain multiple byline elements, and therefore need to be handled manually:

LEAD101
EXEC1
HENS2
SWAN1
QMPS1
EIRE1
TRIU1
TESI1
CHRU1
TROI1

197 documents have a single <byline> element. Of these, 93 have only one <name> element in their <byline>. These will be the simplest to handle.

I've written code to handle all the single, simple instances, and that seems to be working pretty well. I'm going to see if I can elaborate it to handle single bylines with multiple names.

CB reported some missing titles on people pages, which turned out to be due to the XQuery which generates them not supplying the appropriate <front> element to the XSLT. Fixed this, and also added a trap for empty document titles.

Our Plum buildbot is failing to build eXist WARs for various reasons, so I set up a build setup on my local machine and did a fresh build of eXist with no modifications. Since it worked, I thought I'd test MoEML on it. The upshot is:

• Everything basically works fine, and the whitespace-node-loss bug is fixed (although when you change preserve-whitespace-mixed-content to "yes" in conf.xml, you then have to re-upload all your documents for the change to take effect).
• The upload-sync script Greg wrote was failing because the last_modification_date.xql script would not run on the /db root collection without a logon (because it was accessing the security collection in system). Changing the script to use the admin logon when checking the date, rather than only when uploading to the db, fixes the problem.

The redesign project is now launched, after a plenary meeting with the PS. I've sent a follow-up email going over what we discussed, and I'll liaise with him on the early stages of mock-ups.

To remove all ambiguity about what should be the page title, I've restructured all the documents in the collection so that they have one unambiguous page title, and changed encoding instructions, templates, XSLT and XQuery to match.

Met with JJ and CB to do some preparation for the meeting tomorrow with PS. More info coming...

Two new people to add to the pay timesheet system. Created new timesheets for them. Still waiting for Sept 1-15 hours for 4 people.

Codebase is now clean of name/@type. In the process, found an extra file in the db which wasn't in versioning (DITC1), so added it.

In our born-digital documents, we're sometimes assuming that the page title will be taken from the teiHeader, and sometimes assuming that it will be the first div/head in the page; this is very confusing for code which is trying to render a title and then provide a TOC as well. I've put a very messy set of rules in place that attempts to render the page title based on what it can guess about the author's intent, but we're going to have to firm up our practice here. I think we need to formalize what we're doing here. For the page title, I think we should be using text/front/head in all situations, even where we have text/group following it. That would put the page title in the text without its being confused with a toc (which would be generated based either on body or on group). I'll have to figure out how best to make the changes smoothly, though.

After checking that CB has removed all instances of name/@type[.='pageant'], I've started removing the now-redundant @type='person'. I only got as far as /info/ before I found a different bug to focus on, though.

I've rewritten the TOC code so that it can cope with both the old <group> structure and a simpler setup based on <div> nesting. I've also converted all of the files in /info/ that were using multiple <text> elements so that they use only one <text> with nested <div>s. All of these are now rendering OK, and the old <group>-based pages elsewhere are also still rendering with TOCs while the team decides what to do about them. We can leave any pages that actually need multiple <text> elements alone if we want to, but any we do change will now get working TOCs.

I also have a handy XSLT tranformation that can turn a <group>-based document into a single-<text> document automatically, so conversions don't have to be done manually.

As a byproduct, I've removed the processing of div[@type='placeInfo']/head from the rendering of the locations pages, so those pages are only getting one title, and it's taken from teiHeader/fileDesc/titleStmt/title. CB having some problems with those <head> elements at one point.