Résumé XML: Current and Future Steps

I have finished reformatting my résumé into my own XML schema and instance – basically, I now have a formalized definition for what the XML containing my résumé should look like alongside the actual data (in XML format, of course).  The first step was to create what’s called a transform – basically a method of translating the XML data into something more human-readable – so that it can be displayed on my web site in HTML format.  The PHP file that my résumé link points to now actually dynamically creates this HTML display based on the current state of the XML data behind it, so it’s as accurate as the information behind it.

My end goal is to make it so that the XML data drives all presentations of my résumé, including HTML, PDF, Word 2007, and plain text.  While the XML version will always be a complete reflection of my work history, accomplishments, etc. (so things will never be removed, only added), the Word, PDF, and plain text versions will be specifically targeted and abbreviated versions of the information on the site.  The HTML version, on the other hand, is likely to remain a complete transform of the XML (assuming that I don’t end up with so much data as to make this impractical to display properly).

There’s still quite a bit I need to do, though, in order to make this happen:

  1. Create a plain text transform.
  2. Figure out how to write a transform that allows me to create Word documents that have the same layout as my current Word document.
  3. Ditto for PDF.
  4. Modify the original schema (the formalized structural definition of the data) to include targeting parameters so that I can specify which information makes it into which transform.
  5. Add the ability to specify skills/objectives.

Numbers two and three are not insignificant tasks (the last two aren’t either, but require far less effort).  I’m hoping to get this done fairly quickly, since currently, I’m maintaining two copies of the same data in different formats (one in XML and one in Word 2007 format).

Moodle UI hacking

I’ve been doing my own little bit of user interface hacking on Moodle for work, since the layout we had before (below) didn’t work well for our purposes; specifically, the issue we had was with the “Enrolment (remote) database fields” section, which is supposed to map values from a remote database tables into Moodle’s local database tables so that students can be automatically enrolled in courses.  Before, the screen looked like this:


My user interface tweaks below include a new mapping category done by our in-house web developer Lucian DiPeso so that the full name of the course could also be used locally.  The new section, relabelled “Data Mapping”, has eight text fields instead of the original six for precisely this reason.


The only issue with this layout change is that the help text on the right-hand side of the new table isn’t in line with the rest of the help text on the screen, which I expect to correct soon.

There is one other change that we will be implementing on this screen, but that won’t generate as substantial a user interface change as our need to re-envision the data mapping portion did.

We do intend to commit these changes back to the Moodle core, but we’ll see whether they are accepted or not (this won’t be done until we’re absolutely sure the code changes required across several Moodle files are completed).