XML Power Job Hunting

May 28, 2003

Q: What can you tell me about XML-based résumés?

Is there an XML standard language for curriculum vitae data?

A: First, for the uninitiated: a curriculum vitae (Latin for "race [or course] of life," often shortened to "CV") is a more detailed version of what's also -- particularly in the U.S. -- called a résumé. It's a common means of summarizing your career and accomplishments when seeking work in the academic, scientific, research, or international fields.

A good rule of thumb: If you can think of a knowledge domain to which you can prepend the phrase, "Is there an XML standard language for...?", someone has probably already done the work for you. So it is with this questioner's concern.

The place to look is SourceForge, in particular the XML Résumé Library (which I'll call XRL here, although this abbreviation isn't used by the Library's project team). This application does indeed codify a "standard language" -- a vocabulary, defined via a DTD -- but it also includes some nifty other components. For now, let's look at the structure of an XRL document.

If your document is to contain only a single résumé (the normal case), its root will be a resume element. (For building multi-résumé documents, which are useful if, say, you're presenting the qualifications of an entire project team, wrap a series of resume elements within a single resumes root element.) Each resume contains an optional header element, elements describing the résumé's various sections, an optional "date last modified" element, and optional copyright information. The sections, each of which details specific aspects of your career to date, include descriptions of your overall objective, your academic background, your publications, interests, awards, and so on.

A simple XRL document might look something like this:

<resume> <header> <name> <firstname>John</firstname> <middlenames>E.</middlenames> <surname>Simpson</surname> </name> <contact> <email>simpson@polaris.net</email> </contact> </header> <objective> <para>To be satisfied with whatever falls into my lap.</para> <para>Well, that, plus to encourage more things to fall into my lap.</para> </objective> <pubs> <pub> <bookTitle>Just XSL</bookTitle> <date><month>September</month><year>2001</year> ;</date> <publisher>Pearson PTR</publisher> <url>http://tinyurl.com/cg1d</url> </pub> <pub> <bookTitle>XPath and XPointer</bookTitle> <date><month>August</month><year>2002</year></date> <publisher>O'Reilly and Associates</publisher> <url>http://tinyurl.com/cg1n</url> </pub> </pubs> </resume>

This barely scratches the surface of the kind of data you can include in an XRL document, but it's a start. For more information, see the XML Résumé Library DTD.

If this were all there were to XRL, it would sufficiently answer your question. But as I said, there's more. The SourceForge download also includes:

Numerous XSLT stylesheets for transforming an XRL document to a résumé in XHTML, PDF, or plain text format. (There's also a CSS stylesheet for styling the resulting XHTML, if that's the way you choose to go.)
A "targeting filter," allowing you to tailor the output résumé for particular types of employers.

Stylesheets

When you've unpacked the XRL installation file, you'll have an xsl directory consisting of six subdirectories, including ones (for example) called country and output. In each of these six subdirectories reside numerous XSLT stylesheets. The purpose of these stylesheets is largely to set XSLT parameters used to control the résumé's format and output medium (XHTML, PDF, text).

To my mind, the most interesting stylesheet included with XRL is the one named params.xsl, which resides all by itself in the xsl directory (not one of the subdirectories). Like many of the other stylesheets, this one simply establishes parameters to drive the transformation of your XRL résumé to its target format; with params.xsl, however, you're specifically encouraged to make changes to the contents. A few examples:

The parameter named skills.param can take one of two possible values, comma (the default) or bullet. With the former, the list of your skills will be presented as a simple list, with the items separated by commas. With the latter, skills appear in a bulleted list.
The css.embed parameter controls how the transformation to XHTML works to refer to an associated CSS stylesheet. A value of 1 embeds the stylesheet in the XHTML output (this simplifies e-mailing your résumé); with a value of 0, the CSS stylesheet will be linked to in a separate file.
If you want your "referees" (that is, professional references) to appear in the output, set the referees.display parameter to a value of 1 (the default); otherwise, set it to 0 and the transformation will substitute the phrase Available upon request. (This phrase is itself customizable, using a referees.hidden parameter established by the country-specific XSLT stylesheet of your choice.)

Note that the transformations effected by these XSLT stylesheets (and the CSS stylesheet, for the XHTML output) result in documents of extremely plain appearance. It's not up to the XRL project team, after all, to design the look of your résumé. If you want truly professional-looking résumés, be prepared to spend some time tweaking the default XSLT (and perhaps the CSS) stylesheets. Furthermore, if you're hoping to generate PDF format, you will need to know quite a bit about the use of XSL Formatting Objects (XSL-FO), as well. PDF output is not generated automatically; it's the final step of a process from XML source, to XSL-FO stylesheet (by way of an XSLT transformation), which is then fed into an XSL-FO formatting engine (such as the Apache Project's FOP or RenderX's Xep).

Targeting filters

If you've spent much time job-hunting, you know one of the basic frustrations: how to avoid handcrafting a different résumé for each different job you're considering. Wouldn't it be better, or at least easier, if you could create a single résumé but instruct your résumé-generating tool to include this skill and exclude that one or to name this referee but not the other?

That's where XRL's "targeting filters" come into play. Every element in an XRL document has an optional targets attribute, the value of which is a comma-separated list of keywords. Each keyword (the specific keywords are up to you to choose) defines a particular target audience or purpose for which this element's content is suitable.

Given the mini-résumé above, I could target it to different audiences by adding targets attributes in something like the following fashion:

... <pubs> <pub targets="XPath,XSLT,XSL-FO"> <bookTitle>Just XSL</bookTitle> <date><month>September</month><year>2001</year></date> <publisher>Pearson PTR</publisher> <url>http://tinyurl.com/cg1d</url> </pub> <pub targets="XPath,XPointer"> <bookTitle>XPath and XPointer</bookTitle> <date><month>August</month><year>2002</year></date> <publisher>O'Reilly and Associates</publisher> <url>http://tinyurl.com/cg1n</url> </pub> </pubs> ...

Also in XML Q&A

From English to Dutch?

Trickledown Namespaces?

From XML to SMIL

From One String to Many

Getting in Touch with XML Contacts

At the time my résumé is generated, I can specify (depending on the position I'm seeking) to output information on the books covering XPath, or just the one which covers XSLT, or just the one which covers XPointer...all by telling the XRL transformation to attend just to the corresponding targets attribute values. If, on the other hand, I limited the output just to targets attributes with a value of XML, then neither of those two books' information would appear.

Some caveats about using XRL's target filtering:

To use this feature, you must add the xmlresume-filter.jar file (included with the download) to your Java CLASSPATH.
The values of the targets attributes on higher-level elements (like pub, above) are inherited by descendants of those elements (such as booktitle, date, and so on) which have no targets attributes of their own.
If a given element and its ancestors have no targets attributes specified, that element will be included in all output résumés (that is, it will not be filtered at all).

Q: Internal schemas?

Can you include a schema internal to an XML document, and if so, how? I have seen DTDs internal and schemas external.

A: You're right about DTDs: a given one can be either wholly external to an instance document, internal to it, or a combination of both. You'll look in vain, though, for any way to accomplish this with XML Schema; an XML Schema document is always external to the document(s) conforming to it.