DTD relevant to the xmlResume

The author of this project was actually not willing to do it on his own. The idea of the resume in the XML format is so straightforward and obvious, that finding an appropriate OpenSource and/or commercial product was not expected to be a problem. Actually, it turned out to be a problem, just because it is too simple. It looks like everybody starts learning XSLT by working on a small xml Resume project, and I was no exception. However, the standard for xmlResume does exist! Moreover, it is as official as it can get without joining Apache foundation: http://xmlresume.sourceforge.net/

The XML transformation by tyoma.com is another skin for the same purpose, complying with the ideas and design of the original XmlResume project.

  1. The first DTD you should try is the official XmlResume located at http://xmlresume.sourceforge.net/dtd/resume.dtd If it works for you - it is great.
  2. It does not work for me, because it includes ISOlat1.module- you can see it right after <!DOCTYPE declaration. You can either install ISOlat1.module (it is easier to install the complete xmlResume package from Source Forge) or simply delete the include from the DTD: resume.dtd
  3. My project does not cover all the features of the Source Forge XmlResume. This means that my DTD is actually more restricted, than the original one. It is OK to verify the document against the original DTD, but all data not conforming to my DTD will be ignored, therefore, it is recommended to use verification against my DTD.

Would this be absolutely sufficient? Unfortunately, not. This is a reality of trying to follow the standards in XML development. If one does not follow the existing standards, DTD or Schemas while doing some new stuff, he is doing a bad job for the original, still useful projects, and at the same time, is severely restricting the potential audience (it makes no sense to migrate from one XML structure to another in most cases), so that following standards is very important. At the same time, following standards literally severely restrict the opportunities for new development, because the document structure is completely fixed (this is a main idea of DTD/ Schema, after all). The only way around is actual misuse of the some uncertainties. In our project, several additional restrictions/conventions were added. Unfortunately, I have not found the way to incorporate those restrictions into DTD and/or Schema, only human-readable description is available.

Most of them are related to abuse of (%inlines) elements <project>, <employer>, <achievement> and <para>; they are defined as any mixture of #PCDATA | emphasis | citation | url | link and one would expect to have a standard simple template for these 5 elements. Contrary to the expectations, there are no standard templates for them, and information for emphasis | citation | url | link but of #PCDATA is generally ignored with exception for:

  1. <para> tag in <misc> section, which has text in <emphasis>, printed in the top section, next to address and contact info.
  2. <misc><para>><url>… construction used for absolute URL for the photo, displayed on the right.
  3. <history> accept target attribute used for splitting Experience into several sections: Full Time, Consulting, etc.
  4. <employer><citation> used as an Employer's name
  5. <employer><url> used as an Employer's URL
  6. <employer><emphasis> used as a short Employer description
  7. <project><citation> used for the specifying technologies used in the project
  8. <achievements><achievement> is used for the short description of work responsibilities and achievement at job.

The author totally admits that this is rather confusing. Any suggestions on how to improve the data verification without losing reasonable backward comparability and reasonable flexibility are most welcome.