Skip to toolbar

Community & Business Groups

CV 2.0 - Global Resume Community Group

The purpose of the CV 2.0 - Global Resume group is to move the current textual data and partly chaotic graphical resumes to a well-structured and accessible CV 2.0 that supports applicants as well as recruiters.

The group will publish and update:

  1. specifications on the creation and usage of a CV 2.0,
  2. guidance on the implementation of new systems using the CV 2.0 and integration into existing professional networks or resume filtering software,
  3. templates, styleguides, and more.

See the charter for more detailed information.

Group's public email, repo and wiki activity over time

Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.

No Reports Yet Published

Learn more about publishing.

Chairs, when logged in, may publish draft and final reports. Please see report requirements.

This group does not have a Chair and thus cannot publish new reports. Learn how to choose a Chair.

Happy New Year

Happy New Year everyone!

happy_new_year

Please check out our specification draft on GitHub via the right sidebar on the blog and don’t hesitate to ask me to join the organization on GitHub so you can edit it yourself or suggest changes.

Happy and healthy 2016+!

cv2.me – ready for contributions

The service that will implement our specification has started at http://cv2.me/.

Those who are interested in the early development are invited to check out the code (very early v0.1) on GitHub. Members of this group will be added as contributors to the organization on GitHub if they send me a request to the internal mailing list. Other than that, the time frames are as mentioned in an earlier post – contributions welcome.

In order to join the group, you will need a W3C account. Please note, however, that W3C Membership is not required to join a Community Group.

Proposal: .cv2 syntax

This post is a proposal on parts of the .cv2 syntax for the CV 2.0. Things will still be missing and we need to discuss more in order to create a specification, so feel free to join in on the discussion via the mailing list.

Syntax Signs

\\ 2 backslashes for section start

\\ Personal
...

\\ Professional
...

\\ Education
...

\\ Skills
...

\\ Personal
...

Additional information for a section can be added anywhere into the .cv2. The parser will recognize everything from a beginning \\ to the next \\ as one section. If two sections are the same, the properties will be recognized as belonging to the same section. Newer (i.e. further down in the file) values will replace older values if they address the same tag, much like cascading stylesheets.

/* comments */
As usual in many programming languages, comments can be added in between a slash, asterisk – asterisk, slash combination. Example:

/* comments optional - filename: john_doe_timestamp.cv2 */

 

\{} Special Characters and Escaping Characters

