teiJournal

Spent half an hour playing with it, and found it's not going to be practical for what we want to do. The GUI is too slow -- no AJAX, just form submission, and wait, and eventually get a page back. It's going to be quicker to provide online templates ourselves, I think. Worth checking out EndNote first, though.

We have the OK to go ahead with this project, so I've created a blog for it. I've migrated all previous posts from the Depts blog over to this one (tedious process in phpMyAdmin -- needs a GUI!).

One of the major tasks in this post is to figure out how to link <cit>, <q>, <quote> and <bibl> tags to the xml:id attributes of <biblStruct> elements containing details of the cited work. The key attribute is not available on these tags, so we're left with three options:

1. ana: indicates one or more elements containing interpretations of the element on which the ana attribute appears.
2. corresp points to elements that correspond to the current element in some way.
3. n gives a number (or other label) for an element, which is not necessarily unique within the document.

The first smacks of tag-abuse, because it's really meant to point to an analytical interpretation. The third is a multi-purpose attribute which is available almost everywhere. corresp seems most appropriate, especially for <bibl> tags (it's less suitable for the other tags, but it would do at a pinch).

Adding this as a task, because I need to search the TEI-L archives for any discussion of this before, then lay out my proposed solution (corresp and get comments.

I broke down the initial phase of the project into individual tasks and estimated hours for them, then wrote to Peter to see if he thinks it's worth going ahead with it.

Finished the document on bibliographical markup, made a couple of changes to the implementation document, and then made a start on the detailed timeline. In the process, Greg and I discussed and researched several issues:

Secure logon: this can only be handled by turning on SSL in Tomcat; this enables any page to be accessed through https. If the user does this, we can give them an option to make use of it in the application, whereby sensitive documents would only be rendered if their access URL was using https. The default install will have this turned off, because we can't control or detect the user's Tomcat setup.

Building a WAR file package: Greg has now mastered building Cocoon with eXist as a block, so we can go this route. We can turn on all the blocks we want and exclude all the flaky ones. The only remaining issue is how to inject our website materials into Cocoon, along with the sample database, after building. Perhaps we can just edit the contents of the WAR file (which is just a zip).

Spent most of the day working on the presentation on teiJournal, creating graphics, diagrams and so on, then paring it down to something that will go for 20 minutes. It could be prettier but it's to the point.

Wrote the outline/plan for the presentation. I'll flesh it out with text and graphics tomorrow.

As part of the teiJournal plan, and because it also helps with creating my presentation for Friday's Vancouver trip, I wrote the next part of the project description, the description of output formats. The idea of the user-configured ad-hoc anthology is beginning to get clearer.

One key aspect of teiJournal will be the ability of the editor to configure as much as possible of the presentation information through a user-friendly interface. There is so much to configure that the key problem is going to be organization and storage of this information. One way to think of this is as "style blocks", each of which controls a particular aspect of a particular presentation format.

Typical blocks would be: the default format of bibliographical info (Chicago?), layout of each format (e.g. running titles), the content of each format, and the abstracted and user-configurable aspects of each output type (font, style, page size and other choices, especially for PDF).

Style block code will find its way into two kinds of output: XSL:FO (for PDF), in which it will be inserted inline, and CSS, where it will control the display of predefined XHTML classes. The most convenient way to store this information will be as XSL Attribute Sets. Since these are XML, they can be stored directly into the database, and read easily. The data itself is going to be a combination of CSS and XSL:FO attributes and values; we need to come up with a template-based GUI for editing it.

Finally, there will be some types of style choice that do not translate into CSS or XSL attributes. For instance, the choice of MLA or Chicago formatting for bibliographies or references will be a choice between two blocks of rendering code. There may not be many of these.

Including time spent working this out so far.

We have a set of sample documents ready for use in the teiJournal project here. However, a number of issues remain to be resolved with regard to the exact details of the markup practice:

1. There is too much duplication, especially of author and title information. It should be possible to limit this, perhaps by eliminating some elements, or (better, perhaps) by using XInclude to automatically include information from the formally-structured <biblStruct> element in the header into the main header <titleStmt> and into the document's <front> tag.
2. There are some unresolved issues with regard to marking up quotations. Where a quote is followed immediately by a reference, they can be enclosed neatly in a <cit> tag, but when the reference information is introduced discursively in the text, it's harder to tie the quote to its reference. We need to investigate ways to do this, using attributes and ids, then write formal instructions for it.
3. There should also be a way to tie a <bibl> tag to the full <biblStruct> tag in the bibliography.
4. We need to look at how to formalize the classCode system, and then XInclude that information into the header of each document.
5. Running titles must be allowed for, but it's not clear exactly how we should do it. The best approach might be to use the type attribute to supply other title types in the <biblStruct>.