Greg and I worked on the XSLT, CSS and HTML for the site to implement the new theme, which we'll probably make available in a choice of colour-schemes to the end user. We worked with the biblio.xq page, which is the most complicated one with the exception of texts and images themselves. It's almost complete, and once it's done (tomorrow, we hope), we'll port the changes into the other pages, and then (hardest of all) into the text and image rendering pages. We're really hoping everything will be done by Friday's Showcase.
Category: "Activity log"
March 13, 2007
March 12, 2007
Continued working on the XSLT code in preparation for the site redesign, until Lettuce went down. Reported that to the sysops, but no immediate response.
In the process of fixing biblio information in some of the documents, I ran up against a couple of questions:
- Two of the documents, Reconfort des Femmes and Purgatoire, are sourced from the same 19th-century collection. The first included the info that it was from "Tome IV", but there's no volume number in the data for the other one. Is Purgatoire also from Tome IV?
- Purgatoire also lacks an author tag. Is it "anon."?
Added appropriate
<biblStruct> tags to all remaining files that are taken from Cabinet Satyrique, and copied them into the db and onto the server archive.March 8, 2007
Made some progress in preparing the system for the new look:
- Wrote a replacement for
index.xqcalledbiblio.xq. This creates a TEI document with a<listBibl>element in the header, containing all the<biblStruct>and<bibl>elements, acting as a formal index for the collection. - Added new code to
index.xsl, to process this data into the TOC. - In the process, discovered a big hole in the metadata: all the documents drawn from Cabinet Satyrique share a single XIncluded file containing a
<listBibl>with two<biblStructs>, but naturally this is the metadata for the collection; it doesn't include the title etc. of the extracted document. Using the doca_une_femme_mariee.xml, I began working on a solution. - This revealed a big flaw in eXist's XInclude code. It ONLY handles fragment identifiers when they're encoded in a way which is explicitly banned by the W3C; it doesn't handle them correctly when they're encoded correctly.
- To get around this, I broke up the
cab_sat_sourceDesc.xmlinto three separate little files, and XIncluded each of those in the right place. That now seems to work fora_une_femme_mariee.xml. - Next I need to port that fix to the other documents that use the XInclude. Adding that as a task.
As part of the move to the new design, we should refactor a lot of the original site code. Here are things we should do:
- The index XML generated through
index.xqis not TEI XML; it's a temporary format just used for rendering. Now that we have explicit biblStruct elements for each document, we should actually construct a proper TEI document containing a<listBibl>element which simply lists the<biblStructs>. The only question is, when there is more than one, do we include both? We could include both using thecorrespattribute to link them both to the same document id, and then process only the first. - This is an appropriate document format:
<TEI xmlns="http://www.tei-c.org/ns/1.0"> <teiHeader> <fileDesc> <titleStmt><title>test</title> </titleStmt> <publicationStmt><p></p></publicationStmt> <sourceDesc> <listBibl> <bibl></bibl> </listBibl> </sourceDesc> </fileDesc> </teiHeader> <text><body><div></div></body></text> </TEI> - There is also the problem of the classCode element, which is not in the
<biblStruct>. We need to find a way to get that information into the<biblStruct>(where it should presumably be encoded anyway). - Having updated index.xq, we'll then need to update index.xsl to process the results.
- The XML will then serve as a useful bibliographical reference for the whole collection, and can be made available directly.
- The JavaScript inserted by the index.xsl file should be abstracted into a separate file (if it's actually needed -- it's to do with the menu display, which is changing anyway).
This is urgent -- we need the design working next week before the showcase.
March 7, 2007
...arising out of discussions with Greg and tests of his redesign of the site:
- We should take the JavaScript code used for note display in EMLS and re-purpose it for displaying notes in text documents, and teasers in the document index. The old system based on the target pseudo-class doesn't work reliably on Opera, and causes some jumping in other browsers. We can leave it in place, though, to handle the cross-document linking between notes in images and texts.
- The menu should be a single button which shows and hides a drop-down menu. This reduces clutter, and enables us to have the same menu on the image markup pages.
- Document titles, where they are too long, should ideally be replaced by an editor's preferred short title. However, in the meantime, we can truncate them more aggressively because you'll be able to click on them and see teasers.
- The links to various document formats can be removed from the table and put into the teasers instead. This will again reduce clutter (but it does require that teasers work on all browsers, so we must abandon the CSS-only approach).
- We should clean up the original images and the reduced-size versions, using Greg's GIMP procedure. They'll look much clearer.
- We need to have the look installed by the end of the week so that we can create posters and a handout based on it, for the Showcase.
March 6, 2007
We determined that we need to go for a static menu in a conventional location for the main site pages, so the main pages are obvious, and perhaps make the same menu available as a popup from a button in the top right of the image markup pages. There should also be a gallery of images, using thumbnails which expand on hover to show slightly larger versions of the images. All the documents could do with some editorial introduction; at the very least, it could be a more chatty version of information which is already in the teiHeader, but ideally it would also include explanations of the significance of the item, reason for choosing it, and so on. This would enable us to make the TOC and gallery more tempting for readers.
March 5, 2007
The file aggresseure.xml (Présage malheureux) in the regular tree on the network seems to have been overwritten by an older version, lacking the <biblStruct> tag Claire and I added the week before last, and containing a link to an image mapped on drive Z. I imported the <biblStruct> code from a newer backup, and corrected the image path.
Worked on the problems in Opera and Safari with the search page. The problems are:
- Opera fails to import the retrieved responseXML from the AJAX request into the page. It performs the retrieval, but apparently can't handle the proper importNode code which I've been trying to use in order to get around innerHTML.
- Safari inserts the XML correctly into the document, but apparently considers it to be XML rather than XHTML, so although links appear, they are not clickable, and you can't get to any of the documents your search retrieved.
- Konqueror behaves like Opera (at least, the oldish version of Konqueror I have).
The only solution I could find to all cases was to sniff those browsers and cause them to set the BadBrowser variable; when this is set, the script reverts to using innerHTML to set the content of the results div using the XMLHttpRequest's responseText property, rather than using proper DOM methods with responseXML. What this means is that no browser except for Firefox currently works properly in this regard. Nevertheless, Safari is close, and WebKit doesn't show the problems we have with Safari, so it seems that in future Safari and Konqueror may be off the BadBrowser list.