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 Çelik

See related hcalendar-issues. See related hcard-issues.

Issues

issues 2012

• open issue! 2012-09-05 raised by Tantek Çelik
  1. the "publications" property should be "publication" per naming
     • the "publications" property in particular seems a bit off - it probably should have been "publication" per the naming principle, and used, e.g. <cite class="publication"> ...

issues 2010

• open issue! 2010-03-17 raised by TobyInk
  1. Embedding hCard for job title leads to ambiguities.
     • It's tempting to assume that any class="vcard" within the class="experience" must be an hCard representing the contact while they were at the organisation (e.g. class="title" represents their job title, class="role" their role, etc). But there's no guarantee of that. e.g. <span class="experience vevent">...<span class="location vcard"><i class="fn">Employer's Name</i></span>...</span>.
       • Suggested solution: provide a class name for indicating that a particular hCard represents the contact while they were at the organisation. e.g. class="vcard me".
       • Suggested solution: based on a couple of recent real world: hresume-examples-in-wild ([1], [2]) which both use the same pattern, it seems reasonable to use the class name vcard on the same element as experience and vevent. This solution appears to be sufficient to resolve the issue, and does not require any new class names. - Tantek 19:58, 18 March 2010 (UTC)
         • class="experience vevent vcard" - indicates both the hCard for the job title as well as the event for the experience on the same element.

issues 2009

• open issue! 2009-02-21 raised by mfreeman

• The draft should describe a way to handle a series of assignments at various employers within the context of one job working for a contracting, consulting, or temporary firm/agency.
• For example, a person is employed by ABC Corp. as a Staff Consultant from 1/1/2000 to 12/31/2008. During that time, ABC Corp. placed the person at:
  • XYZ Inc. as a Business Analyst from 1/1/2000 to 12/31/2005
  • DEF LLC as a Technical Writer from 1/1/2006 to 6/1/2006
  • "on the bench" with no assignment from 6/2/2006 to 8/14/2006
  • OMG Inc. as a Database Designer from 8/15/2006 to 12/31/2008
• The draft may already address this, but it is not obvious.

issues 2007

• open issue! 2007-10-02 raised by jeffmcneill.
  1. Support for Awards and for Service sections are not currently implemented
     • I have attempted to use the Experience tag, however am unclear whether this will break things. Please see the example here. --jeffmcneill 04:09, 2 Oct 2007 (PDT)

• open issue! 2007-06-21 raised by Steve Ganz.
  1. rel-tag can be difficult to implement for "skill"
     • In Draft, version 0.1 it is required that each "skill" be marked up with rel-tag. While this is a good idea, and easy to do for individuals, it poses some challenges in the real world for large publishers of user generated resume data. If rel-tag was optional for "skills", it would be easier to implement.
     • +1, expecting a resume author to link out to a hypothetical tagspace is an unnecessary barrier to entry. In reality authors end up linking to places like WikiPedia, which is not a real tagspace as defined in rel-tag. We should look at a more complex skill format for both this and the issue below opened by NTollervey. --Ciaran McNulty
     • +1, I have tried very hard to think of ways to make rel-tag work for skills description. In the end I had to drop marking up skills altogether in hResume because I am unwilling to add meaningless hyperlinks. As Ciaran mentioned we need a more complex structure that actual models to real world use. I have documented some alternative ideas skill brainstorm Glenn Jones

• 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 Sourceforge.net's skill inventory feature (that captures both a level and length of experience) although I think its implementation is horrendous.
     • +1, There are enough people using either skill ratings or denote duration for us to consider extending the skills. We already have two patterns in other microformats rating and ISO duration that could be used extend the structure skill brainstorm Glenn Jones

issues 2006

• open issue! 2006-10-19 raised by 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.
     • Any solution should also be a valid hCalendar, which makes things even more difficult. One possible solution would be to use an event without a DTEND for the current period of employment but have some extra class that indicates that within the semantics of hResume it's an ongoing event and let the hCalendar version just indicate the start of the employment. --Ciaran McNulty
     • Although not the best solution, for the time being, a date far ahead in the future (e.g., 2049-12-31) may have practical use (Note: Google Calendar can handle up to but not including year 2050) -- --Sarven Capadisli 21:34, 18 November 2008 (UTC)
     • I tend to just use the current date for dtend: anything else seems semantically wrong as an abbr of "present". GeoffreySneddon 21:46, 19 November 2008 (UTC)

• 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.

• Agreed, when adding my references in hCard to the bottom of my hResume it became apparent there was no way I could mark 'my' hCard as the one belonging to the subject of the hResume. Perhaps @class="hcard subject" as a child of the hResume? Ciaran McNulty

• 1. • hCards can be differentiated by their id. Representative hCard might be sufficient to point out the contact info of the hResume -- Sarven Capadisli 12:22, 9 September 2009 (UTC)

Related Pages

• h-resume

Research

• resume-examples
• resume-formats

Previously

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.

• hResume
• hResume cheatsheet - hResume properties

• hResume examples in the wild - an on-going list of websites which use hResume.
• hresume-authoring
• hResume FAQ - if you have any questions about hResume, check here.

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.

• hResume Feedback - general feedback (as opposed to specific issues).
• hResume Brainstorming- brainstorms and other explorations relating to hResume.
  • see also hResume skills property brainstorming.
  • see also resume-brainstorming.
• hResume Issues - specific issues with the specification.