JT's run of our diagnostic tools package against the Standard XML static output revealed thousands of errors, most falling into a few categories, which I've been addressing today:
I'm now building and validating various parts of the static process before I run the diagnostics again on the results.
I wanted an easy way to list all the Stow chapters in a table, and decided on a new category, mdtPrimarySourceStowChapter, which is added to the chapter files when they're generated. To make that work in the build, I had to rewrite the XML category file generation process so that it works from the site/xml/original documents (where these generated files are) rather than the XML source in /db/data (where they're not). In the process of doing that, I cleaned up the globals module so that it has no hard-coded paths in it; they're all relative to the baseDir now.
Following a request at the team meeting the other day, I've added document status displays to all the category listings pages.
Following a good team meeting with lots of discussion, I've made a formal link to the viewable-draft document so that it's easier for everyone to access drafts, and also fixed a bug in the class attribute generation that was preventing the display of the draft watermark.
The new static build version of the Map of Early Modern London project has now transitioned from alpha to beta, meaning that we believe all key features have been implemented and we're in bug-fixing mode.
Got some sample transcription from KB, and did a test encoding, tweaking the XSLT and the schema too to get more worthwhile results.
Also fixed the problem with the generic search box on regular pages; it was missing some named hidden fields, so wasn't providing enough info to the search.xql file. I do need to make this a bit more robust, though; missing fields shouldn't break the results paging navigation as it does.
Went through the steps planned yesterday, and also added DC metadata for all the people and orgs mentioned in all documents; I think the headers are now looking good.
We have an issue with a small category of documents, typified by QMPS1. These docs purport to be mdtPrimarySource, and indeed they contain transcribed primary source selections, but that content is interspersed with born-digital commentary and no attempt is made to describe the bibliographic features of the original source. When rendered in the static build as mdtPrimarySource, they end up unstyled. I've hacked around this by insisting that a true primary source document (for rendering purposes) must include at least one rendition element in the header (other than those auto-generated from @style attributes during the build process); failing this, the document is treated as born-digital. In the long run, we should find a principled solution to this issue, and JT is drafting a description of the problem for the next MoEML meeting.
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:
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.
:: Next Page >>
This project allows literary and scholarly works (primary and secondary) to be associated with locations in London, providing the reader with a richer understanding of the works.
|<< <||> >>|