Re: Proposal: General Workflow and Filename Extension [via CV 2.0 - Global Resume Community Group]

I avoided being too technical so far because I showed the e-mails to some
recruiters I am in contact with and most of them don't really understand
what we're talking about but I think it's not really necessary for them to
be informed about all the technical details. They're far more interested in
software using the specification we create. So I'll use this e-mail to go a
little more in-depth since we do want to end up working with something on
which we all agree. For a summary, see the last part of my e-mail.

Here's a snapshot of what I think we both agree on:
1. We need some original file format that can then be mapped to other
formats because the ultimate goal is to edit one file and have various
output files. So part of our work involves resume-specific mapping in any
case.
2. This original file format is going to have a file extension.

Now to the points where our opinions differ - I am not happy with the bulk
code added in HTML format as simplicity is the key and is less error-prone.
What I thought of initially, might look like XML at first, but as I said,
it should have ideally been a listed collection of schema.org properties,
eventually including our own schema.org extension had we needed it,
removing all the bulk and containing just purely property -> value (the
syntax is something we could have talked about). No presentation. I did not
want to use RDF because a resume is not a huge dataset and while we may
display any CV as a graph as well, it is not the main focus. The fairly
small dataset of a CV does not justify the added verbosity of RDF, although
I'm not opposed to using RDF syntax (without HTML) and just having an .rdf
in the end. The only thing that suffers with this solution might be
marketability but that depends on how well we establish what we are doing.

Later on, we might want to add functionalities so that companies can
display a graph containing resume informations from all applicants, but
here we have to discuss the technical details just as much as the privacy
part and it is doable no matter what format we use as base format.

HTML+RDFa is an option, yes, but the intention was NOT to have a
displayable file from the start. A displayable file format automatically
includes bulk data. It doesn't matter if the viewer of the .cv2 sees just
code using simple tags because most people will never open the .cv2 and
look at it directly. It is ultimately meant to be imported in bulk and
viewed in one presentation format based on the preferences of the viewer.
Or to be used by applicants who want to export one resume into several
formats and then apply their own style to those formats without having to
edit each and every file. And yes, it is very easy to edit the base format
if you just want to change your address, for example. Anyone can open the
file in a text editor and change their existing phone number to the new
one, assuming we're using a simple syntax.

I disagree with the statement that people don't want to manage their data,
but that doesn't matter for our purposes. We want interfaces for those
people who do not want to edit their data and those interfaces are much
more lightweight if we have one original file that maps to other formats.
Some formats won't be able to be mapped back to the original, and that's
fine. Mapping PDF back to usable HTML+schema.org or similar probably won't
happen or at least not in the early stages of our work.

In any case, what we need to be able to start working now is an original
file format. While we may have mappings to and from each format we support,
we have to concentrate on creating the mappings from the initial file first.

What is closest to being viable other than our own file format is
https://jsonresume.org/schema/. What they did was create their own thing,
though - because the existing options are all flawed for the purposes of a
next-gen CV. They are great for semantically brushing up your Web CV but
they do not help recruiters and people who simply do not need to have their
CV on the Web. I am repeating content from my last e-mails so I'll leave it
at that now.

-------------------
Summary: I am strictly against using .html as the original file format for
the reasons mentioned in several e-mails now. Unless all other participants
write that they prefer .html with either RDF or schema.org, this option is
out. I do not say .cv2 is the best option but it would have enabled smooth
mapping to infographic resumes and Web alike and while all decisions have
advantages and disadvantages, we just need a decision and then base our
work on it. If you are opposed to creating our own format, the next similar
existing option is JSON or standalone RDF. Check this out for a small part
of what I had in mind for our group: http://registry.jsonresume.org/,
except that this community does its own thing and I do not want to fragment
too much. I agree that creating another file format on top of all existing
ones does not aid with avoiding fragmentation but if we manage to create a
good enough specification, then we could lead it all back together.

I will call a vote via blog post so that we can conclude this decision and
move on to actual work. In my opinion, all options available in the vote
are viable and have their merits so I am happy continuing with whatever
base format we choose from the options declared in the upcoming vote.
-------------------

Have a great day,
Sanja