HCMC Blogs

Reviewed two more packages.

JQuiz and JCloze files all lacking keypad settings -- consumes a bit more time than it should.

As our new document markup projects get under way, we're going to need to provide options for them to view and proof their work in the context of the site, without the documents themselves appearing in the various TOCs. I've set up a system for this based on the use of revisionDesc/@status.

• If a document has status="published", or it has no revisionDesc/@status at all (which is the case for our current published docs), then it will appear in the regular TOCs on the site.
• If it has a different status value, it will not appear in the TOCs.
• You can view the documents with a given status on any of the TOC pages by appending the URL parameter "status=whatever".
• The search system only looks at documents with no status or published status.

This will allow us to look at documents in development without "publishing" them officially.

Created a template with explanatory comments for marking up front matter. In the process, I realize that we should probably move a lot of existing content from the beginning of the body into the front -- dedications, prefaces and TOCs all really belong in front. A preliminary look at the XSL and CSS suggests that this will have no effect on the rendering, thankfully, so it should be a straightforward change. I'll put it on the list of things to do.

Working on creating a template for the <front> element, I discovered that the <argument> tag would be appropriate in <titlePage> and we should use it. However, it wasn't permitted by our schema, partly because we'd never used it in that context, and partly because it was only added to model.titlepagePart earlier this year (our schemas dated from 2009). Also, we had two separate schemas, with a sort of splinter schema used by the Agreemens texts and Complaintes, while the main schema was used for all the others. Time to generate a new schema. These are the steps:

• Copy all the XML files from the anthology into a temporary directory. Also copy in a new file which includes the new feature that you need to make available in the generated schema (in this case, <argument> inside <titlePage>).
• Open a terminal in that directory.
• Run oddbyexample.xsl like this:

  java -jar /home/mholmes/apps/apache-tomcat-6.0.26/webapps/mariage/WEB-INF/lib/saxon9he.jar -it:main -o mariage2010.odd /home/mholmes/WorkData/tei/1.8/xml/tei/stylesheet/tools2/oddbyexample.xsl   corpus=`pwd`/
  

• Upload the generated .odd file into Roma, and add title and description.
• Save the .odd file again from Roma.
• Generate the schema.
• Validate all the existing files against the new schema, before replacing the old one with it.

In the process of validating, I found a couple of errors in files which I've corrected (duplicate @xml:id attributes in two image markup files, and one mistyped attribute name in Sonnet 1609). I also discovered that I seem to have a broken Saxon jar in my cocoon_with_exist setup (which explains many things), so the path above is to a known working one inside the Mariage Cocoon.

Reviewed two more packages.

The stats on Megapode seem to have been backfilled with stats from previous times, going back to February 2009, so I've now retrieved the six stat blocks I'm tracking for both 2009 and 2010 up to Nov 30. The aim is to have one file for each year, but just in case stats end up getting lost, as has happened in the past, I download the year-so-far stats at the end of every month.

On late duty.

Lots of files missing keypad switch and content, so that has to be added manually in the config. Also I've edited the jcloze6.ht_ source file to add a second keypad at the top; this helps with long exercises. TB is up to around unit 26, so I'll try to do another 5 units tomorrow.

RVDB sent a solution to my Ant build problem, which basically works -- the eXist build.sh is now found -- so I've integrated that, and I've also found a better solution to using Saxon for XSLT, that doesn't depend on its being on the CLASSPATH (which I want to avoid, because its version numbers are likely to change over time). I found the solution in one of the comments on this page, and it's basically this:

1. Define a macro for Saxon, specifying a way to call it with the parameters we need to use:

     <macrodef name="xslt-saxon">
       <attribute name="in"/>
       <attribute name="out"/>
       <attribute name="style"/>
       <sequential>
         <echo level="info">XSLT Generating @{out}</echo>
         <java classname="net.sf.saxon.Transform"
           classpath="${saxon.home}/saxon9he.jar"
           logError="true"
           output="@{out}"
           fork="true">
           <arg value="@{in}"/>
           <arg value="@{style}"/>
         </java>
       </sequential>
     </macrodef>
   

2. Call the macros when required like this:

   <xslt-saxon in="${cocoon.home}/build/webapp/WEB-INF/cocoon.xconf" 
               style="cocoon/patch_cocoon_xconf.xsl" 
               out="${cocoon.home}/build/webapp/WEB-INF/cocoon.xconf.patched">
   </xslt-saxon>
   

Now I have RVDB's whole build process working OK, but the resulting webapp is broken; XSLT transformations don't seem to work. I suspect this is something to do with the way Saxon is being set up in the sitemap, because I'm using a more recent version of Saxon (HE, 9.3, as opposed to the three-jar version 9). I'll work on this issue tomorrow.