HCMC Blogs

The transition from version 1.7 to 1.8 in the Image Markup Tool has introduced some new features and changes which needed to be migrated into the Mariage project files. This is the procedure I implemented to make the changes:

1. Data files (IMT XML files) were converted over to the 1.8 format. This was done with the IMT's built-in XSLT conversion file, but I modified it with some special overrides as below.
2. The result of this conversion would still have the wrong IMT version number in it, so that was updated by a modification to the XSLT conversion.
3. The conversion also results in a file which has inadequate distinction between transcriptional and non-transcriptional annotations. This problem arises in two locations in the file: first, in the <tagsDecl> area where the transcription categories are stored, the Transcription category had to be designated as "Transcriptional" by the addition of a <desc> tag inside the <rendition> tag. This was also easy to do through a modification to the XSLT.
4. The second problem component of the file is the linking, which by default ends up using @facs; all cases which are not transcriptional should be using @corresp instead. Another modification to the XSLT from IMT accomplished this conversion.
5. This gave me valid IMT 1.8 data files. The problem now was that the XSLT on the site was expecting the old format files, so I had to modify imt_p5_to_xhtml. Any code that makes use of the @facs attribute value had to be rewritten so that it could use both @corresp and @facs, and was sensitive to the new presence of the hash at the beginnings of those values.
6. Having converted all the data and the XSLT, I tested the XSLT by first uploading one new data file, and confirming that it failed to convert using the old XSLT; then uploading the new XSLT, and confirming that it worked with the new data file but failed with the old ones; and then by uploading all the new data files and checking a sample of them. Everything seems to work fine, including links into individual annotations.
7. Finally, I archived the old data files, and overwrote copies on the server in the mariage account with the new versions.

Everything seems to have gone smoothly. This is a tricky kind of task, especially on a live site, so it was good to do it when the office was empty and there were no distractions.

Dealt with some issues arising out of email over the break, including archiving some content dumped from the backup tapes from the old IBM mainframe.

Leaving early on December 24, then accounting for the three days of absence when the office is closed, brings my total down to only 11.5. Not bad!

Wrote the initial phase of a system for building PDF volumes. I now have XQuery that can retrieve a set of documents based on volume and/or issue number, or an arbitrary sequence, and return the results as a <teiCorpus>. I still have to figure out how metadata should be dropped in (derived from the first in the sequence, or some other approach), and how much metadata should go in through XQuery as opposed to XSLT. Both have access to the db's string resources, so both could do it.

Made copy of static social justice site and extracted the primary and secondary navbar stuff to javascript, just as a test. Created menuArray.js file which is a big lookup of all the folder and file names and all the section and subsection texts that appear in the GUI. Also created writeMenus.js which grabs the current page's URL and then writes the navbar including figuring out which elements to highlight. Got it working at http://web.uvic.ca:8080/~socjust/testjs

Pros: far less duplication of code on pages, edit one js array file
Cons: if JS disabled in browser, no navigation; have to understand structure of js array file and be careful editing (commented thoroughly in code)

Next: will do similar abstraction, but using php, which should keep the pros and eliminate the big con