Mariage

We're using a <listBibl> containing <biblStructs>. Each <biblStruct> has three attributes:

1. xml:id="chartier_2005": the unique id of this item, based on the author(s) or editor(s) surname(s) and the publication year. Where there are multiple people, separate each surname with an underscore.
2. type="book": the primary type of the reference, which will govern the rendering process. I'll list these values as they crop up, in this document; I'll adhere to the list I've already got for teiJournal wherever possible.
3. subtype="collective": an additional classification, following the main section headings of the bibliography as it is currently organized. This may prove overkill (see below).

All biblio items will be stored in the main file, and simply referenced from elsewhere, and smaller, subject-specific versions of the main bibliography can be created by creating a framework file referencing items in the main file. This approach may be the best way to create the section-divided biblio rendering in CC's biblio, which I'm currently marking up (which would make the third attribute above irrelevant).

biblStruct/@type values:

• book (simple monogr-level book)
• series_volume (volume in a series which is cited by the series name, rather than the volume editor, volume title, or series editors).
• ...more to come...

My initial intent with the editorial articles (two of which are ready to go up on the site) was to encode them in XHTML, for a quick and simple display. However, several factors make this a bad choice: first, they include links to documents in the collection, and to locations in those documents; second, they include bibliographical references that need to be solidly encoded; and third, some of those references are from the main bibliography listing, and would best be marked up once, centrally, and xincluded or imported into the articles at render time. Finally, it seems to me that it would be a good idea to make the articles searchable along with the rest of the collection.

So we've made the decision to mark up the bibliography and the articles in P5, using practices largely drawn from the teiJournal project (and re-purposing some rendering code from teiJournal too). The best place to start, as always, is the bibliography, and the logical thing to do is to centralize all bibliographical references in a single file, carefully encoded, and then we can present the complete list easily as well, as a separate document. Accordingly, I've started work on the list (which currently runs to about 5 pages), and I'll record my progress, along with any significant decisions I make with regard to biblio markup, in the next post I make.

I've gradually been working my way through the markup issues in La Comtesse D'Isembourg, and I think it would be a good idea to list some of the obvious ones here so that if they're reproduced in other texts, they'll be easy to fix.

First, CSS issues. In @rend attributes, we use standard CSS code only; the Isembourg text had quite a few errors. Among them:

• font-style: small-caps SHOULD BE font-variant: small-caps
• text-align: top-center SHOULD BE text-align: center. text-align only handles horizontal alignment.
• rend="top-right" is not CSS. Mostly this error occurred in <fw type="pageNum> tags, where the intention was to float a page number to the right or left. This is how to do that: <fw type="pageNum" rend="float: right;">235</fw>. Remember that both right-floated (recto) and left-floated (verso) page numbers should appear IMMEDIATELY AFTER the <pb> tag, and BEFORE the (normally centred) <fw type="head"> tag containing a running title.
• left-indent: 0em SHOULD BE text-indent: 0em;. The text-indent property affects only the first line of a paragraph or other block element; margin-left and padding-left properties affect the entire block.

Other problems were caused by some very odd settings in the <tagsDecl> element in the header (where we specify the basic page layout, on which individual rendering instructions are based); there were negative top and bottom margins for page breaks, which meant that each page rendered partially over the top of the preceding page.

There were also many instances of page number tags which were encoded as @type="sig".

The most significant errors have been fixed, and the display now looks pretty good, but I think someone should take a closer look at the layout and rendering at some point.

Uploaded most recent changes to references and Varin, after validating them; then I also uploaded CC's latest versions of the images files (after one XML tweak). Then uploaded the Isembourg, and found a lot of layout issues which I'm still working on, mainly related to page breaks and running headers. I've fixed some, but I'm still working to figure out exactly what is causing the others.

I've now got the Complaintes text looking more or less as it should, after some extensive XML edits as well as a few tweaks to the CSS and XSLT. In the process, I noticed that the display of reference notes in the marginal popup was not optimal, especially for longer notes, so I worked on that a bit; it now scrolls, has smaller text, and has been moved slightly to the right. Tested that on FF, Midori, Opera and IE8.

