Mariage

It would be useful to add a new drop-down list to the search screen enabling the user to choose to search only within specific annotation categories. (Obviously this search would be limited to images). One great advantage of this would be that we could retrieve sets of annotations, and it would be possible also to pull back thumbnails of the images themselves, so you could look at (for instance) all chickens appearing in the images.

I've spent a little time thinking about this, and there are a few issues to decide before we can plan it properly:

• Building the select drop-down itself should be straightforward (the same as the other drop-downs).
• Building the XQuery clause to do this search is not so simple, though; we should shell out to a separate function to do it, as we do with the text search.
• What we need to pull back is going to be complicated too, especially if it's combined with a text search. It's not exactly clear what the user might intend by searching for "chat" (text) and "Graveur" (annotation category). Does this mean that she's searching for all instances of "chat" that appear in an annotation which is in the Graveur category? Or does it perhaps mean all documents which have annotations in the Graveur category, which also contain "chat"?
• One approach is to say that if a category is chosen, then the search is restricted to hits within annotations in that category; and what will be retrieved, for each document, is a reduced document which includes only the <rect> and <div> elements for the annotations containing hits; then the XSLT code can process only those annotations, and for each annotation, produce a thumbnail view of the image area using the web-sized version of the image, computing the view rectangle from the original image size and the annotation coordinates.
• Such an approach could be usefully extended if there were two controls: one checkbox for "Search only in image annotations", which in turn enables the other, "Restrict search to this category of annotation only". If the first checkbox is checked, whatever the search, what is retrieved and displayed would be shown in a thumbnail view.
• Another option is to say that whenever a hit occurs within an annotation, the XSLT should be intelligent enough to notice that, and render the hit with a thumbnail. This is something we can implement first, and get working, before adding other controls on the page.

On balance, then, we should probably proceed by implementing the thumbnail display in XSLT first, then when that's happy, we should add the filter controls to the search page, and implement the XQuery.

Posting time spent figuring this out...

Fixed it: had to use <xsl:sort select="upper-case(tei:title)" />

We still have some work to do on the XHTML mime type issue, and we have to discover once and for all whether it's practical to use it. Proceed thus:

1. Remove the meta tag to get a "pure" application/xml+xhtml site, and test on various browsers. Make notes of what works and what doesn't.
2. Replace the meta tags, and change the sitemap to serve pages as xhtml11_compat for all browsers (not just IE, as is currently the case). (xhtml11_compat is my serializer for XHTML 1.1 served as text/html.) Test again, and note the results.
3. If we find that things generally work (especially if they work in Safari and Opera), we should probably give up on the use of application/xml+xhtml for the moment, unfortunate though this would be. We can always change this later when browsers become more reliable in this regard. Meanwhile, we need a working site. The site can still make use of proper DOM methods (where they're supported) instead of innerHTML.

Once we have a clear idea of what's happening, document it to death, and then set up a system which works for all our core browsers.

Completed 19/02/07.

I've just noticed an odd bug with the site menu. If you use the menu to navigate to another page, then use the browser's back button to return, the menu is showing and fixed on the page (in other words, it doesn't disappear when you mouseout). This is a bit odd. The menu is based on Eric Meyer's Pure CSS Menus, which show a much less annoying version of the bug (on his page, as soon as you mouseover something on the page after going back to it, the menus disappear). Figure out why this is happening and fix it.

Documents marked up using the IMT have minimal headers at the moment. These need to be expanded, with the addition of two different blocks of information:

The <publicationStmt> element needs to be fleshed out like this:

<publicationStmt><idno>arrest_contre_les_chastez.xml</idno>
  <publisher>Humanities Media and Computing Centre</publisher>
  <pubPlace>
    <address>
      <addrLine>University of Victoria</addrLine>
      <addrLine>B.C., Canada</addrLine>
    </address>
  </pubPlace>
  <date value="2004-08-20">20 August 2004</date>
  <availability status="free">
    <p>
Copyright 2004. This text is freely available provided the text is distributed with the header information provided.
    </p>
   </availability>
</publicationStmt>

The second is the sourceDesc, which needs to contain at least one <biblStruct> element, for the original publication, and possibly more, for cases where they have been republished in later anthologies. This is an example:

<biblStruct>
  <monogr>
    <title>Sermon pour la consolation des cocus</title>
    <author><name>anon.<reg>anon.</reg></name></author>
    <imprint>
      <pubPlace>Paris</pubPlace>
      <date value="1624">1624</date>
    </imprint>
  </monogr>
</biblStruct>
<biblStruct>
  <analytic>
    <title>Sermon pour la consolation des cocus</title>
    <author><name>anon.<reg>anon.</reg></name></author>
  </analytic>
  <monogr>
    <title>Le Bibliophile fantaisiste ou choix de pièces désopilantes de rares</title>
    <imprint>
      <publisher>J. Gay et fils</publisher>
      <pubPlace>Turin</pubPlace>
      <date value="1869">1869</date>
      <biblScope type="pp">359-70</biblScope>
    </imprint>
  </monogr>
</biblStruct>

Where dates are vague, we can use the precision attribute to specify certainty, and put a date range in the date tag content:

<date value="1670" precision="low">1650-1680</date>

Completed 12/02/2007.

We're finally close to having a working eXist 1.1.1 setup on Lettuce, which will be the long-term home of all our eXist projects. This setup is a substantial improvement on the old one, because it allows more flexible indexing (for better performance), handles large files, and has some other useful new features.

However, moving projects to the new eXist requires:

• Having a user for the project (we already have one called "mariage").
• Moving the project Cocoon/eXist files into a "webapps" subdirectory in the project user home directory (a simple task, which enable other Cocoon instances to use the same site files without having to make copies of it, and allows access through common url paths such as cocoon/collections/mariage).
• Uploading the XML files into the new eXist db.
• Rewriting the XQuery to take account of changes in eXist.

All but the last are relatively trivial. Once this move is made, the current site can continue to be maintained with new data, but all functionality updates (such as the addition of a search page) will be done in the new location.

Completed 11/01/07: IMT 1.4 should have been released, and there are small changes to the file format which will require that:

1. IMT 1.4 be installed on the project computers.
2. All image markup files be loaded and saved, to make the format conversion.
3. These new versions of files be uploaded into eXist.
4. The XSLT which renders the interactive image pages be updated to handle the changes.

Right now, the only change is from attribute name svg:id to plain id. There may be more by the time of release, though.

Included minutes putting this task together.

I'm marking this task as completed, because we have identified most of the problem areas. We now need to progress to creating proper markup guidelines.

I need to work through the existing markup and look at how some key items are handled:

• sourceDesc bibliographical info (should be formal, probably using biblStruct)
• titles and headings
• pagination/page breaks
• major divisions (are there any nested divs?)
• other line-level tagging practices

Once that's done, we can progress to the creation of some formal guidelines.

1. Add Francela to the users.
2. Make sure C and F can log in and post, and change their pws.
3. Add a link from the project Website to the blog.
4. Create an inc file for the project, for linking into the HCMC Website.