HCMC Blogs

Processing of people from PERS1.xml is now working, and the Credits page uses this XInclude to include the contemporary ones to whom credit is due:

<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="/db/data/PERS1.xml" xpointer="xpointer(//person[persName[@type='cont']])">
  <xi:fallback><p>Unable to find people in the PERS1.xml file.</p></xi:fallback>
</xi:include>

Use of XInclude precludes editing "live" inside the db via the oXygen data explorer, because the XIncludes are expanded on serialization, so you end up with a static page with the included data whenever you open the file. However, there are lots of other reasons not to use the data explorer (see my next post).

I've also basically finished the id listing page, although I have to add some JavaScript to make the table sortable. It gives a lot more info than the previous one, and links to the relevant data.

You can't put xql logic up with the declare statements in the head of the xql file. So, if you need to modify any of those dynamically, here's what you do:

1) hard code in the default case

2) write a function that tests the condition(s) you care about

2) then in the part of the file that is actually processed (and that seems to be anywhere within the root element (e.g. html)), invoke the function and then for each value returned by the function use a util:declare-option statement.

For example, if I want to write out one exist:serialize argument for IE and another one for all other browsers:

1) hard-code the default case (i.e., the one that works for all browsers other than IE) as usual near the top of the file :

declare option exist:serialize "method=html5 media-type=application/xhtml+xml encoding=utf-8 indent=yes doctype-public=''";

2) write a function that tests the condition you care about and put that up at the head of the file too (declare the namespace if necessary):

declare function local:isIE() as xs:boolean{
let $user-agent := request:get-header("user-agent")
return
if (fn:contains($user-agent,"MSIE"))
then (true())
else (false())
};

3) somewhere within the html element invoke the function and re-declare the option:

{if (local:isIE())
then (util:declare-option("exist:serialize", "method=html5 media-type=text/html encoding=utf-8 indent=yes doctype-public='' "))
else ()
}

I'm not sure if there are any constraints or best-practices regarding where to put the test and redeclaration, but in my brief testing it doesn't seem to matter.

Out at the dentist's for 1.5 hours this morning, but on late duty, and then we had a couple of last-minute things that had to be done before leaving (deadlines looming for SSHRC etc.).

KSW noticed that TS had forgotten to commit his changes to SVN, but I was able to log into his machine as hcmc and sudo svn commit. Have to make sure that didn't result in any permissions changes that would prevent future updates or commits.

This document has proved quite complicated to turn into XML, because it contains a bibliography which should be drawn from items in the main bibliography, but several of the items are missing or slightly different. I've had to develop the following conventions for referencing and linking:

• Normally, when a document is processed, a <ref type="bibl"> will result in the importation of a biblio item from the main bibliography file into a special <div type="biblReferences"> at the end of the TEI file; that will then be processed into a full bibliography list. However:
• When a structure like this appears:

                    <listBibl>
                      <bibl type="replace"><ref type="bibl" target="OGIL1"/></bibl>
                      <bibl type="replace"><ref type="bibl" target="ATOZ2"/></bibl>
                      <bibl type="replace"><ref type="bibl" target="HORW1"/></bibl>
                      <bibl type="replace"><ref type="bibl" target="BACO1"/></bibl>
                      <bibl type="replace"><ref type="bibl" target="SAUN1"/></bibl>
                      
                    </listBibl>
  

  the XSLT assumes that we're constructing a bibliography in-place from items in the main bibliography, so it does not produce a list at the end of the document; instead it replaces each of the above <bibl> elements with the one referred to, and creates a bibliography in place.
• When an @xml:id attribute is placed on one of many key elements (<div> etc.), it will be turned into an <@id> attribute in the output XHTML only if there is also a <ref type="internal" target="#[theId]"> in the same document. The <ref> element will then be turned into an internal link to the XHTML element concerned. This is how internal linking within a document is accomplished.
• Other types of ref element include <ref type="detail" target="[an id]">, which I've inherited but which is wrong (the id should be a URI); this will be fixed eventually, but both before and after fixing, the element is turned into a link to [the id].htm (a "detail" page, from the locations subcollection or similar). There is also <ref type="external">, which is a normal external link, and (for instance) <ref type="internal" target="/page.htm">, which is a link to an ordinary page in the root of the site (which is where all pages are served from).

Proofing/editing/expanding bits of the application in an early draft. Deadline looming!

Moved updates from dev site to live site, on HN's instructions.

First timesheets for the two workstudies, and regular timesheets for the Mariage folks. Takes more time than you think it's going to...

GM has joined the team, and will be working 6 hours per week on the Ville-Thierry. Slots have been booked on Spartan, and he's had a general intro to the project; LSPW will direct him to the TEI Guidelines initially, and then show him the V-T text and get him started. The V-T has little or no CSS code in it yet, so it's straightforward transcription and markup.

This page will list our SVN conundrums and how we solved them! And, should this page miss something, check this website.

• When we need to compare, that is, find the difference between two versions of the same file, or files, I suppose.Use this:

  svn diff -r [version number]:[version number]

  As in this example:

  svn diff -r 460:481 B60001.xml

  This was used to look at two versions of the same file: B60001.xml from version 460 and version 481. The SVN report details, with little plus and minus signs, to indicate lies and content added or removed, respectively.