Mariage

EDIT by MDH 2011-12-22: I believe both of these issues are now fixed. I wrote a template to split lists and it's now in use, and I think LSPW has fixed the erroneous @target attributes. Setting this task to Completed.

Several XHTML validation issues have arisen recently. They fall into the following categories:

• Unexpected elements inside lists. le_bon_mariage.xml has many instances of page breaks, and forme works which occur inside lists. The XSLT doesn't expect this, and outputs XHTML elements inside <ul> and <ol> which are of course invalid (only <li> is allowed).
• Duplicate ids in reference links. Reference links inside the text are provided with unique ids so that you can navigate to them, and these ids are constructed from the target id of the reference itself, followed by an underscore and a number; numbers are provided in sequence by counting preceding references. This is going wrong somehow, resulting in more than one reference link with the same id attribute in the XHTML.

The first requires a policy decision (do we allow other elements than item inside of list?), followed by fixes to the XML and/or the XSLT to deal with the consequences of the policy. The second seems to be caused by typos in the @target attributes of ref elements in the references file; I've identified a set of these and asked LSPW to fix them. The same kind of typos also show up in anthology documents, so I've identified a stack of them using XQuery and sent them to LSPW too.

NOTE: With regard to the first issue, I wrote to the TEI list, and had a number of useful responses; I think the most appropriate was to keep the current markup (which is, after all, "correct"), but use a two-stage transformation to get the document to XHTML. In the first stage, any lists bisected by page breaks, forme works etc. would be split into two lists, allowing the second transform to proceed appropriately. This is a really good idea, and could also be used to handle bisected lgs, which are currently output as <ul>/<li> sets if they're not bisected, or <div>/<span> sets if they are.

Following a meeting discussing contracts, working hours and future plans, we added LSPW's word-processor file, in which she's documenting the markup practices of the project, to the repo, in a new directory called documentation. It looks pretty comprehensive and extremely useful. I might just store it in the exist db so it could be made available on the site (although a PDF version would be more appropriate for that).

I've always been unhappy with the way original and modern transcriptions in the engravings are stored in separate annotations and linked to separate zones. I think a better approach would be to combine the two within one annotation, inside special divs that mark them as alternates:

<div type="transcription_alternates">
  <div type="transcription_orig">
    <p>[...]</p>
  </div>
  <div type="transcription_modern">
    <p>[...]</p>
  </div>
</div>

The XSLT could then provide a single pop-up annotation window with a choice of two tabs at the top or the bottom, so you could switch between them. It could even remember your preference (the last tab you looked at) in a cookie.

It might be possible to automate the conversion of the existing code to this new approach using XSLT; you'd have to identify zones which were equivalent (mostly overlapping), and rewrite the contents of the Transcription category so it contains both, then delete the modernized ones. I think this would definitely be a cleaner approach to providing both transcriptions.

More research on the regularizations suggests that those which handle i/j and u/v variation are also unnecessary in the original transcription field. Using this XQuery, I was able to identify 573 choice elements which have 340 distinct variants:

xquery version "1.0";

declare default element namespace "http://www.tei-c.org/ns/1.0";

let $list :=
(
for $c in //choice[orig]
where translate($c/orig, 'sſuvUVijIJ', '') = translate($c/reg,  'sſuvUVijIJ', '')
return concat($c/orig, '  :  ', $c/reg)
),
$distList := distinct-values($list)
return 
(concat(count($list), ' items, of which there are ', count($distList), ' distinct values: '), 
$distList)

If CC agrees that all these are irrelevant, it would be easy to remove them. That would leave 247 other regularizations, which mainly seem to consist of supplying missing spacing and apostrophes. These could presumably be kept.

I've completed the markup of all the latinate abbreviations identified by CC in the five engravings which contain them; I've also found what I think is one more instance of apostrophe-with-dot-below used for -(m)ent, which I've marked up without a description, waiting for word from CC.

I tweaked the title attribute so it begins with the expansion, for additional clarification.

