Map Of London

I have Julian to Gregorian date conversion popups working for simple dates (@when only). This is not yet on the live site because date ranges are not yet working, but I hope to have them in place soon.

There is a lot of unnecessary conversion between string representations and actual xs:date values all over the code, due to the way it's grown by accretion, and the way we've changed our minds about rendering rules. I should really look at this again, and see if I can take strings on input, convert to xs:date, do all manipulation with xs:date, and then render out right at the end. The problem here is that when we have partial dates (e.g. year-only dates), constructing an xs:date object requires the addition of month and day values, otherwise it fails; this introduces a spurious precision to a date which consists only of a year.

Baptism dates are now rendering as prescribed by CB. This took longer than expected, because it's a special case, but still needs to be part of the regular rendering pipeline so that projected handling of non-gregorian calendar dates works as expected with it.

At present, TOCs are only generated for documents which have multiple <text> elements. This is resulting in documents which should never have multiple texts being created that way, just so they get an automated TOC. Obviously this is silly, and I need to revise the system so that it continues to support the existing documents (while we change them -- although perhaps not all will change), but supports TOC generation for single-text documents based on some measure of complexity. (Or perhaps all documents with multiple div elements should get a TOC by default?)

I now have a working and tested fuction which, given a Julian date at any level of specificity (YYYY, YYYY-MM, or YYYY-MM-DD) will return either a single Gregorian equivalent, or (more likely) a sequence of two Gregorian dates representing a corresponding range, accounting for the leap day offset and the March New Year issues.

Meanwhile, we've determined that in the context of the personography, birth and death dates will be rendered as en-dash-separated years only where both are precise and certain (i.e. @when). In other cases, the renderings will be split into b. xxx d. xxx clauses, so that the ranges, precision, certainty etc. on the two components (which may be different) can be expressed unambiguously.

The following from SM (examples in this file):

1. Check page break
2. Check fw
   Is header (running title) correct? Is page number correct?
   Is signature correct?
   Is catchword correct?
   Remove any empty form works elements
3. Add comments for printer's ornaments
4. Proof text itself – insert comments to editor if anything is unclear, in doubt, or needs to be glossed - Check hyphens and insert comments for double hyphens
5. Identify any foreign languages (Consult http://mapoflondon.uvic.ca/tei_markup.htm if necessary)
6. Mark up dates

I've started work on the date conversion code for handling Julian vs Gregorian proleptic. It's astoundingly complicated, but for now I've decided to handle two core features: the increasing day offset caused by the Julian leap year miscalculation, and the fact that between 1155 and 1751 the year was generally viewed as starting on March 25. There are dozens of other potential gotchas, but this will at least give us a basic way of handling conversion that will be approximately right nearly all the time.

The core ideas are:

• Where @calendar="mol:julian", the encoder will either do a calculation to create gregorian date values (which will only really happen if there's solid evidence to enable this), or they'll encode the date string using @when-custom and friends from att.datable.custom.
• If this is a transcription of a source, the original text will go into the date element, and that will be what's rendered. If there's no source text, then the date element may be empty.
• In the former case, the original text will be rendered faithfully, and a mouseover will be created explaining the date in gregorian.
• In the latter case, a rendering will be created according to our styleguide (based on MLA and on practice from elsewhere that CB is collecting), and again, a mouseover will give expanded detail.

I've spun off all the XSLT relating to dates into a separate module, and created a testing module that I'm building as I go along, so that we can verify everything is working without too much extra work whenever we make a change.

• Added Fictional Personography page.
• Changed index_moeml to encyclopedia.xml, which makes more sense and fits with its menu item.
• Updated index_site.xql so that links to the old URL still work, just in case.
• Fixed a bug which was introducing an extra comma after nested analytic titles. I had not been paying enough attention when using the preceding:: axis, and had to change self:: to ancestor-or-self::.

The personography has been enhanced with codes for student contributors, and their page is now equipped with an auto-harvested table; CB will be checking the existing information from that page is all in the personography entries before deleting the old list.

The personography of historical figures has now been regenerated using the new system, at a new URL, and its table captions are now in boilerplate.xml; the table is now part of a static page which can be edited.

I investigated the use of <respons> instead of <occupation> for the person entries, but it has a required attribute @locus, which is supposed to specify precisely what part of the element concerned the person is responsible for. This is not what we need to do at all, so <occupation> is our only option, but I'll continue to raise this issue on TEI lists, because it appears there's no useful way to assign responsibility according to a formal scheme without using the inappropriate <occupation>.

As part of fixing the missing text in links in MIDD17, I tested and fixed the system for implementing links from one document to a fragment of another. This is basically how it works:

If you want to link from one document (say MIDD17) to another (say TRIU1), you can link to the whole document using mol:TRIU. However, sometimes you might want to link to a specific part of the TRIU1 document (which is a multi-text document). You can link to a specific <div> in the target document like this:

• First, give the <div> in the target document its own @xml:id. For instance, we might want to link to the "Grocer's Company" section of the TRIU1 document, so we find the div that contains that section, and give it an @xml:id. Our convention is that an @xml:id for a section in a target document should be created with a prefix that consists of the main document id (TRIU1) and an underscore. So we do this: <div xml:id="TRIU1_grocers">.
• In the document where you want to put the link, construct the link as follows: <ref target="mol:TRIU1#TRIU1_grocers">. In other words, mol: + the document id + # + the div id.

Links constructed like this are now working on the site (see MIDD17 links to TRIU1 for examples).

Monographic and journal titles need to be italicized, but when nested inside another of the same, they need to revert to roman type. That is now working.

Note to self: there are a lot of old CSS classes that we're no longer using, which could be cleared out to simplify the CSS.