This one is a personal project. It started a few years ago (somewhere in mid 2003), when I created my previous web site (same address, older technology), which was based on Windows SharePoint Services version 2.0.
Goal of the project was to create a single source CV for multiple platforms and applications.

  • Edit the CV content only once
  • Maintain the CV in two languages (English & Greek)
  • Use everywhere
    • web for online reading,
    • MS Word & Adobe PDF for distributing and printing,
    • whichever else application comes along as need

Obvious solution was: use XML and XSLT.
After browsing around for standards I discovered (back then), the XMLRésuméLibrary Project which defined an XML vocabulary for CVs along with a set of tools for visualizing and printing them.
I didn't like the tools they provided as I wanted to approach the whole thing "the Microsoft way". So I just took the DTD from there.
First thing I tried was to create an InfoPath form from the DTD, but converting the DTD to XSD did not yield a solid reasonable schema. Would be nice to have an InfoPath form for editing my CV but the time needed to be devoted in creating a solid result was not worth the try. So I scratched that effort and decided to edit in straight XML.
Next thing I had to do was create an XSL transformation to visualize my CV on my web site. I wanted to maintain the layout and style of the CV I already had in Word format so I created the XSLT from scratch.
Now I had another problem to solve: I needed two versions of the CV in two different languages. There were three solutions to that problem. There was no provision for multilingualism in the XMLRésuméLibrary DTD so I either had:

  • to alter the DTD,
  • trick it somehow (using the "targets" attribute),
  • or just maintain two different XML sources one for each language.

I opted for the third approach (because actually I did not think of the second one at the time).
Maintaining two XML files was not the actual "problem". The problem now was maintaining a single XSLT as apart from content provided in XML I had to translate the static text of the CV (labels etc.)
To do that I used a separate XML (which I named Resources.XML) with a schema I defined for that purpose. This XML file included all static text in translated versions distinguished by a "language" attribute. The Resources.XML file was included by the XSLT using xsl:include and was referenced wherever needed being passed a parameter that specified the selected language.
So far I had the following files:

  • "My Resume.Greek.XML" containing the Greek version of my CV.
    This file had to be edited every time I needed to update my CV in Greek.
  • "My Resume.English.XML" containing the English version of my CV.
    This file had to be edited every time I needed to update my CV in English.
  • Resources.XML containing the labels used in my CV localized in both languages.
    This was a static file created once and never really had to be altered. Here is a sample part of the file:
  • "My Resume.XSL" containing all the XSL transformation required to convert either language source of my CV to DHTML. This was a static file created once and only had to be altered whenever I needed to improve the style and layout of the output. Here is the rough structure of the XSL file:
  • "My Resume.Greek.XSL" which is a minimal file that just stets a variable indicating the selected language to Greek and includes "My Resume.XSL" to do the actual transformation. This file is static and never needs to be edited either. Here is the content of this XSL file:
  • "My Resume.English.XSL" which is a minimal file that just stets a variable indicating the selected language to English and includes "My Resume.XSL" to do the actual transformation. This file is static and never needs to be edited either. The content of this file is analogous to it's Greek equivalent displayed right above. It just changes the value of the "language" variable to English.

These are the basic elements of my first XML CV solution. In practice I maintained a different XSLT for use in MS Word because the XSLT for the web included DHTML interactivity (JavaScript) and slightly different styling than what looked best for print.

All these were not as easy or straight forward as they seem. Problems I was faced with included:

  • Issues with MS Word integration:
    • CSS needed some tweaking to produce the results I wanted in Word.
    • I also had to have an automatically updating Word document. So I used just a Word field to include the XML and transform it on the fly and I also used a Word macro to to automatically update the field every time someone opened the file. Here is the field code:
  • Issues with SharePoint integration when moving to WSS 3.0:
  • See this relevant post for a clue.
  • Issues with PDF transformation:
    I never really tried to solve this one. I am still creating PDF versions by hand (by saving to PDF through MS Word 2007). I will have to look for an automated solution for this one in the future.

All these pretty much remain under investigation since they need some time and effort which the for the moment are not practically worth for.

So this about sums it up for the first phases of this project. Which brings us to 2008. Many things have changed since 2003 that all this started and even since 2006 when migration to WSS 3.0 caused me to re-investigate some of the projects details.

Today we have new things like: Europass, hResume and microformats, HR-XML specs, Linked-In, Xing and other Web 2.0 stuff. So the project is again being revisited these days on any spare time I can get a hold of for it.

What do I currently do?

  • I am making a new XSL to convert from XMLResume to Europass layout.
    This is being done purely for practical reasons.
  • I am considering the problems of integrating with Europass specs in general.
    This has a lot of implications as the two formats have fundamental differences. HR-XML is considered also along this path.
  • I am about to implement hResume in my existing and new XSL transforms.
  • I am considering the problem of integrating with Linked-In.

There are a lot of thoughts on these issues but I will not make more comments on them until I feel I have something concrete to say about them.