hresume-issues: Difference between revisions
(→Issues: Fixed broken link) |
m (Reverted edit of Gazza, changed back to last version by AndyMabbett) |
||
Line 18: | Line 18: | ||
*#* Many job experience listings will include jobs that the person is presently working at. Ciaran McNulty [http://microformats.org/discuss/mail/microformats-discuss/2006-October/006477.html 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. | *#* Many job experience listings will include jobs that the person is presently working at. Ciaran McNulty [http://microformats.org/discuss/mail/microformats-discuss/2006-October/006477.html 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. | ||
* {{OpenIssue}} 2006-10-19 raised by [[ | * {{OpenIssue}} 2006-10-19 raised by [[Steve Ganz]]. | ||
*# ''There's currently no way to distinguish different hCard types in hResume'' | *# ''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 <code>address</code> should be used to the distinguish an hCard as the subject's contact info. This proves problematic to implement because <code>address</code> 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 Draft, version 0.1 it is specified that a parent element of <code>address</code> should be used to the distinguish an hCard as the subject's contact info. This proves problematic to implement because <code>address</code> 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. |
Revision as of 23:21, 1 May 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.
Issues
- open issue! 2007-01-04 raised by ntoll.
- 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.
- open issue! 2006-10-19 raised by RyanKing.
- 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.
- There's currently no way to say 'present' in hCalendar
- open issue! 2006-10-19 raised by Steve Ganz.
- 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 becauseaddress
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.
- In Draft, version 0.1 it is specified that a parent element of
- There's currently no way to distinguish different hCard types in hResume
Template
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.
- Issue 1: Here is the first issue I have.
- Issue 2: Here is the second issue I have.
Related Pages
Research
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.