Devonshire

Karin and I have had three or four discussions over the past week on TEI markup, as she's in the process of updating the markup. Some of these have spilled over into questions to the TEI list, and a bit of research time, so I'm posting the cumulative time just so we keep track of it.

I've written the output code to handle names, linking to their references in the name list. To do this, I first made three small edits to one poem in the transcription document, to add the appropriate key attributes to the <name> elements, pointing at the xml:id attributes of the <person> elements in the header. I've made no other changes to the name elements, leaving the current text of those elements unchanged (see my previous message). These changes enabled me to work on the output code for a specific poem.

This is what now happens with name elements:

• When the XML document for a single poem is being generated, the XQuery code looks for each <name> element in the code, and for each distinct value of their key attribute, it retrieves the appropriate <person> element from the names file in the database. It includes this list of <person> elements in the header of the poem's document. This means that the XML view of each poem is complete and internally consistent (in other words, each person mentioned is fully documented in the header).
• When the HTML view is created, each <name> element is turned into a bold, clickable span. It has a tooltip which consists of a the short form of the bio, and if you click on it, a full bio pops up.
• The full bio contains most of the information in the names database. There are some items that aren't yet in there (such as <genName> elements, and notBefore and notAfter attributes) because I'm not really sure how best to present them. Those are simple tweaks to make.
• If there's a DNB reference, it's turned into a link to the DNB entry.
• If there's an LOC reference, it's displayed as text. I don't know how or if it's possible to link to the LOC information online -- any ideas?

The sample poem which works is here. Let me know if this is along the right lines, and if you have any suggestions for the issues mentioned above, let me know.

Currently, trailers/closers are encoded using <note type="scribal">, which meant that they were being treated as part of the apparatus. This will change when they are re-factored into <trailer> and/or <closer> tags. I added some XSLT which picks up both the current encoding and both the future options, rendering this text as part of the transcription rather than the apparatus, and excluded it from the apparatus.

Karin has provided an excellent supplementary XML file containing two <listPerson>, elements, one tagged as "historical" and one as "modern", containing details of all individuals associated with the MS and the project. This will enable me to provide full details of any individual from any point in the text where a <name> tag shows up.

In order to make this work, each <name> tag in the transcription document will have to be given a key attribute pointing at the xml:id of the <person> tag which contains the information for that person. There are 363 name tags in the document, so this is no small task.

It's a little complicated by the fact that <name> tags occur within discursive text, and typically contain some of the information that the <person> tag has. For instance, consider this code block:

<bibl>
   <title type="incipit">I may well say with Ioyfull harte</title>, attributed to 
  <name type="personal">
    <reg>Margaret Douglas, Countess of Lennox, 1515-1542</reg>
  </name>, on her marriage to 
  <name type="personal">
    <reg>Thomas Howard, Lord, 1512-1537 </reg>
  </name> by 
  <name type="personal">
   <reg>R.G. Siemens</reg>
  </name>.
</bibl>

It's straightforward to add the key attributes (DOUGLAS, THOMAS_HOWARD, and RGS respectively), but we have to decide whether the inline discursive information contained in the <reg> element, which in two cases includes honorific and date information, should be left as it is. The idea of centralizing the person information is that it can be updated in one place. Therefore, it would make sense to remove all that information, and replace it with a simple tag like this:

<name key="DOUGLAS">
 Margaret Douglas
</name>

The name would then be turned into a link; mousing over it would pop up some simple info (full name and dates?), while clicking on it would show a larger popup with full details of the person.

I don't see that we need the type="personal" designation -- can anyone see a value in it? The fact that the key attribute points to a <person> tag makes that information clear.

Does this make sense? Although it may take some time to make all the changes to the transcription document, I'll need to know how the changes will be made in order to write my code to link names to the info in the person lists.

These issues are relevant to me:

• Spaces between stanzas will be denoted using the <space> tag instead of using notes, as they currently are. This will have the effect of removing many notes which are currently cluttering up the apparatus.
• The rend attribute will be rationalized, and the range of its values reduced. For now, one thing I should do is to write my code so that it ignores all varieties of "smcap", but doubles the font size for "lgcap". Adding this as a task to make that happen.
• The type attribute on <div> tags will be rationalized, so that all poem-type divs will have a value beginning with poem_. Other values for type will be collective, which is the main container div for all the poems, notation, which will be for inline comments (usually in another hand), and notation_marginal, which is for marginalia. The last two should show up as children of a poem div, so they will need to be rendered by my code in some way.
• Trailers will be encoded using <trailer> or <closer> tags, and my code will have to render these too as part of rendering poems.
• People will be listed in a <particDesc> element in the <profileDesc>, as a <listPerson>. Each <person> tag will be linked to one or more online sources (the DNB or LOC) using an <ident> tag, distinguished by type="DNB" etc. Karin will create this list of people, and I'll pull relevant items from it to place in the XML document for each individual poem, and render the info into the apparatus.