/* a name with umlaut as an example of how to escape characters */
fullname: John D\{"o}e

The above example syntax is borrowed from LaTeX, although Umlauts and other symbols should be recognized since .cv2 will have UTF-8 encoding as requirement in our specification, so there should only be the need to escape, for example, company names with two backslashes in them or other names that interfere with our .cv2 syntax which should happen rarely if at all. Anything that is input via a form needs to be sanitized and escaped correctly. This is a main security point in our specification.

“Values spanning

several lines”
As newline is our ending character, we need a sign to tell the parser that a value spans several lines. Example:

j1.description: "this text spans several lines and is rendered similar
to the pre tag in HTML - preserving line breaks"

[] Enumerations and Value Ranges
Enumerations and value ranges are important for custom tags that are defined by the user and have no defined meaning as well as value ranges for skills in order to create visualizations and charts. Example:

\\ Skills
CSS AS css
Java AS java
Project Managemenet AS pm
 
scale1: [0-100]
scale2: [Beginner, Intermediate, Expert]
 
css.level: \{scale1:67}
css.category: markup languages
 
java.level: \{scale1:85}
java.category: programming languages
 
pm.level: \{scale2:Expert}
pm.category: organizational

Enumerations and value ranges are created using name: [x-y] for value ranges or name: [a, b, c, d, …] for enumerations and must be created before their first reference. They can be addressed via the usual escaping/referencing syntax: \{name:value}

Tag Names

We will still have to define most tag names. Some tag names are suggested in the Notes post, such as:
fullname, faoname, email, birthDate, birthLocation, citizenship, name, dateStart, dateEnd, role, description, degree, level, category, …

faoname stands for “For Attention Of” as used in letters and is used to designate the proper salutation. We cannot use first and last name since many cultures around the world use a different concept and people need their full name on their resume as well as some option to tell how they would prefer to be addressed.

Multi-Tag Properties

Some properties have multiple tags, such as jobs and education. The choice is to either group them in parentheses, making them harder to separate or concatenate anywhere else in the document and also harder to read eventually. So the approach is to treat them similarly to objects in a programming language, addressing the property followed by a dot and the tag. Example:

j1.name: Some Company Name

Aliases

The Alias concept has been borrowed from SQL and can be used for any multi-tag properties. Aliases must be created for user-defined properties such as skills or custom tags. Example:

job1 AS j1

j1.name: Some Company Name
j1.dateStart: date in format dd.mm.yyyy

Cross-References

Cross-referencing is very important for the visualizations so additional links can be clearly shown and visualized in various ways, for examples skills can be linked to jobs or jobs to education, etc. Example:

j2.description: "created blah, e-mail me: \{email}"
j2.additionalInfo: some more blah, had a contract for \{j1} while doing this

The syntax for cross-references is \{tagname} including the cross-referenced tag name in the curly brackets.

URLs and External Files

URLs and external files like pictures and logos can be added to a .cv2 using \{externaltag} where “externaltag” for now only has the options of url:, mailto:, and file:. Example:

j2.description: "created \{url:http://blabla.org} in this job,
email to \{mailto:myaddress@here.com} for questions"

FYI

According to the charter (section Decision Process), we need a group consensus or at least a 2/3 majority vote on this proposal where agreement as well as silence implies consensus.

If no objections arrive by October 11th 2015, this proposal is regarded as accepted. A small reminder: if you agree, please reply to the public mailing list – if all participants agree or disagree before the 11th of October, we can already move forward with our work. Thank you!

Introduction to SVG Templates

As promised before the syntax proposal, here is a glimpse of what an SVG template could look like (with filler text):

SVG 2.0 example, fictive character John Doe

Since SVG is a text format that can be read (but not visually interpreted) by any text editor, SVG templates can be created by anyone. We should also write documentation on how to create templates, but this is not our priority for now. The same can (and will) be done for HTML and exported to PDF and several other output formats in the same design. In our best practice style guide we should also include that developers shall add a print output option for less toner waste.

A repository for templates will be created within the next days. Additional templates will be continuously added. If you know designers who want to participate, if you have your own design ideas, or comments/improvement suggestions on existing templates, don’t hesitate to write to the mailing list.

Time Frames

We work in two packages – one is the definite specification where we address shifts in hiring best practices and that we will continue improving with new technologies. It is our main deliverable. The secondary package are several deliverables that will be posted continuously on this blog.

Main Focus

Specification

(December 31st, 2015 or earlier for the first draft)

  • syntax
  • style guide for the syntax
  • definition of a CV 2.0
  • definition of privacy ethics

Other Deliverables

Templates

(continuously)

  • HTML
  • SVG

Code Snippets

(continuously)

  • mappings to other resume formats
  • other useful code snippets that can be reused on existing resume solutions

If you have suggestions for further deliverables, please communicate them via the mailing list.

Notes on the .cv2 syntax

For the .cv2 syntax, I have spent some time researching syntax decisions and syntax specifications from other formats, particularly XML, JSON, YAML, RDF, and various programming languages.

As was already discussed on the mailing list, syntax is always an arbitrary decision.  The biggest part of people who will use a CV 2.0 will use tools and services in order to create their resumes. The greater vision is that people who are currently looking for a job do not have to open a word processor and fiddle around in order to align their picture with a heading but rather that they know about the services they can use or even learn to open their created .cv2 in any text editor and correct a newly changed telephone number themselves, then generate outputs in several formats.

I’d like to open a discussion on the .cv2 syntax, what we need are:

  • tag names
  • cross references to
    • file-internal tags
    • external values
  • skill levels
  • text spanning multiple lines in case we take a new line per tag
  • categories (mainly useful for skills, maybe something else like job categories in the future)
  • comments (so you can comment/uncomment data you want to use when outputting)

Levels and categories have their value for textual output, but they are crucial to visual output when charts and diagrams need to be created. The following is an idea of what the .cv2 could look like.

/* comments optional - filename: john_doe_timestamp.cv2 */
\\ Personal
fullname: John Doe
faoname: Mr Doe

\\ Professional
/* aliases can be created for any multi-tag properties,
but have to be created for user-defined properties, such as skills */
job1 AS j1
job2 AS j2

j1.name: Some Company Name
j1.dateStart: dd.mm.yyy
j1.dateEnd: dd.mm.yyyy
j1.role: Senior Developer
j1.description: "this text spans several lines and is rendered similar
to the <pre> tag in HTML - preserving line breaks"

j2.name: The previous or next company
j2.dateStart: dd.mm.yyyy
j2.dateEnd: dd.mm.yyyy
j2.description: "created \{url:http://blabla.org} in this job,
email to \{mailto:myaddress@here.com} for questions, can also use \{email}"
j2.additionalInfo: some more blah, had a contract for \{j1} while doing this

\\ Education
edu1.name: Some University
edu1.dateStart: dd.mm.yyyy
edu1.dataEnd: dd.mm.yyyy
edu1.degree: BSc

\\ Skills
CSS AS css
Java AS java
Project Managemenet AS pm

scale1: [0-100]
scale2: [Beginner, Intermediate, Expert]

css.level: \{scale1:67}
css.category: markup languages

java.level: \{scale1:85}
java.category: programming languages

pm.level: \{scale2:Expert}
pm.category: organizational

\\ Personal
/* you can concatenate information manually anytime,
systems using the .cv2 will re-format the data */
birthDate: dd.mm.yyyy
email: myemail@here.com

If you have any comments or want to discuss further topics, you’re welcome to do so via the public mailing list. A concrete proposal including explanations of why, how, and additional information on the syntax will be posted until September 30th, 2015. The next posts before the proposal will include the first visual .svg template and some time frames on deliverables for our group.

Call for Contributions: Use Cases

This is the first call for contributions – anyone who has a certain use case in mind is welcome to join in and contribute, preferably via the mailing list. Programming skills and technical knowledge are irrelevant for creating use cases. A use case can be as simple as the following:

Simple Use Case 1

Title: Filter Resumes for Java Experience

Primary Actor: Recruiter (Agent Smith)

Scenario: Agent Smith has 3 jobs to fill for his client, a bank. He is looking exclusively for developers who have at least 3 years of experience with Java. He is using his corporate system to filter the applications he receives via e-mail and via the form on his company’s website.

Simple Use Case 2

Title: Unemployed Saleswoman learning Resume Writing

Primary Actor: Applicant (Anna April)

Scenario: Anna is participating in a course on resume writing because the job center sent her there after she has been unemployed for half a year. She has no computer skills apart from using the browser and needs to create a resume.

The above use cases are the simplest form – of course one could go into more detail and explain what kind of files Agent Smith receives and what happens in case of both successful and unsuccessful filtering, etc. The simple use case form is usually enough in order to be able to explain what a certain group of people might need the most from a next-gen resume. Names for the actors are useful when referring to the use case scenarios in future feature discussions.

Why do we need use cases?

Most of the existing resume solutions have one particular group of people with one particular presentational format in mind and while creating a specification as well as snippets and tools for developers is what we are aiming at, we want them to be well-defined.

When John is looking for a job, he doesn’t want to fiddle around in Word to align his photo. Stella wants to edit an infographic but doesn’t want to put the hours of work into creating it from scratch. Berta, who recruits people in different time zones from home, would like to view all the resumes she receives on a black background with light gray text, because it is easier on her eyes. Andrew wants to avoid discriminating anyone even subconsciously, so he would like to show every resume without a photo or name on them before he decides on his ten top candidates.

Thinking of use cases helps us explore people’s needs without having to conduct expensive user experience research right away and it will also help us recognize the limits or weaknesses our approach might face – so feel free to jot down your use case thoughts in any form you prefer, as long as there is at least a title, actor role, and description provided.

Base Format: .cv2

As proposed on August 23, 2015, we will continue with a base format using the filename extension .cv2. The purpose of creating a .cv2 is to focus solely on defining a universal and extensible resume format.

Existing solutions are based on one way to present a resume, thereby mostly excluding other options, formats, and visualizations. Much like a passport has all important data needed for travelling, a CV 2.0 represents a job passport that can be filtered, printed, and viewed in several formats and visualizations.

After some time, we will collaborate with other Working and Community Groups in order to incorporate standards that are useful for integration into and adoption of the CV 2.0.

Proposals for a .cv2 syntax and calls for contributions will be announced within the next days.

Vote: Base Format

Following up on our mailing list discussion (see subsequent mails for further replies), a vote is needed in order to proceed. According to the charter:

Voting

Votes are public and any decision needs 2/3 of voting participants to come into effect. Voting lasts for 14 days or until all Participants have voted.

The vote is about the format that we use as basis for our work.

Here are the options, ordered alphabetically:

  • .cv2: CV2 (suggestion is to use schema.org properties as tag names and decide on a simple syntax)
  • .html: HTML+RDF
  • .html: HTML+schema.org
  • .json: JSON Resume
  • .rdf: RDF

The vote is effective until September 8th, 2015. This is a call to all participants of this group – please vote on one of these options per e-mail to the public mailing list, otherwise we have to wait until the vote is over. Ideally, we have a consensus decision or at least 5/7 participants voting for the same format. Otherwise 2/3 of the voting participants are needed for a decision.

If you definitely want to abstain from voting, please state so as well, so we don’t have to wait the full 14 days. Thank you!