Map Of London

With JJ, have been working on aligning our byline attribution phraseology with Marc Relator terms. We're almost there.

Added <eventList>, <event> and <rs> into the schema, then created the eventography file, with one sample event, and marked the event up in two files using <rs>, as a demonstration for CB. Once we have some real data in the eventography, I'll add the requisite XSLT to make it functional.

Fixed several hundred encoding oddities and errors related to name tags and docAuthor tags. Also updated Schematron to try to catch some of these. We're now in a position where we have almost all names marked up as either @type="person" or @type="pageant", and the question now is whether we should simply make "person" the default, and therefore optional, and save a bunch of space in files by deleting all instances of it. I see no reason not to do that. There are some name tags which lack it already, and they're working properly.

Working on standardizing the current byline markup so that I can use it as the basis for generating more formal <respStmt> elements using our taxonomy of responsibilities. I have all names now marked up as names, but the informal descriptions of their roles are going to be very difficult to parse into clear categories.

Standardized our usage of @type on <list>, removing a couple of obsolete usages, adding documentation to the schema, and tweaking the XSLT. Many files changed.

Timesheets for Aug/2 done.

Processed all the files, tested locally, made some fixes, and migrated the changes to the live db. Also updated documentation on date encoding.

Lots of changes, most of them relating to the date coding changeover tomorrow, but also others:

