HCMC Blogs

Fighting with console warnings from an ant scriptdef...

6am to 7.30, TEI Stylesheets co-op group meeting. Made some progress with a ticket dealing with whitespace in biblStruct processing.

Fairly major overhaul of the original code, to do this:

• Handle all attributes, rather than trying to figure out which might be pointers.
• Determine instead whether a token value in the attribute is some kind of pointer.
• Resolve prefixDef/private URI schemes.
• Handle paths on Windows. This took some wrestling.
• Calculate the date in the ant script instead of getting it from Oxygen.
• Format the output much more effectively.
• Add tests for simple cases.

Lots more to do, of course, but this is coming along nicely.

Certain trial-file records (e.g. Ely Smith 1750 age 20 Robbery) return a count() of 2 rather than 1, and I can't figure out why. The count returned from the sql query seems to be used only in the json.php file to determine how big to make the brick for the specified crime/gender/agegroup etc for the specified year. So, I modified one line of code in the json file to replace the value of count() with 1.

The _execute function in the Search.php file has been simplified so that it always uses
$this->_select->group('tf.trial_file_id');
Previously table output used that argument and chart output used the argument
$this->_select->group($this->allowedGroups[$this->_data['group']] . ', YEAR(tf.trial_file_start_date)');
but that caused inconsistencies in the total number of records returned, which I haven't been able to resolve.

The issue now is that the chart appears as a stack of same-coloured bricks for each year-attribute pair rather than 1 brick of height count(). For the time being I'll trade off the slightly less elegant display for the accurate and consistent counts.

Endings and workstudy.

A couple of tweaks to the personography per DH; and also working with GL settled on a specific token that will be included inside a commented-out table (untaggedTable) which will trigger a message in the output to the effect that we haven't encoded it yet. Implemented the output processing for this and tested it.

JT started the diagnostics repo for projectEndings on GitHub, and did all the initial work to get something that will process a folder full of XML and check internal links. I tested and raised a few issue tickets, then set about solving some of them. We now have a process that will check three kinds of link: internal links within the same document (on the assumption that RelaxNG does not do this unless DTD Compatibility is turned on); links to external documents; and links to specific ids inside external documents. I think this is a good initial selection, and when run against Mariage, it does indeed find some bugs that need fixing, which I will fix. There's a lot to do in terms of making it prettier and more user-friendly, but the basics are definitely there.

The new translation document came in. The translation's not long, but there's a fair bit of intro material and lots of footnotes. Did the header, front matter and first few paras, along with the bibliography; I've left old content from the last translation in place so it's clear how the encoding is structured.

I did hit one strange error which took a while to resolve. When I copy-pasted text from the Word file open in LibreOffice into Oxygen, I got errors because of the inclusion of non-Unicode chars, specifically 0x7 and 0x8. After opening the document.xml file in Oxygen to see what these were, it turned out that these were the positions of bookmarkStart and bookmarkEnd elements in the text. I don't need the bookmarks, so I search-and-replaced all the bookmark elements away and saved back into the Word file archive; no more problems.

Tweaked the tagging-tools page a bit too, to handle editor list encoding better.

I have a viable 'search all' system working now. It relies on a separate table that consists of a record id (the person's ID) and another field that is a concatenation of many of the other fields. It will need to get regenerated every time the materialized view is rebuilt.

The resulting search is very fast on my VM. The only feature missing for this is the ability to add constraints to the result. So, if you search for 'electrician calgary' it will work very well, but if you add an explicit regimental number constraint to the search, it will fail. This isn't hard to overcome, but it will require a fair bit of fiddling with the main SQL constructor as the structure is quite different from the way other queries are built (sub-query that produces a sequence of IDs gets passed to the parent query for eval.).

worked till Homer - The Iliad, Book 24 . time spent 11:20-1:20 ~ 2 hours .