Met with ER to discuss the next phase arising out of the Coup de Dés project. Wrote a proposal and uploaded it to the Sharepoint site.
In preparation for the completion of the XSLT stylesheet that will transform the XML data into a valid data set, SD has made some revisions to the list of outcomes and outcome groups. These revisions are mostly just involve refining current outcomes and making them more explicit (e.g. expanding "Executed" to "Hanged", "HangedOnSite", "Gibbeted", "Dissected", "Burned", and "Drawn").
I've got some work ahead of me to integrate the new outcomes - mostly just accounting for them when encountering irregular data in the XML - but for the most part it should be fairly straightforward. The new outcomes are in the XSLT, so now it's just a matter of adjusting the stylesheet.
JW has requested a new, smaller-scale db for another project, and sent details of the field structure. It will also use custom fields, so it's a useful testbed alongside the larger AdaptiveDB. Today I:
- built the schema in MySQL Workbench
- sent the schema diagram to JW for checking
- generated the db-creation sql
- added the custom-field-related sql (to create the fieldTypes, customFields, and customFieldData tables). I made a generic template for this, which I've added to the AdaptiveDB codebase.
- Created a db ("manifest") and an admin user for it ("manifest_admin") on mysql_dev.
- Tested and tweaked the table-creation sql until it worked.
If JW OKs the structure, I can build the local_classes.php file and we'll be ready to roll.
Fire drill went OK except for one room of people who reportedly wouldn't leave. I forgot to pass on the OK signal around the corner of the building -- must keep that in mind for next time. Notes from the meeting:
- The new alarm ring is an ISO standard, and will be the same in all buildings eventually.
- Instructors were reluctant to leave classrooms, which caused students to move slowly as well.
- Don't forget to clear washrooms.
- Get people out by the nearest exit. They often want to leave the way they came in, even if that's distant.
- Locking office doors is OK (in the past we were told to leave them unlocked).
- Don't leave until your floor/wing is cleared, unless staying puts you in danger.
- If you have any knowledge of the actual fire (location, conditions, injuries etc.) make sure the BEC knows.
- We have seven real fires a year at UVic, so it won't always be a drill.
Some revisions, and a lot of writing notes for myself to cover the parts that SA presented, which will be down to me this time around. I think there needs to be some kind of activity in the process, though, otherwise it'll be sleep-inducing. I'll have to think of a couple of tasks.
Worked on the courses page today making each individual
course linked to course description(s) described below
on courses page.
Contacts page: updated with email address, office hours
Next step: images
document.write(), which isn't available in XHTML. While there's a workaround which involves using AJAX to load the map (this is a good discussion about it), the work required to change the Google maps PHP class that I'm using (view the class) would be significant. Instead, I found a script to emulate document.write() in XHTML. I'm not sure if this is the 'best' solution, but it's time-effective and doesn't break validation.After discovering the excellent WineBottler package of Wine for the Mac, and testing it with one of my personal project (Markin) at home, I was hopeful that it might provide a means to run the Image Markup Tool on the Mac. GN and I thoroughly tested a variety of solutions: WineBottler, PlayOnMac, and Wineskin. All did more or less the same thing: install Wine (and sometimes XQuartz as well), and build a customized runtime environment (a "prefix") for the application, bundling it into a .app package. Everything worked well with the exception of the graphics handling. Opening a normal Mariage-sized file took several minutes, during which the app was unresponsive. This is in contraxt to IMT behaviour on Linux Wine, where everything works as normal (if anything, a bit snappier than Windows). Our conclusion is that the mapping of Windows graphics calls to the OSX graphics system is not as sophisticated as it is on Linux, so the fairly intensive operations the IMT does to resize and zoom images, which use the Graphics32 library, run extremely slowly. Maybe this will solve itself. We tested with Wine 1.1.4 and 1.2.2.
Martin, Greg and I spent quite a bit of time getting the video page (player.php) to validate as XHTML5. The validation started out as part of the debugging process while figuring out why the HTML5 video player wasn't displaying in Firefox.
So, first we changed the document to XHTML5:
- Changed the doctype to html
- Changed the content-type header to: application/xhtml+xml;charset=utf-8
But that was causing hitherto unnoticed character encoding problems to throw outright validation errors. The characters came from the XML data and were mostly French accent characters. The XML itself was fine, so I finally boiled it down to an incorrect usage of PHP's XSLTProcessor library by the PHP eXist database library (which we didn't write). Following a comment made on the PHP page for XSLTProcessor::__construct, I changed this:
$xml_result = $xslt->transformToDoc($dom);
To this:
$xml_result = $xslt->transformToXML($dom);
In other words, from a DOMDocument object to plain old XML string. The DOMDocument transformation was resulting in improper character conversion.
Switching to transformToXML worked, EXCEPT that now, self-closing tags defined in the XSLT (e.g. img) stylesheets weren't being closed when transformed into XHTML, even though they were closed in the XSL files (weird). The solution, after some trial and error, was to change this tag in the XSL file:
<xsl:output method="html" omit-xml-declaration="yes" />
To:
<xsl:output method="xml" omit-xml-declaration="yes" />
So, simply changing the output method from html to xml. And luckily, that did the trick. The page was validating as XHTML5! Yay! Except for one problem...
The OGV videos still weren't playing in Firefox. D'oh. Then something clicked in Greg's mind and he remembered a similar problem on another project that turned out to have something to do with MIME types. Lo and behold, Apache doesn't have an OGV mime type (at least, not in the version running on the Francotoile server). So, I added this to the .htaccess file (along with MP4 types for good measure):
AddType video/ogg .ogv
AddType video/mp4 .mp4
AddType video/x-m4v .m4v
And that was it - video now working in Firefox.