hresume-issues: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(== Related Pages ==)
Line 29: Line 29:
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''
*# ''Issue 2: Here is the second issue I have.''
== Related Pages ==

Revision as of 16:02, 17 March 2007

hResume issues

These are externally raised issues about hResume with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — Tantek

See related hCalendar issues. See related hCard issues.


  • open issue! 2007-01-04 raised by ntoll.
    1. With regard to the "skill" attributes in a resume: often skills have an indication of the level of attainment - be it as a descriptive "tag" or a duration denoting the length of experience of the referenced skill. In fact, abstracting out a "skill" microformat might be useful for re-use in the job-listing (Vacancy?) microformat. That way, job requirements can be married to CVs. Although not a job-site, I like's skill inventory feature (that captures both a level and length of experience) although I think its implementation is horrendous.

  • open issue! 2006-10-19 raised by User:RyanKing.
    1. There's currently no way to say 'present' in hCalendar
      • Many job experience listings will include jobs that the person is presently working at. Ciaran McNulty correctly pointed out that a blank DTEND does not indicate that the event is still ongoing. We need to find an easy way to make this work in hResume.
  • open issue! 2006-10-19 raised by Steve Ganz.
    1. There's currently no way to distinguish different hCard types in hResume
      • In Draft, version 0.1 it is specified that a parent element of address should be used to the distinguish an hCard as the subject's contact info. This proves problematic to implement because address cannot contain block level elements. To avoid sacrificing semantic value by restricting the child elements of an hCard to inline elements, we need to settle on an alternate method to classify a subject's hCard as thier contact info.
      • In any given experience there may be one or more hCards. One which would be the subject's hCard for that experience and the other for a supervisor or manager, etc. We need a way to distinguish different hCards in a given experience.


Please use this format (copy and paste this to the end of the list to add your issues):

  • open issue! YYYY-MM-DD raised by YOURNAME.
    1. Issue 1: Here is the first issue I have.
    2. Issue 2: Here is the second issue I have.

Related Pages



hResume is the classic microformats predecessor for h-resume. Work on hResume is documented at the following for historical purposes. Much of the general discussion and research likely still applies.

The hResume specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. These thoughts, issues, and questions are kept in separate pages.