Mariage

This is a quick guide to how the information appearing in the table of contents is harvested from the documents themselves (so you know where to look in the document if something's wrong in the TOC):

• Most of the info comes from /teiHeader/fileDesc/sourceDesc.
• The title comes from biblStruct/[monogr or analytic]/title[@type='trunc']
• The author name comes from /biblStruct/[monogr or analytic]/author/name/reg
• The date comes from /biblStruct/monogr/imprint/date
• The teaser comes from the <bibl> element that follows the <biblStruct> element.
• The document "type" comes from /teiHeader/profileDesc/textClass/classCode

Our practices for linking between documents have grown by accretion, and have now reached a point where they're confusing and complicated. They need to be re-thought and re-coded. This is the beginning of a process of thinking through the issue.

This is a list of all the types of linking we do:

• Linking from one document in the anthology to another.
• Linking from one anthology document to a specific anchor in another anthology document (by @xml:id).
• Linking from one anthology document to
• Linking from an article to a bibliographical reference inside the same article.
• Linking from an article to a bibliographical reference in the central bibliography.
• Linking from a document in the database to an entry in the references files.

These break down into two basic types:

1. Linking to other documents in the collection (moving to another page).
2. Linking to fragments that should show up as popups inside the current document.

What I propose is this:

For both cases, we need a practice which references other documents (and fragments in them) based on a real model of the database collection structure (which is just a file-system structure). This will enable validation, but because we're using usefully-named collections, it will also enable the processing code to access items efficiently. In the second case, we can rely on XQuery to retrieve and inject all the items we want into the document that's linking to them before processing.

This is what references would look like:

• A biblio reference in an article:

     <ref target="../biblio/biblio.xml#timmermans_1993">Timmermanns 1993</ref>
  

  . This points to the bibliography collection (biblio) and the biblio.xml file within it, and identifies the entry which is required. It climbs up the tree one level before going down to /biblio/ because articles are in the /articles/ collection which is a sibling of /biblio/. Here, the processing code can easily retrieve the item through the relative path, and also knows what kind of item it is because it's in the biblio collection; thus we have no need of a type attribute on the <ref> element.
• A link to a reference ("allusions/notes" entry) from a document in the anthology:

     <ref target="../../references/references.xml#achelous">Achéloos</ref>
  

  Here, the link comes from a document in /db/anthology/texts_original/ collection; to get to the /references/ collection, we need to go up two levels and then down. The tag identifies the reference as being in the references.xml file. We do have multiple references files, in fact, and occasionally references move from one to another, but the backend processing can be very robust in this situation because it can ignore the file name and simply retrieve the <div> element with the requisite @xml:id.
• A link from an article to a document in the anthology:

     <ref target="../anthology/texts_original/advis_salutaire.xml">Advis salutaire</ref>
  

  Again, we specify the subcollection (texts_original) explicitly for precision's sake, but the processor will know that all anthology document xml:ids are unique, so it can construct a relative link in the XHTML based purely on the id.
• Linking to a fragment or anchor in another document:

     <ref target="../../anthology/images/invention_femmes_2#scalpel">Invention des Femmes (2)</ref>
  

  Here we might actually be linking from within the same collection, but we go up the tree first for absolute clarity. If we go up to the root of the tree every time, we have a degree of robustness to withstand the moving of documents into different subcollections, because we can always assume when processing the URI that the first component of the path is the first subcollection under the base "mariage" collection. Note that this kind of linking requires that the target element have an @xml:id attribute, and that this is converted into an id attribute in the output XHTML. We need to ensure that this is always the case, which may mean restricting the range of elements that are normally linked to, so that the XSLT can be sure to pass through any @xml:id it finds. There are situations in which an underlying TEI element does not result in the generation of an XHTML element in the output, which would preclude the passing through of an attribute because there would be nothing to put it on.

Multiple linking is handled the same way as in these other cases; @target can take multiple space-separated URIs. Of course, this is problematic for processing, since an XHTML link can only point at one location, but we can probably handle this with a "see also" kind of structure that's automatically added after a link where there are multiple targets.

So much for encoding. Next, we need to handle processing and rendering.

For fragments intended to be used as popups, all the content should be retrieved by the XQuery and inserted into a <back> element of the document. Since there can only be one <back> element, and the original markup itself might require one (we have no such examples yet, but we may), this many need some rethinking; we may need to insert the content at the end of the <back> element. Whether or not this content is displayed at the end of the document by default is problematic; we need some simple rules that can be applied both to articles and to anthology documents, and this is by no means easy; but in most cases, notes-allusions information from the references collection will be linked from anthology documents, and bibliographical info will be linked from articles, so we could default to displaying biblios and hiding notes-allusions.

In any case, all types of popup content should be displayed in exactly the same manner, using the same mechanism. Anything else is confusing and fragile. We need one box which shows up on the right, of a reasonable size, scrolling, and position: fixed. Content going into that box should be cloned from the content in the target element; this allows us to leave the original content visible (and printable) at the end of the document while we're also displaying it in the margin.

One issue remains to be solved: inline notes, which are <note> elements. These also need to be displayed as popups, and ideally they would use the same mechanism. There is a need to link to these notes, however, so they will probably need to be handled differently. They can presumably be rendered inline but hidden, at their original position, and styled to be marginal but not position: fixed; then when they're linked to, they'd automatically pop up through an onload event.

This looks like a plan. It involves considerable changes, but most can be accomplished through search-and-replace or XQuery, and the simpler rules will be easy to teach and give us better XML and a better interface.

Created a new collection called "intros" and a document called intros.xml, which has the introductions for the three tables of contents. This is marked up and rendered such that the larger part of it is initially hidden, and revealed by clicking on a link. Cleaned up the menus a little by removing dates.

I need to implement the code for popping up biblio references in response to a click; there's one example in one of the intros which will do as a testbed, and the code should then carry over to the article rendering when I get to that.

I've also normalized all the <classCode> values, which have been in flux from the beginning, such that they're comma-separated values (for the moment), including "roman", "fiction", "prose", "vers", "satire" and "gravure", in various combinations as suits the document. This may need revisiting, as will the search page Genre drop-down, which uses distinct values from this element; it should use distinct values from the comma-separated whitespace-normalized fragments, so that you could search just on "prose" or "vers".

Lots of instructions from CC for changes to the menu (implemented, but I'm not sure they're an improvement yet), TOCs (we now have satire, fiction and engravings), and the beginnings of some work on introductory material for each of the individual TOCs. The problem I'm having now is that the intro material will actually have to be stored in the db and retrieved, rather than encoded directly into the XSLT, because it's lengthy and full of formatting. I'm going to have to create a TOC document to encapsulate it, then tweak toc.xq to retrieve and render the right bit. That'll take a while.

Team meeting today -- my notes:

• All the Cabinet Satyrique transcriptions are now drawn from the version of the anthology which doesn't have satirical publication info. That's a blessing. The old ones will be updated from the new transcriptions. LCC is doing that now.
• The newer, clearer biblio info in the header of the first Cabinet poem to be updated threw up some weaknesses in the XSLT processing the table of contents, and also raised again the problem of mixed content in teasers not being rendered in the right order (an XQuery issue). I've now solved both of those problems; the one was a simple XPath fix, and the other I solved by trying a solution that failed in the old db version but now works; my original XQuery solution is vindicated. Mixed content now works in teasers.
• Footnotes from the 19th-century anthology should be marked up in the same way as our own editorial footnotes, but distinguished from them by some appropriate introductory text which specifies their source.
• Decisions on exactly how the modernized texts should be used in Search are still pending; there are various problems there, which we discussed. In the meantime, though, if there is a modern version of a text, a link to it should be provided in the XHTML view of the document. This will require some re-organization of the db structure, and rewriting of XQuery, so that normal queries and document listings don't retrieve both copies.

Made a bunch of fixes to dates and regularizations of author names, in an attempt to make the TOC look more normative. Some questions are still outstanding, but we're nearly done with this.

Sigs and catchwords between verse lines were showing up run into the line; the main reason for this was that verse lines are rendered with their linebreaks before them, rather than after (for various reasons), whereas the novels have simple linebreaks in the original text, at the end of lines. I've now added a bit to the XSLT which detects when an <l> tag precedes them directly, and in that case an extra <br> tag is emitted.

I've made the following changes this morning:

• The Table of Contents has smaller text, making room for two new columns (Date and Author).
• The new columns, like the old ones, are now click-sortable.
• Fixed the original document title header in the table, which was in English ("Title"), and is now "Titre".
• Made the date column append a question mark to the date when it's uncertain, and show the date range as a tooltip when you mouse over it.
• Titles in the list are now linked directly to the HTML rendering.
• Teasers now show up when you mouse over the title, and disappear when you mouse away.
• The links to XML and Text views of documents now appear in the XHTML view of the document.

Some slight inconsistencies are revealed by the new layout, which in the case of text documents, Leanna and Lauren could fix; for image markup, I'll make changes on CC's instructions:

1. Some documents have no author. That's because they have no <reg> element in the author name -- example from Candale 1:

              <sourceDesc>
                   <biblStruct>
                      <monogr>
                         <author>
                           <name>anonyme.
                           </name>
                         </author>
   [...]
   

   Actually we need to do two things here: standardize the form on "Anon.", and include it in a <reg> tag as well:

              <sourceDesc>
                   <biblStruct>
                      <monogr>
                         <author>
                           <name>Anon.
                             <reg>Anon.
                             </reg>
                           </name>
                         </author>
   

2. Two documents have no date (Opérateur céphalique and Le taste-poule). Claire, if you can give me approximate or exact dates for those, I can add them.
3. The Sonnet de Courval texts have the same regularized form for the name as the non-reg form:

   <name>Sonnet de Courval, Thomas <reg> Thomas Sonnet de Courval</reg></name>
   

   I think it should be:

   <name>Sonnet de Courval, Thomas <reg>de Courval, Thomas Sonnet</reg></name>
   

   or maybe:

   <name>Sonnet de Courval, Thomas <reg>Courval, Thomas Sonnet de</reg></name>
   

   Claire, which do you prefer? (In both cases, it should sort according to the C, when I've got the sorting thing working properly.)
4. Some names are inconsistently rendered (Le Pautre in one document, versus Lepautre in another).

After much struggle, finally got a working eXist 1.4 up on the server, and so far so good: uploads/indexing are going very quickly, and the site seems to be working perfectly without the need for all the re-indexing we had to do before. I found a bug immediately in my code which creates id attributes for page-breaks: there was an <fw> tag with no content, which tripped up my function for creating an id. That's now fixed.

I also noticed that footnote popups and reference popups were typically on top of each other, so I've moved the footnote popup down the page a bit. We should also add a close button to both of those.

Finally, I've made the menu position: fixed, because I was getting sick of scrolling back up the page to get to it...

Converted my project to a runnable application (not easy -- had to manually edit manifest.mf, specify the main class, etc.; best to start with a Java app target if that's what you want to end up with). Now it will zip and return the size of a string on the command line; I'll add NCD from the command line next.