HCMC Blogs

In the static build output, all of the standalone documents which are created from AJAX fragments (people, bibls, orgs) have a particular problem in their headers: they are constructed based on the entire containing document rather than the fragment which forms the actual body of the document. This is because the same hcmc:createHtmlHeader() function is called passing in e.g. PERS1 rather than the target person entry. I've been trying to figure out how best to remedy this, and I think the best approach would be this:

The hcmc:createHtmlHeader() function, along with the hcmc:getDcMetadata() function it calls, should have an additional optional parameter which is the component item which is actually the focus of the page. Where this is not passed in (the default situation), the same processing would be applied, but where it is, the document title and resulting metadata should be constructed based on it. Some of that data will still have to be derived from the parent document, but (for instance) the list of places and people referenced (the former already implemented, the latter still not generated in the DC metadata) should be drawn only from the links appearing in the target fragment.

Steps to proceed:

• Add the parameter to the two functions.
• Fix any calls to those functions such that they pass the empty sequence or the relevant fragment.
• Test the build process to make sure nothing is broken, including search (which depends on header metadata).
• Add conditional branching to handle the different cases where a full document versus a fragment is being dealt with, for the current output. This includes ensuring that the document title is correct -- so instead of "Complete Personography" for every person page, it should be "Complete Personography: Fred Bloggs". (Not yet sure what should happen for bibliography entries, where there's no natural "title" other than the document title; perhaps the first title element in the bibl should be used.)
• Add (to both cases) processing of the person data (listing persons mentioned in dcterms.appropriatething, presumably dcterms.subject).
• Check that the outcome is appropriate for all fragment pages.

I noticed that some procession maps were stored in the site/images folder rather than in data/graphics (which actually meant that they failed to appear on the static site), I've moved them, and fixed references to them in the documents. As a general principle, images which form part of the site structure and design (thus appearing on lots of pages) should be in site/images, while images which are linked in specific documents appearing on the site should be in data/graphics, where editors can manage them.

Much polishing to do, and formatting/footnoting/referencing, but the bulk is done, and I've added a flowchart diagram which helps clarify things. I think it'll come in at about 25 pages at 12pt double-spaced.

Received PGL's site edits; have made the changes; more to come; updated tabs-block;
republished edited pages.
Sent update email to PGL.

Set-up on-line account and ordered through printing on-line business cards for JN. Will order remainder once 1st order is received/approved.

Encoded (at home this morning), but with some questions outstanding with editors. P5 and PDF versions not yet generated because I have no XEP here.

On late duty.

JA called to report that the config on the CCAP db had been hosed by the visit of a robot to a specific URL, which triggered something completely unexpected and unwanted. He was able to recover it, and add protection against a similar event both on CCAP and on LOI. The AtoM documentation is apparently not working properly so we can't find anything on their site about this particular "feature".

As part of work on the article, ran the algorithm against the Maple Ridge land titles db data, and did some background research to reduce the number of ja-xProvs. I have the output counts for the initial phase and the phase after research; some interesting/problematic cases emerged, which I'm discussing with MA and JSR, but in general everything worked as expected (virtually zero genuine false positives; all provisionals are "interesting" and need research; no false negatives).