These are some points emerging from the editorial meeting:
<seg>elements with an
@anaattribute pointing at a list item element in the back of the document, like this:
[main doc] ...<seg ana="#blah">bleoh</seg>... [back matter] <list> ... <item xml:id="blah">blah, blah blah</item> ... </list>This will allow centralization of glossing, so one gloss can be referred to many times; and it will also allow us to generate links from the glossary back to all the items in the text.
<head>of a poem will be unified into a single, multi-paragraph editorial note, which will be rendered distinctly based on its context.
<note type="annotation">. They often contain editorial notes, but these can presumably be rendered as normal, if their position inside marginalia doesn't cause problems.
Following our decision that projects like this ought to be able to function as standalone Cocoon-based Webapps, I've created a standalone version of the application living on the Lettuce Development Tomcat. We discussed whether this should be using Tomcat authentication, as we did for the IALLT Journal, but there are reasons to stick to the rather hokey Cocoon-based authentication we have, and in fact to improve it. If we do Tomcat-based authentication as described here, then there's a co-dependency between the roles defined in the Tomcat users file and the web app's
web.xml file. This means the project isn't actually portable at all.
All in all, it's time I properly mastered Cocoon authentication; this is an opportunity to do it.
KA raised the issue of what precisely is meant by the "URI" content of the
@corresp attribute. According to the guidelines, the value is one or more of data.pointer, which is defined by RFC 2396. This is identical to the data type of
ref/@target. The RFC does not mention XPath (it dates from 1998). According to the RFC, these are the components of a URI:
URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
However, the guidelines go on to specify a range of different options for the fragment component, including the use of XPath. According to the current incarnation of the guidelines (or at least, my reading of it), because the first component (absolute or relative URI) is optional, and its absence means that the current document is the target, we should be able to use XPath as in the following example:
I think it's the case that my original formulations for the Devonshire look like this:
So we need to prepend the hash.
The current version of the DMS is running as part of the single Cocoon/eXist stack on the main Tomcat on Lettuce. As part of our policy of separating out individual projects, I've started building a distinct Cocoon instance for it on the DEV tomcat. I got the latest 1.2 release of the Cocoon/eXist WAR file, unrolled it on Tomcat, and then brought down the resulting tree and made the edits to config files, jar repositories etc. which are listed in our previous instructions. However, I can't re-upload the changed files yet, because the default directory in which stuff is unrolled by Tomcat ends up being owned by apachsrv, so I have no write permissions. Still waiting for sysadmin to fix that for me.
Got three new apparatus files from CL (two brand-new, one replacement), and integrated them into the site. In the process, I discovered that P5 has changed the tag name
<listWit>. This doesn't affect much, but I changed all the existing files and tested everything to be sure.
Carried out the following changes in consultation with KA and MC, through an XSLT transformation, to bring the document into conformance with the current status of TEI P5:
<sourceDesc>, with minimal required children, to provide a location for
sourceDesc/msDesc/physDesc, and all child
<hand>elements to handNote.
g/@type, by replacing them with underscores.
@typeattributes pointing to folios to
@targetattributes pointing via XPath at the relevant
<revisionDesc>list item to describe these changes.
Editorial note anchors (numbers) are no longer floated to the right of the poem; this takes them too far out of context, and sometimes wraps them to another line, which is not good, and also it prevents proper display of anything when an editorial note is embedded in a scribal note (an "annotation"). Scribal notes are now positioned correctly as far as I can tell, and should work OK by and large, although there's not necessarily always enough space for them in the margins, and some can never be handled adequately (such as the one which is "vertical(ascending)".
A couple of titles were missing from the index page, and the contents of the last "poem" (an excerpt) were not showing up. This was because the XSLT was looking for a
title[@type='incipit']; it now uses any title element it finds if there's nothing matching that. The body of this excerpt is les than a line, so it was wrapped in an
<ab> tag rather than
<l>; I'm now handling
<ab> elements in the XSLT too.
There's a wide variety of distinct values for @rend attributes. Some of these are combined, and many overlap between
<seg> tags. I've taken a shot at providing some kind of decent rendering for most of the ones that can be rendered meaningfully; some which can't are ignored, and still others are awaiting conversion or normalization to another form of markup.
This was another empty-span-tag issue, caused by the combination of Cocoon and Firefox. Cocoon spits out empty tags as self-closing tags (which is wrong according to W3C guidelines), and Firefox screws up rendering when it encounters a self-closing tag which can have content, such as
<span/> (which is annoying but at least draws our attention to the problem). In the case of this error, the empty span tags were caused by lines which have no number (i.e. no
@n attribute), because they're in some way a refrain or a tagline that shouldn't be numbered. Fixed this by adding non-breaking spaces where there are no line numbers.
:: Next Page >>
|<< <||> >>|