MyNDIR

PAB came with a case in which one document was correctly showing a keywords while three were not, although they appeared identical. It turned out that the one that was working was doing so accidentally because elsewhere in it, there was a correctly-configured reference to the item, while the others had only the keyword entries which crucially were name elements lacking the @type attribute. Let PAB know; when she's fixed all such instances, I'll add a trap to the Schematron for this.

I'm now in the process of adapting the XQuery and XSLT from the Cocoon-based site to create static versions of the pages, and I'm making steady progress. One issue is that I'd like to avoid the use of the custom Java collation for sorting, just for the sake of simplicity, so I'm wondering about implementing the same thing in XSLT; it may not be worth it, though. We've been having discussions with PS about how the redesign might work, and I think the best approach right now is to generate something similar to what we have, and implement the JS-based search functionality, then worry about the actual design when PS has some more time.

Starting work on the Ending-ization of the project, I've written the process that expands the XML into standalone pages, added validation for those pages into the system, and started a reorganization of code to make the build process easier.

In preparation for Endings-izing this project, I've set up a Jenkins build job, and reworked the schema build and the validation process completely, following the model of DVPP. In the process I discovered a useful thing worth documenting. I had a Schematron rule which required the reading of an XML file, whose location was specified relative to the ODD file/RNG file location. However, when compiled Schematron was created elsewhere, this didn't work. Therefore I rewrote the rule so that it resolves a relative URI against the context file, like this:

<constraintSpec ident="biblCorrespPointsToBibl" scheme="schematron">
            <constraint>
              <sch:rule context="tei:bibl[@corresp]">
                <sch:let name="biblId" value="substring-after(@corresp, 'bibl:')"/>
                <sch:assert test="doc(resolve-uri('../biblio/biblio.xml', base-uri(.)))//tei:bibl[@xml:id=$biblId]">
                  ERROR: The @corresp value should point to the @xml:id of a bibl element
                  in the biblio.xml file (<sch:value-of select="$biblId"/>).
                </sch:assert>
              </sch:rule>
            </constraint>
          </constraintSpec>

Did a lot of work on schema and documentation, implemented some code changes using prefixDef structures, normalized a bunch of inconsistencies, and built a project file for both of us. Then PAB came in and we got her set up with svn and checked out the repo.

Met today and officially moved the XML over to svn, although PAB won't edit at all till next week; meanwhile, I'm fixing and constraining:

• The ODD file, which was huge and generic, is now much tighter, allowing only used elements, and including fixed valLists and Schematron to help editing.
• Inconsistencies in linking, ids, naming and so on have been fixed as a result of the much tighter schema and enhancement of diagnostics. Many improvements there.
• Began the process of changing full path links to prefixDefs; more to do there.
• Fixed XSLT and XQuery to take account of changes in markup to bring in line with 2018 TEI.

Next steps: Finish prefixDefs and processing implications, add more and fiercer diagnostics, add documentation for SVN to the ODD file, build ODD file documentation generation into the process, then train PAB with svn and hand back the process to her. The start writing the static build process.

Met with PAB and discussed our previous plan; decided not to create smaller versions of images. I will proceed with the rest of the plan as previously outlined (basically making it an Endings project) when time permits.

PROJECT PLANS, MAY 2017

Preliminary stuff Trish does first:

    - creating all the multiple-size versions now allowed following agreement from Danish National Library.
    
Stage 1: Specification for the new site menu and image array:

    - Main menu must work on all devices.
    - Thumbnail array should use grid layout and be flexible for all devices. 
         Display all images in grid layout.
         Each image has a descriptive caption (currently @title).
         When an image is clicked on, the grid disappears, and is replaced by a button for "Show thumbnails".
         The record appears.
         When you click on "Show thumbnails", all the images appear again above the current record.
         
Stage 2: Move data into svn (XML, not images).

Stage 3: Redesign pages in HTML5.

Stage 4: Write build process to create pages.

Stage 5: Implement Jenkins build.

Stage 6: Implement XAR creation in build process.

Stage 7: Roll out new eXist and test.

Stage 8: Replace original app.

Per PAB, added a new caption to the search results pages.

I've simplified the build process so that it just rsyncs a backup from the db into the repo, rather than trying to figure out whether it needs to or not. I've finished the diagnostics process, which reveals a highly-consistent and well-managed dataset, and sent the one or two little inconsistencies to PAB to fix. I think I'm done with work on this now until we know for sure that all full-size images can be shown, in which case PAB needs to finish creating the displaysize versions, and I then need to turn the displaysize image into a link to the full-size one.