In IE7, the popup div appears above where it should. IE's interpretation of offsetTop seems to differ from everyone else's. That'll need a fix, and while I'm doing that I can add the fix for the popup scrolling off the bottom of the page, which will also require some browser-specific code, I think.
March 29, 2007
Spent most of the day working on the popup functionality which enables you to read in either the apparatus or the poem, and get popups from the other.
The basic idea is simple, and it took no time at all to get popups of notes from the apparatus in response to clicking on note anchors in the poem. There were only two small wrinkles there: first, because we're cloning the note node, we need to make sure any ids in its contents are replaced with new unique ids, otherwise the document structure will be violated. Wrote a recursive function for that. Secondly, since notes are list items, when they're cloned they need to be wrapped in a list container element (in this case <ul>, so that they don't end up with a different number).
Getting an appropriate segment of the poem to pop up is a different kind of problem, though. The issue is that the note anchor is usually interleaved with other tags, inside the poem div. There's no point in popping up the note anchor itself; it's just a number. What you want is the element to which it refers. That's not its parent, in the case of this document. Personally, I'd say that it should be -- the <note> tag should be inside the <l> or <lg> tag to which it refers -- but in this document the note can be a sibling of the <lg> tag. Its immediate parent is the entire poem, so that's no use. What I ended up doing was getting a list of elements which are children of the note anchor's parent element, then filtering out all which are not either the note anchor itself, or <div> elements. Then I was able to choose either the preceding element in the list (if there is one), or the following element, and pop that up. Generally, that means a line, but sometimes it's a stanza.
This would have been a perfect job for the DOM Traversal API, but it's not widely supported, so I had to do it manually.
Then I tested on other browsers, and found two bugs in IE7 that I had to work around:
- DOM level 3 says that when you ask for Element.getAttribute('blah'), if there is no such attribute, you should get back an empty string. However, IE gives you back null. If you then test for length, you get an error. So now I check for null before checking for length.
- ID7 doesn't seem to define, or provide access to, the node type constants (e.g. Node.ELEMENT_NODE), which we use to determine what type of node we're dealing with. I had to revert to using hard-coded integers (in this case, 1).
With these fixes, everything works on Firefox, IE7, Opera, and Safari. Next steps:
- A fixup to ensure that when the popup is off the bottom of the screen, it moves its bottom up to where its top was. This will be finnicky because of IE's oddities, but we've done it before.
- Fading out the poem or the apparatus when a popup shows up. This is cosmetic, but significant from a usability point of view, and will be interesting to do. Again, I predict problems with IE's opacity handling.
Met to discuss the plan and implementation:
- A feature structure array will be created for people.
- Each person's feature structure will initially contain a pointer to their entry in the Library of Congress Authorities
- Each name tag in the text will be identified with a
keyattribute pointing at their feature structure. <reg>tags will be removed, and dates will be moved outside the<name>tag.- People identified as authors will have their name tag wrapped in an
<author>tag in the<head>of the poem attributed to them. - TOC code will display names from all
<author>tags found in the head of a text. - Proper bios will later be added to flesh out the feature structures, and the genealogical database will be linked in.
While this is being done, I'll concentrate on making the poem+apparatus display work as proposed in my previous post, with the addition of a splitter between the two columns so that users can resize the columns.
Following this, collation information will be generated using Collate, and then Mike and I will work to process this using PERL into well-formed XML, and thence via XSLT into a block of TEI XML suitable for dropping into the <head> tag of each poem. Then my apparatus code will include this information in a simple textual view, like a traditional scholarly edition. Later, we will work on converting this to a formal TEI apparatus, with more adventurous rendering.
Posting time in the meeting, and minutes spent documenting it.
Link: http://etcl-dev.uvic.ca/~cmleitch/v-machine/ahrobyn/ahrobyn.html
The versioning machine that Cara published, using Ah Robyn as an example.March 28, 2007
This task is now complete; its status should be changed from Outstanding to Completed. Posting the minutes spent on that.
I have the poem displayed on the left, with line-numbering; I have note anchors floating to the right of the poem, numbered; and I have the beginning of the apparatus showing on the right, with notes and note anchors linked. Before we go any further, it would be prudent to decide on a layout. These are some considerations:
- Ray's explained that it's important from the point of view of the publication that the apparatus be readable as a continuous flow of text, as it would be in a traditional edition (although in a traditional edition it would be broken across pages).
- From a usability point of view, that's a poor way to approach the design, because it's going to lead to multiple scrolling panes. Readers are likely to prefer to work within one scrolling page based on the text (as they do in a printed book), and access information from the other as they need to, by clicking on something.
So I have an idea. Imagine the poem and the apparatus appearing side-by-side, as if they're in columns on the page. Now, when you click on a note anchor in the text, the apparatus fades into the background (although it's still visible), and the content of the particular note you requested appears next to the point where you clicked, on top of the apparatus. If you click elsewhere in the faded apparatus, the popup note disappears, and the whole apparatus column is now clearly visible again. This is the scenario if you're reading the poem and referring to the apparatus.
Now imagine that you're reading the apparatus and referring to the poem. You click on a note in the apparatus. The poem text fades into the background, and a copy of the block (probably a line-group) which contains the note anchor now appears on the left, on top of the faded poem, next to the point in the apparatus where you clicked. Clicking on the faded poem dismisses the popup and brings it back to the foreground.
This solution allows for multiple reading approaches, and yet leaves both poem and apparatus on the screen for scanning or printing. I don't think it would be too difficult to achieve. What do you think?
March 27, 2007
Worked most of the day building a flexible TOC system which allows sorting (ascending and descending) by title, type, hand and author. The variation in encoding of authors was a little problematic; to get a valid sort, I had to do this:
<xsl:sort order="ascending" select="normalize-space(lower-case(string-join(tei:head/tei:bibl/tei:name[1]//text(), '')))"/>
The hand issue is another interesting problem, because many poems continue in the hand of the poem preceding them, so they don't actually contain a <handShift> element at all; eventually I figured out that what we have to do is go to the end of the poem (its final element), then look back using the preceding axis to find the first handShift that appears:
<xsl:sort order="ascending" select="lower-case(descendant::*[last()]/preceding::tei:handShift[1]/@new)"/>
The TOC page now works, and you can click on the headers to sort the list, although it's all unstyled HTML at the moment.
This poem provides more interesting meat for the name controversy:
<bibl> <title type="incipit">And now my pen alas wyth wyche I wryte</title> which is Book <num type="Roman" value="4">IV</num>, lines <num>13-14</num> from <title type="source">Troylus and Creseyde</title>, also known as <title type="incipit_alternate">The double sorwe of Troilus to tellen</title>, by <name>Geoffrey Chaucer</name>, which is based on <title>Rime <num>132</num> <title>If love be not o Lord what fele I so</title> ( <title><foreign xml:lang="ita">S'amor non è</foreign></title>)</title>, also known as <title type="alternate">Troilus' song</title>, which appears in <title type="main">Troylus and Creseyde</title> as Book <num>I</num>, lines <num>400-420</num> by <name type="personal"><reg>Petrarch, 1304-1374</reg></name>.</bibl>
Here, Geoffrey Chaucer has no <reg> tag at all, and it's not clear whether he, or Petrarch, ought to be listed as the author for this piece.
Karin suggests that authors are not so important in this document, and so the TOC need not list them. That would make my life easier, of course, but I think one way or another readers are going to want to be able to find texts based on authorship, no matter how disputed or uncertain, so even if they don't appear in the TOC, we'll have to deal with this problem.
This post moved to the: wiki
The following poem div is missing its type attribute. I think it should probably be type="poem".
<div xml:id="LDev020-TM1061-TP1168" rhyme="40:8x5 aabaB8 ">
In an effort to find a way to inject a single rend attribute into the root of the DMS document when it's retrieved from the database (which I'd like to do so that I can pass that on to XSLT processing, for e.g. sorting a TOC), I ran up against yet another infuriating problem with xmlns "attributes" on serialized XML. After struggling for a while, I posted this explanation and request for help to the eXist list:
I have a simple TEI document that starts like this:
<TEI xmlns="http://www.tei-c.org/ns/1.0">
<teiHeader>
<fileDesc>
<titleStmt>
.... and so on.
I query it using a simple XQuery like this:
declare default element namespace "http://www.tei-c.org/ns/1.0";
declare namespace ....
....
<TEI xmlns="http://www.tei-c.org/ns/1.0" version="5.0"
rend="{request:get-parameter('rend', '')}">
{doc('/db/devonshire/DMs_P5.xml')/TEI/teiHeader}
{doc('/db/devonshire/DMs_P5.xml')/TEI/text}
</TEI>
(What I'm doing here basically is just inserting the request parameter
"rend" into the root as an attribute. I expect to get something like this:
<TEI xmlns="http://www.tei-c.org/ns/1.0" rend="title_asc">
<teiHeader>
<fileDesc>
<titleStmt>
...
but what I actually get is this:
<TEI xmlns="http://www.tei-c.org/ns/1.0" version="5.0" rend="">
<teiHeader xmlns="http://www.tei-c.org/ns/1.0">
<fileDesc xmlns="http://www.tei-c.org/ns/1.0">
<titleStmt xmlns="http://www.tei-c.org/ns/1.0">
...
In other words, every single element now has a redundant xmlns
"attribute" attached to it. This is what happens if I serialize the XML
using the standard Cocoon XML serializer. If I do the query in the eXist
client query window, I don't see the extra xmlns attributes. I'm
wondering whether these are added by the Cocoon serializer, and if so,
why? Is there anything in my query that would trigger such behaviour? If
I replace the query with this:
doc('/db/devonshire/DMs_P5.xml')
then I don't see the problem. Removing the default element namespace
declaration from the xquery file makes no difference at all.
I have a feeling this is something to do with the eXist XQuery generator for Cocoon, but I'm not sure yet. For the moment, I have to live with it, but it's annoying, and it makes the serialized XML document much larger than it should be.