Started working on the Complaintes text:

• Went through the header and reformatted, adding various bits and pieces our practices require, and reworking other bits (creating a full <biblStruct>, for instance, and adding the <textClass>).
• Added XSLT and CSS handlers for the <sp> and <speaker> tags. This is currently rudimentary, but basically working.
• Noticed that the markup seems to be based on CC's transcription, meaning that it doesn't necessarily reflect the original document (and we don't seem to have any scans or PDF). This means that (for instance) all page numbers were originally put on the left, even on a recto; this I've fixed, guessing that odd page numbers would be right-aligned, but there's no way to check that.
• Also it looks as though LCC has included linebreaks based on the DOC transcription, but those linebreaks may well be just artifacts of the wrapping in the DOC file; we need to clarify this.

Pulled down the image markup CC has been editing, and checked them over; I found a couple of bits where there were invalid constructions, chiefly due to <choice> elements being inserted inside linegroups (<lg>) but outside their line (<l>) tags. Fixed those, and validated all the files, then uploaded the changes into the database.

CC has created a new category for transcriptions:

<rendition xml:id="Transcription_moderne">
  <desc>transcriptional</desc>
  <label>Transcription en français moderne</label>
  <code rend="rectangle" lang="text/css">color: #ffffff</code></rendition>

I've now added that to all the remaining files she hasn't edited yet, using a search-and-replace.

Started checking the Varin XML file. The XML was valid, but the XHTML output showed 72 validation errors. These were a couple of the causes I found and fixed:

• The XQuery that bundles the reference <div>s from references.xml into the document XML file before rendering includes one reference <div> for each distinct-value of ref/@target, selecting the <div> by using the section of the @target following the hash to find the div/@xml:id. If, therefore, the portion of the @target attribute preceding the hash is wrong, then two copies of the same reference <div> may be retrieved -- for instance, if there is <ref target="refefences.xml#blah"> and <ref target="references.xml#blah">, there will be two instances of the <div xml:id="blah"> in the output, an error which will be flagged by the W3C HTML validator. This amounts to an integrity check which throws up lots of typos in the target attribute, and I fixed many of those in the original XML.
• In references.xml, the <list> element is used with @type="bulleted" and without an @type attribute value, neither of which situations was allowed for by my XSLT, which expects @type="unordered" for an unordered list. Rather than rewrite the XML, I tweaked my XSLT to output all TEI <list> elements whose @type attribute is not equal to "ordered" as XHTML <ul> elements.

I also ran some XQuery to find a list of all <ref> tags whose @target doesn't match an existing element in the references.xml file, for whatever reason, and sent that to LCC for her to check through the list, fix typos, and put in empty reference <div> elements in the references file for any missing items.

Uploaded the latest 1609 Sonnet, and then validated the HTML (not the XML, which is fine). There were three errors, which I worked through and fixed:

• There was a <fw> (page number 7) tag inside a <head> element, which is fine in TEI but ends up generating a <div> inside an <h2> in the HTML. I think the page number actually belongs outside the <head> tag anyway, so I've just moved it one level up into the containing (TEI) <div>, which solves the problem.
• The page 11 number had the same problem, fixed in the same way.
• My decision yesterday to include the <figure> element inside the <l> element to handle a floating image alongside the run of lines resulted in a <div> inside a <span>, which is of course silly. Since it's pretty clear that the only place to put the <figure> tag is inside the <l> element, because the TEI schema precludes its appearing between line elements in a line-group, and in this case the line-group is clearly coherent (in other words we can't close the <lg> and open a new one to allow a place for the <figure> tag), I need to change my rendering code so that the <figure> tag doesn't come out as a <div> in this context. I found I had already added a similar exception to handle figure elements inside head tags, so I added another clause to deal with this situation. The HTML now validates, and I've uploaded my changes to the xml file to the server location for LSPW.