We need to update the Agas Map code so we can use the latest OpenLayers for GIS maps as well. It turns out that the changes in OL since the original code was written have been significant, so I made a start on this today. I have the basic functionality working (although I still haven't managed to successfully reproduce the pan/zoom functionality -- needs more work), but more important is the drawing code, which is only partly working; drawing itself works, but no feature is available at the end of the process, so the TEI output is not being created in the text box. We can't switch to this version till I've fixed this.
The controller didn't have anything set up to show the XSLT files which we provide as part of the documentation. JT reported it, and I fixed it.
Tiny bug in the TEI Simple XSLT broke the build: LS used the @resp
attribute on <soCalled>
, which is a nice idea and makes perfect sense, but which the simple code wasn't expecting. Took a while to narrow it down, but it was an easy fix.
MoEML training day today, so spent the day prepping and training. Went well, especially the hands-on stuff.
Put in ticket for @where
in the TEI and debated on that thread
Since the static site is now deployed, we can finally convert all pointers to "mol:julian" to "mol:julianSic"; we'll have to change these on a case by case basis. These have now all been changed and the schema updated so that "mol:julian" is no longer a valid value. Luckily, I didn't need to change any of the static code, since it could handle all four cases (julian, julianSic, julianJan, julianMar). In the future, we might want to clean up the code so that it doesn't have to handle "julian," but, for now, it should be fine.
The more pressing concern, however, is the documentation. I've updated encoding_dates.xml to reflect new encoding practices and changed the wording where the difference were obvious. However, the documentation will need to be updated so that it includes a larger discussion of why we are disambiguating julianJan/julianMar/julianSic with evidence to support why we need to do this.
Martin, Tye, and I made a presentation on 2015-09-02 about this, which ought to be turned into the documentation. There's some good evidence in the slideshow that I had completely forgot about (the reason we did this in the first place is that the STC regularized to January 1 without doing the necessary arithmetic to get the date into the Gregorian equivalent).
Worked with MK and JJ over the last two days working on various mayoral pageant encoding. Each playbook gets two documents (as well as paratexts/critical introductions etc etc):
- An old-spelling edition, which includes a horizontal collation. This is not radically different from how we've encoded the pageants (and Stow) already, but a few small changes:
- There will be fewer divs than before. The title page goes in the front, while the rest goes in the body.
- Instead of using choice/(sic|corr), we will use app/(lem|rdg). This allows us to do a horizontal collation, which is fairly simple since there are few versions of these texts. Plus, it hasn't really been done yet, so it's a worthwhile thing to do.
- A modernized version, which will include a vertical collation. We talked about this a bit less, since we won't be working on this for a bit, but we had a few ideas:
- Since the move element has now opened up, we've thought about using move to denote the physical geographical movement of the characters through space. It may be a bit of an abuse of @where, so I'll have to check on this.
- We also want to denote discursive shifts in the play (the shift from description to history etc etc). We should do this via milestones (or something similar) that denote the start and beginning of a particularly interesting segment, since these often cross textual hierarchies.
Created an intro to SVN using the training repo, and delivered it during the meeting.