Some of you may be wondering at this point why I used static HTML files, rather than just dynamically invoking the XSL transform engine as needed. Initially, this was my plan. Unfortunately, though, it didn't work out for simple economics: my ISP wanted an extra $15/month for servlet support, and when running the transform as a CGI program, each page took more than ten seconds to render. The same performance penalty also kept me from using XSL to display the enlarged photos: it turned out a perl script, doing simple pattern matching on the XML files, did the same work in a fraction of the time, and was just as flexible.
I have to say, the XML and XSL transformation was definitely the most enjoyable part of my development. XSL technology is still quite new, so it's understandable that there are minor functional gaps and big performance issues. I didn't want to get too immersed in it, for fear it wouldn't serve my needs, but now that things have turned out well, I plan to use it for generating the templates underlying the journal text as well - since the headers and footers are basically the same, except for the day number and title, this will make customizing the layout much easier than writing a perl script to go through and make all the modifications every time I wanted to make a change across every page.
To keep the reader reminded about the photographs, I tried to embed a thumbnail or two within the text, including a snapshot of a souvenir every once in a while, just to break the repetition of countryside scenes and touristy landmarks. This required accessing the photo's XML file again, to get the dimensions (so that text would wrap around it), the title (for the alt tag), and the filename of the enlarged photo (for the link). Unfortunately, there was no easy way to do this without some type of server-side execution. I put together another perl CGI script that parsed the XML file passed in to generate the HTML needed to display the thumbnail -- again XSL was too slow for real-time execution -- making sure to surround it with JavaScript tags, so nothing would be displayed when viewing text only.
There are a few small drawbacks to this approach. First, it requires more server resources to keep running that perl script, although so far, it hasn't been a problem. (My ISP's hardware and software have proven to be quite up to the task so far.) Second, the scripts have to be run even if no output is being generated, in the case of text-only viewing. This actually bugs me, but there's no way to make the SSI execution conditional, and no way for the perl script to know that JavaScript is turned off. So long as performance of the server isn't a problem, however - and the percentage of users viewing text only should be quite low, too - this mostly just bugs me out of principle. Finally, it threw a curveball in my mobile development plans. For the most part, I was doing development on my laptop, running Apache on Windows NT, before deploying the site to my ISP, running Netscape Enterprise Server on Solaris. Unfortunately, I couldn't get the server-side includes to work on Apache/NT, so after going down this path, I wasn't able to fully test the site offline.