teiJournal

Tweaked the contents handling so that proofing documents are now simply stored in a different subcollection. This prevents their being indexed and their authors and other metadata showing up in the TOCs and indexes.

Finished marking up the new article, and sent the URL to the editors for proofing. Added handlers for two different groups of new reference/biblio item: onlineCommunity (which has its own handler), and the other group of onlineFactSheet, onlineBrochure, onlinePublicAnnouncement and software, all of which are handled as part of the old book handler, since they're all similar monograph-type things. Had to add a new function to handle "n.d." dates; this is called from the big monograph template, but not from anywhere else yet. When the time comes, I'll migrate it into all the other bits which render dates.

Received the first article for the new edition of the IALLT Journal, so I started marking it up. I've nearly finished that article. Notes at this point:

• I haven't yet marked up all the names and abbreviations in the body of the document. There are lots. I'll do that tomorrow.
• This article has fournew types of bibliographical item, which I've tagged as onlineBrochure, onlineFactSheet,onlinePublicAnnouncement, and software. The first two can probably be handled identically, but I'll need to write three XSLT handlers for outputting these types in APA format, as recommended in the APA electronic guidelines supplement.
• I wrote a couple of bits into the sitemap and the contents.xq file so that going to a specific page will show the articles uploaded into the db but not released yet; they're tagged as type="proofing" in their <teiHeader> tag. The editors will be able to view these documents through a special contents page.
• I still have to ensure that searching and indexing doesn't include proofing documents. That'll need a bit of work. It might be a better approach to store them in a separate collection, and write handlers based on the collection.

Met with RS, KA, and two of the OJS folks to discuss our development plans. My task is to get stuck into the conversion XSLT for teiJournal to NLM, and also to familiarize myself with the XML Galleys plugin for OJS.

For the last little while, we've been talking to the Open Journal Systems guys about integrating TEI support into OJS, and adding code to produce PDFs from XML in OJS. This is pertinent especially now because our library is touting for UVic journals to put into their OJS system (IK is the contact there), and ETCL is beginning markup of DHCN journal articles for generating PDFs, using my teiJournal system. Over the last week or so, we've been discussing this in detail on email, and it looks as though a collaboration will take place.

My initial task will be to work with KA as she marks up DHCN articles, to expand and nail down the TEI schema for journal articles, and then to write a converter to NLM. NLM is already supported by OJS, so we should be able to use that as a method of adding TEI support without too much pain.

This post is to begin logging the time spent on discussions and planning, and then on coding.

I noticed that the menu was incomplete on the IALLT Journal site. A little poking around revealed that it was an XQuery problem related to testing the equality of strings. If I do this:

declare function f:buildMainMenuItems() as element()*
{
    let $site := collection('/db/teiJournal/site')//TEI[@xml:id='sitePages']/text/body
    for $div in $site/div
        return (
             if ($div/@rend = 'link_only') then
                 <li><a href="{$div/head/ref/@target}">{data($div/head/@n)}</a></li>
             else
                 if ($div/@rend != 'page_only') then
                     <li><a href="site.xhtml?id={$div/@xml:id}">{data($div/head/@n)}</a></li>
             else
                 ()
        )
};

then the "not equals" test will fail for some reason; it even fails if I use compare(). However, if I turn the test around:

declare function f:buildMainMenuItems() as element()*
{
    let $site := collection('/db/teiJournal/site')//TEI[@xml:id='sitePages']/text/body
    for $div in $site/div
        return (
             if ($div/@rend = 'link_only') then
                 <li><a href="{$div/head/ref/@target}">{data($div/head/@n)}</a></li>
             else
                 if ($div/@rend = 'page_only') then
                     ()
                 else
                     <li><a href="site.xhtml?id={$div/@xml:id}">{data($div/head/@n)}</a></li>
        )
};

then it works. I'm not sure why; perhaps it's something odd in the way eXist handles string comparisons, or perhaps it's because I'm comparing a node instead of its text, but in that case I don't see why the equals should work either. In any case, it's a live site, so I had to do a quick fix to get it working. If this shows up on any other site, it'll be worth figuring out the problem.

More struggles trying to get authentication both working and pretty. At one point the site crumbled, and we had to restart Tomcat; two restarts of Cocoon alone, from the TC manager, seem to throw it into disaster. Finally we settled for functional but ugly. I need to work closely with Bruno to build in some proper authentication, in the long term.

Added a new page to the site.xml file, and tweaked the menu/site pages system slightly, so that you can now have a page which explicitly does not show up on the menu. This is for an access-denied page, but there are other circumstances in which this would be useful. Also added a link from the top of articles back up to the TOC page.

The requirement to authenticate users through their IALLT credentials before letting them access the content eventually came down to an IP address restriction, which would enable the IALLT server to get our content and serve it on to its authenticated clients, and no-one else to access it. After much research, and struggling with the remarkably unhelpful (in this respect) Tomcat 6 documentation, we seem to have figured out how to do this.

The key is to create a Context object for the web application, and then apply a Valve (actually, a <RemoteAddrValve>) to control access to the <Context>. There are various ways to create a Context, but on a default Tomcat installation, you need to know that the default Engine name is Catalina, and the default Host name is localhost. Then, you go to [Tomcat]/conf, and create a folder structure inside it consisting of [Engine name]/[Host name]. So in our default setup, we end up with:

[Tomcat]/conf/Catalina/localhost

Next, you create an XML file inside that folder named for the Web application you're trying to protect. In our case, the Web application is called ialltjournal, and so the filename is ialltjournal.xml. That file needs to look like this:

<?xml version="1.0" encoding="UTF-8"?>
<Context>
   <Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="192.168.*,142.104.128.*"/>
</Context>

The only bit of the file you would change is the allow attribute, which consists of a list of regular expressions, comma-separated, which match IP addresses or ranges which you want to allow to access your content. You can also use a deny attribute instead, if you just want to block some ips.

Then you have to restart Tomcat (restarting the web application doesn't seem to be enough).

Stuff we don't yet know, and are still investigating:

I think it should be possible to make a Context more sophisticated by using a path attribute on the <Context> element, so that the restriction might be confined to specific folders or paths. However, I haven't been able to make that work.

Added an XML link to the article rendering, allowing the reader to view the XML markup.