• Added Twitter link to footer.
• Finished and tested all changes to XSLT for dates.
• Centralized ajax storage div in includes file.
• Finished writing and correcting date encoding instructions.
• Wrote comparison XSLT (which runs against itself) to check the boilerplate.xml caption segments against the backups in captions.xsl, and report on discrepancies. Migrated changes back from boilerplate to XSLT file.
• Fixed display of some captions which happen to have tags in them (which I wasn't expecting).
• Tested new date code on my local app with a converted personography.

Good to go for the big conversion tomorrow.

Links to biblio items on the ids page weren't working. I've now fixed it so that they show a little popup with the full biblio item. In the process, I identified a slight stupidity in XHTML page construction, so I've set myself a task to fix it.

On Friday I'll be converting all our existing date encoding to make proper use of the custom dating and calendar attributes, as well as updating the XSLT to take account of this, and providing new documentation. Today I wrote and tested the XSLT conversion code for the source documents, and wrote the first half of the documentation for encoders. What remains:

• Complete documentation for encoders.
• Rewrite XSLT to handle appropriate attributes.
• Make all changes in local test db, and ensure everything is working.
• Commit changes to SVN.
• Update live db.

We don’t need to mark-up dates in Contributor bios. They function as strings of characters in the bios.

1700 would be a reasonable cut-off for other dates. After 1700, we’re into secondary sources, not primary sources. And whatever happened on a location after 1700 isn’t really “early modern” by the conventions of the discipline of English studies. (Early modern is more capacious for historians.)

The guiding principle needs to be: are we going to do anything with this date? Is it harvestable data, or information that we need to manage the site effectively? If not, then it’s just a string of characters.

I've rewritten my original TitleSortComparator class so that it not only handles leading articles but also decomposes the ash character into an ae sequence before doing the comparison. This handles the outstanding issues with sorting of both the historical personography and the bibliography.

This is what had to be done:

• The new class was written with Eclipse, and is called MolSortComparator. It should be used as a model for future comparators and collators for eXist-only (no Cocoon) projects.
• There is also a test class.
• The class is assigned to the ca.uvic.hcmc.mol package.
• The jar file is created using File / Export..., and is named identically to the class (don't know if this matters or not, but it's what I've always done in the past).
• It is uploaded into WEB-INF/lib.
• It is called as follows:

  <xsl:sort select="persName/reg" order="ascending" collation="http://saxon.sf.net/collation?class=ca.uvic.hcmc.mol.MolSortComparator"/>
  

After deployment, eXist needs to be restarted, but I was able to do that from the Tomcat Manager interface (although it took several minutes for the app to shut down).

I think it's all basically working correctly, except that now we will have to convert from using @*-custom attributes, and I'll then have to rewrite the mouseover code accordingly. The XML and XSLT will have to be changed at the same time. That's for next week.

When marking up dates, tag monarchical reigns with notBefore and notAfter as follows:

When Stow says "yet then called the riuer of the Wels, which name of Ryuer continued: and it was ſo called in the raign of Edwarde the firſt"

tag the reign:

<date notBefore="1272-11-20" notAfter="1306-07-07">raign of <hi>Edwarde</hi> the firſt</date>

This post based on an email exchange between JJ and SM.

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.

Edited the personography and associated code as follows:

• The <persName>/@type "tech" is now obsolete (and should be removed from the schema -- note to self). All "tech" people are now "cont" (contributors).
• Two taxonomies have been added to the header of the file, providing codes for various roles played by "cont" people. One is a short one, created by us, with some basic roles; another is a selection from the MarcRelator codes.
• People who were "tech" are now "cont", with <occupation>/@code="#prog".
• All other people who are "cont" should also be assigned occupation codes from the appropriate scheme.
• The index_site.xql file can now display a table of people based on both the person type and the role (type and subtype respectively in the page params). This is probably pointless, because we will actually create sublists of people through XInclude in info pages, but it's useful for testing.

Changed the revisionDesc/@status values to remove "incomplete", and substitute "stub" and "empty" for the two types of incomplete pages. Suitable boilerplate is now added to pages with these two values from boilerplate.xml, and CB has updated all pages so their values are presumably correct. Some pages with other status values still have a stub message hard-coded into them, but CB will fix this.

The <term> and <mentioned> elements are now handled correctly (rendered as italics).

The Chrome bug (rendering <q> with straight instead of curly quotes) has been reported to the Chrome project.

These instructions were originally posted by MH in Flow.

We're going to be moving over to using a curly apostrophe (Unicode character U+2019, which is the same as the right [closing] "smart" single quote). This means you'll need to be able to type this character in Oxygen when you need it. You can do this using a Code Template.

First, find that character in your Character Map, and copy it to the clipboard so you can paste it when you need it. Here it is, in case you want to copy it from here: ’

Click on Options / Preferences, then type "Code Templates" into the filter box at the top. You'll see a list of the existing Code Templates. Click on New, then fill in the following details:

Name: Apostrophe Description: Curly apostrophe (U+2019)
Associate with: XML Editor
Content: [Paste the apostrophe in here]

Then press OK.

Now you can do this to insert a curly apostrophe:

Press Control + Space. You should see the Code Template selector appear, and there is only one template, which is this one. Press OK to select it.

These instructions are adapted from the instructions posted to Flow by JJ on 3 July 2012.

Netlink ID: london
Full address: london@uvic.ca
Obtain password from JJ

All of the emails sent to this account are automatically forwarded to mapoflondon@gmail.com. Obtain password from JJ and see documentation/emails.odt in the SVN repository for more information on using the Gmail account.

These intructions were originally written by JJ and posted to Flow on July 4 2012.

Go to MLA website: mlahandbook.org
[Get user id and password from JJ.]

Search function works fairly well if you know MLA already.

These instructions were created by JJ and were originally posted to Flow on July 4 2012

Go to http://webstats.uvic.ca/.

Username = jenstad
PW = [ask Janelle]

Once you are in, you can view sessions, page views, hits, referrals, domains, entrance pages, and exit pages ... and sort by date. Normally, you won't need to check these stats unless Janelle asks you to perform a specific task.

These instructions were created by MH and posted to Flow on July 6 2012.
Our requirements for validation have been getting more and more complicated, and I'm now using a fairly large Schematron schema which requires XPath 2.0 and foreign elements. This means that you will need to make a couple of changes to the Oxygen preferences so that Schematron functions correctly. If you don't do this, validation of XML files will fail. Here's what you do:
Click on Options / Preferences.
In the filter box at the top left, type XML Parser and press return. XML Parser [P] should be selected.
Under "Schematron / Schematron XPath Version", select "2.0".
Under "ISO Schematron", check "Allow foreign elements".