Posting minutes spent discussing and documenting this.

• Smartened up the TOC display rendering a bit. It's not yet pretty, but it makes it easier to look at while I'm working.
• Added handling for <figure>s. This is basic; the problem is that these tags appear inline, inside <note>s, and inside <seg>s. The markup will need to be regularized before we do a proper job of this.
• Added handling for regularizations, using popups.
• Added handling for deletions. This is rudimentary at the moment. We'll need to do some thinking to come up with something imaginative.
• Added handling for <hi>. There are lots of variants of the rend attribute, but I think I've handled all of them.
• Tweaked the CSS a bit to make things clearer.

Made some significant steps today:

1. Rewrote the XQuery that retrieves a poem in XML, so that it also harvests all feature structure elements from the feature_system.xml file which correspond to abbreviations in the text of that poem. This goes some way towards giving us a working independent XML file for each poem, which is good in itself, and gives us the basis for rendering info about the abbreviations.
2. Added rendering of the abbreviations to the XSLT. What this actually does is to provide a visible span with the expansion, followed by a (normally) invisible span containing details harvested from the feature structures in the header.
3. Added CSS code to support the abbreviation code.
4. Added JavaScript to show the information about the abbreviation. Spent a while tweaking this so that it looks reasonable even when key pieces of info are missing (which is often the case).
5. Tested on all the regular browsers -- no problems, except for some anti-aliasing issues on IE7, which probably aren't worth worrying about at this stage.
6. Added more meaningful menu, with links to the DMS home page, the poem index, the blog and the wiki.

Next we should make it look a bit prettier, and after that, perhaps go back to the idea of the slow fade.

My browser detection for using the IE-specific filter setting instead of the CSS standard opacity value was based on document.all, which doesn't really make sense. Since all we care about is opacity in this code, I've substituted this:

if (typeof [theObject].style.filter !='undefined')

The idea comes from this page on the Opera site, but the method shown there for setting the opacity:

[theObject].style.filter.alpha.opacity = 100;

doesn't work in IE7; I had to use this instead:

[theObject].style.filter = 'alpha(opacity=100)';

This is a precursor to working on the slower fade-in and fade-out.

Worked on making the apparatus fade out when you're reading in the poem, and vice versa. The opacity issues are fairly straightforward: as usual, IE is the rogue component, because it doesn't support opacity according to the specs, so what I've ended up doing is this (where lastFadedObj is the object being faded out):

    lastFadedObj.style.opacity = '.2';
//Hack for IE
    if (document.all){
        lastFadedObj.style.filter = 'alpha(opacity=20)';
    }

The other problem was identifying the poem and apparatus divs themselves. Because of the possibility that poems might share the same page in some views, they have unique ids, so they can only be identified by part of their id or by class. This is working OK, but I think it needs to be refactored in future; I'd prefer to be using the unique component of the ids for this task, so that if you were looking at multiple poems, the code would still work specifically to the poem you were clicking on. I've prepared for this by wrapping both the poem and apparatus in a <div id="LDev001-TM1479" class="poemAndApparatus"> </p>; this will allow me to go up the tree from the sender of a click event to the ancestor container, and then collect its id, and use it to find the child container which needs to be faded.

Tested the code on all the usual suspects, and it works well in Opera, Firefox, IE7 (with special fixins), Safari and Webkit. Konqueror is odd in three ways, though: first, it offsets the line-numbering by one line, for no reason I can see; second, it doesn't respond to the fading code; and finally, perhaps as compensation, it's the only browser that DOES correctly show the alternate table row shading from CSS3's nth-child settings on the TOC page; all the other browsers ignore this.

Next is to refactor as above; then animate the fading. After that, we need to work on the abbreviations, which are an interesting challenge.

Simple solution based on findPos() from Quirks Mode. Basically you have to recursively climb the tree from the target element adding the offset positions, so that whatever model the browser uses for offsetParent (which is where the differences are), the results are the same.