John has expressed a desire that the TOC pages display the article titles sorted alphabetically, but without the articles included. We now have a way to approach this, using a custom sort comparator written in Java, as we've done for the Moses sort. I wrote a comparator which strips articles before comparing titles, and tested it with JUnit tests, then uploaded it to the Cocoon WEB-INF/lib directory and restarted Cocoon. Then I came up against the same problem as I had with Moses: the XSLT is all version 1.0, so Saxon 8 isn't appropriate for it. I did a bit of testing with by creating test pipelines using 2.0 versions of the files, but nothing works properly (XIncludes are not XIncluded, and the sort doesn't appear to work either). If this sort is really important, and can't be achieved simply by adding a new version of the title to each document, then we'll have to rewrite all the XSLT, but it doesn't seem worth it at the moment. The comparator will be very handy later when we work on teiJournal, which will need it, so it's not wasted work.
After I corrected this issue I took time to analyze the div borders, widths, margins and paddings for the affected areas and I had to resize a few elements as I was using too many pixels for the main div which contains the website.
I recreated the homepage, staff, contact, and employment opportunities web pages. I am in the process of recreating/restyling the faculty web page. After I finish this I am going to begin recreating all the other static pages and then move on to recreating the dynamic php pages.
I have completed the feature structures and merging of entries in the affix.xml file. The file still requires proofreading against MDK's filecards, phonemicizing, and changing all ejectives to stop+raised comma, and ensuring that all glottalized resonants are resonant+superscript glottal.
What is the most efficient way for me to undertake the ejective/glottalized resonant changes?
Next task: the Pharyngeal file, to have one more complete file with lexical rather than suffixal content. And then I will turn to the lexical suffix file because the LSs require feature structures as well.
On lates again. Those hours are creeping up, but maybe I'll take it easy in the middle of next week to get them down a bit.
I've continued work on my Java app to generate P5 critical apparatus from the output from the old Mac Collate program. I'm now able to generate all the <app> and <lem> tags, and I've created a table where the user can specify the sigla of in the input file, and alternative sigla to be used in the output if required. I'm now figuring out how to parse individual lines into different readings, and learning in the process how to use Java vectors. The NetBeans IDE is still working well, with the exception of some of the property editors for Swing components -- the table editor is especially flaky, and best avoided.
I've been testing JUXTA, and I find I'm not unimpressed with it so far. First, I did a simple test with three plain text variants of a Larkin poem. The application found all the differences with the exception of leading spaces (indents on even-numbered lines), and it generated a useful apparatus. However, it numbered the lines including breaks between stanzas, so the first line in stanza two of was numbered 6 instead of 5. This is despite the fact that I set it to Ignore Whitespace. When I set it to pay attention to whitespace, in order to see what it would do with the missing spaces at the beginnings of lines 2 and 4 in variant 2, I saw some very odd behaviour relating to the combination of "Ignore case" being ON, but "Ignore whitespace" being OFF. In the end, I found I had to turn all three Ignore switches OFF (whitespace, punctuation and case). If I didn't do that, I would get an apparatus that suggested there were differences in capitalization when actually there were differences in spacing.
Having done that, I found that the line numbering was a total mess. The program found two variants on line one (the second of which was actually on line two), and then placed a fourth-line variant on line three when it was actually on line four. This was using a VERY simple input set. My conclusion is that JUXTA is not usable with plain text input.
Next, I tried markup up the poem variants according to their guidelines (JUXTA uses a proprietary XML format). The first thing I discovered is that whitespace matters in the GUI of JUXTA; if you pretty-print or indent your tags in the XML file, the output will retain some (not all -- it's inconsistent) of that indenting and whitespace, making the appearance of the poems harder to parse in the JUXTA GUI itself. The collation it generated was a bit better and more reliable, but still it was a little odd; missing spaces were signalled by a ~ character with no indication of where in the line they were missing from, and an inserted line in variant 2 was identified as such, and located in the right stanza, but it wasn't clear where it had been inserted.
Nevertheless, it seems as though this might be a useful tool, assuming we have the resources to mark up our source texts. I'm going to look at the actual code of the app, and see if I can figure out how we might improve or work around these issues.
Documentation Manager: Document chapters now display correctly, formatted with CSS. The chapter navigation buttons are working; the search is not. Essentially the Documentation Manager is functional. I found that dynamically transforming the XML documents each time they are requested was much too slow, so it now caches the HTML fragments the first time they are generated (and again if the source XML document changes), and subsequent requests use the cached copy. So the first request is slow, but after that it is fast.
Installation and Configuration Manual: This being the test case, it is moving along slowly as I get comfortable with DocBook. It is about 25% complete.
Completed "Boring Conference No Vars" quandary exercise with no variables, "Boring Conference Vars" with decision points and links ready to add transactions, and "Boring Conference Vars Done" with LiesTold asset and Transactions.
Also completed draft of presentation in XML with HTML output to our standard 'PowerPoint-Like' output, ran through it a couple of times. Have strings of text in text file to copy and paste to reduce typing time.
Pretty well ready to go, will need to run through authoring again, install Quandary on laptop at home and upload site to an account and create symbolic link from hrd/etug2007
John has been studying the turgidly-named by quite interesting Study of the Feasibility of Open-Access Publishing for Journals Funded by SSHRC's Aid to Scholarly and Transfer Journals Programme (PDF warning), which I also took a look at myself, with a view to ensuring we're on the right path and taking the right decisions, and looking at the possibility of SSHRC funding for ScanCan in the future. We do seem to be on the right track, although there's a lot more we could do in terms of:
- Specification of licensing and copyright terms up-front for authors (probably implying the adoption of a Creative Commons licence). We already knew about this.
- Institutional archiving of the journal. We should talk to the library about this.
- Encouraging authors to self-archive their own papers in their own archives.
- Having the journal indexed in one or more public indexing services. This would involve identifying appropriate indexing services, registering with them, and providing an appropriate API or metadata source for them to use.
- Looking at the SSHRC grant application in detail (deadline June 30) to see if we can qualify for support. The requirement for four published issues in the last two years would seem to rule us out, but we might qualify under an alternative criterion which requires twelve published articles in the last two years. If we can get funding, we can set some folks to work digitizing the old issues.