Arising out of a discussion with CC: The intended use of <choice>/<orig>/<reg> in the original transcriptions of the engravings is to restore normal contemporary usage, while the modern transcription is a full modernization. However, there are instances of <choice>/<orig>/<reg> which are used to replace long s with short s (dating back to when we had no modernizations), so these are inconsistent with our policy, and we should get rid of them. I might be able to do this entirely mechanically -- in the case of any regularization where the only difference is between long and short s, I can simply replace the entire <choice> element with the contents of <orig>; while for every regularization where a long s exists in the <orig> but other things are also regularized in the <reg>, I can add an attribute we can use temporarily to find and manually fix them. This is now on my task list.

I've added the required tagging to billet_doux.xml, which has five odd abbreviations of two different types, and implemented the XSLT and CSS to render it as planned. I'm now waiting for textual descriptions in French from CC of the individual symbols, then I'll make the same changes to the other four files which contain the abbreviations.

In the process, I had to modify the schema, which I did using Roma 2, starting from the previous ODD file (mariage_2011_02.odd), and simply adding the gaiji module and a couple of other things. That seemed to work fine, except for the file forest_nuptiale.xml, which was showing validation errors on the @rend attribute when it appears in argument. This was weird, because exactly the same structures validated fine in other files. After some work comparing files, I discovered that the forest_nuptiale.xml file had this declaration:

<?oxygen RNGSchema="../../mariage.rng" type="xml"?>

while other files such as le_bon_mariage.xml had this:

<?oasis-schema href="../../mariage.rng" type="application/xml"?>

Changing to the oasis-schema declaration made the file valid for some reason. Weird, but worth noting in case it crops up again. Other files have combinations of both schema declarations. I should clean up those inconsistencies.

When adding XSLT processing for the <head> tag, I had neglected to suppress its processing inside <lg> during both the <lg> scenarios (one of which uses <ul>, while the other uses <div>s and <span>s because <fw> tags appear inside <lg>s). <head> is now rendered first, and suppressed later, in both scenarios.

The abbreviations deriving from Latin, listed in CC's post, will be handled like this:

• Each distinct abbreviation will have a <glyph> element in the <charDecl> section of the file header, explaining it briefly.
• Each instance of the abbreviation will be marked up in the original transcription following this pattern:

  <choice>
    <abbr>Vo<hi rend="vertical-align: super;"><g ref="#theGlyphTag">9</g></hi></abbr>
    <expan>Vous</expan>
  </choice>
  

• The XSLT will display ONLY the rendered <abbr> element, and will give it a @title attribute for mouseover which is constructed from the information in the <glyph> element(s) referenced inside the <abbr>. This differs from a regular <choice>/<abbr>/<expan>, in which the <expan> is used as the @title attribute. The actual expansion will normally be available to readers in the modernized transcription, since these all occur in the engravings.

The following updates and changes were made in response to problems and new feature requests, in consultation with LSPW:

• A bug was fixed whereby the wrong document title was being used when showing the list of "Liens à cette référence dans les documents". I was using the first trunc title in the monogr, which was wrong when the document was an analytic.
• A new value ("éloge") for text class has been added, and four documents use it, so we've added a new menu item for these documents to give them their own TOC. In the process, I noticed that the sort-by-type function was not using the TitleSortComparator, so it was sorting éloge after everything else; that's now been remedied.
• There's a need to allow <head> inside <lg>, so I've added processing for that.
• Various documents had become duplicated under different names in SVN and in the exist db, so we went through the process of cleaning that up.

Finally, we looked at the possibility of using OCR to handle the Tableau de l'Amour Conjugal. I installed the Tesseract back-end along with a sourceforge front-end called gImageReader, and also the Hunspell and MySpell French dictionaries, and we tried it out, using Simple Scan to get the image, the GIMP to clean it up a bit, and gImageReader to OCR it. The results aren't great, because the quality of the original document is not good, but it might be slightly quicker than straight transcription.