JSON Resume – a JSON-based open source standard for resumes(jsonresume.org)
jsonresume.org
JSON Resume – a JSON-based open source standard for resumes
http://jsonresume.org/
216 comments
Other people might be able to confirm it but I have never received an Europass while working in London. I was told I should never send a cv made with the Europass template as the relation between British people and European things is not always the best. I understand this might be incorrect but it was enough for me to avoid using it. Then I also spoke with some HR people from other European countries who told me they didn't really like Europass so in the end I created my own template using Bootstrap.
Europass is also largely unknown. Politics aside, it is a good format and I would much prefer to get standardized CVs like this, especially for the skill assessment in languages.
The problem here is: some European countries use very particular formats for their CVs. e.g. Germany has the "tabular CV", which expects all these things to be organized by time and date, it even includes where and when you went to Kindergarten. Europass doesn't fit many of those particularities (which is kind of the point).
The problem here is: some European countries use very particular formats for their CVs. e.g. Germany has the "tabular CV", which expects all these things to be organized by time and date, it even includes where and when you went to Kindergarten. Europass doesn't fit many of those particularities (which is kind of the point).
I had a brief look at HR-XML back when I was in love with XML - it's a very old standard, early-2000s, and yet it's never mentioned by any recruiting website, even "geek-oriented" ones that should know better.
At one point I even added an explicit line to my Word/PDF versions: "this document is also available in HR-XML format on request". Nobody ever asked, so eventually I just took the line out. I've never heard of Europass CV, but I live in England, where EU is a dirty word...
TBH, this is the sort of stuff most recruiters don't bother with anyway, in my experience the (European) recruiting industry runs on MS Office. Some industry vendors might do some munging and conversion behind the scenes, but they'll likely never allow people to submit their own data outside of tightly-checked web forms.
At one point I even added an explicit line to my Word/PDF versions: "this document is also available in HR-XML format on request". Nobody ever asked, so eventually I just took the line out. I've never heard of Europass CV, but I live in England, where EU is a dirty word...
TBH, this is the sort of stuff most recruiters don't bother with anyway, in my experience the (European) recruiting industry runs on MS Office. Some industry vendors might do some munging and conversion behind the scenes, but they'll likely never allow people to submit their own data outside of tightly-checked web forms.
it's a classic case of http://xkcd.com/927/
but this one is written in NodeJS. So it is so much more scalabale!!!11!!!! :-)
I like the idea, because I deal with a lot of resumes and can't parse them programmatically.
Some thoughts:
- Eliminate first/last name distinction, and let people just put in their full or legal/passport name. Names are very crazy across cultures, as in some people don't have first or last names, so might as well just let them enter free form text as their name.
- Include a "Preferred name" field, also as freeform text. Some people like to go by nicknames, or shortenings of their names, and it will help out.
- Collapse location region and state into a single field.
- If "websites" is a hash with only a single field, call it "website" and make it a string.
Some thoughts:
- Eliminate first/last name distinction, and let people just put in their full or legal/passport name. Names are very crazy across cultures, as in some people don't have first or last names, so might as well just let them enter free form text as their name.
- Include a "Preferred name" field, also as freeform text. Some people like to go by nicknames, or shortenings of their names, and it will help out.
- Collapse location region and state into a single field.
- If "websites" is a hash with only a single field, call it "website" and make it a string.
Awesome feedback, we already have an issue created for the firstName/lastName dilemma.
Will create issues for your other feedback -> https://github.com/jsonresume/resume-schema
Will create issues for your other feedback -> https://github.com/jsonresume/resume-schema
This is cool! We do a lot of work with JSON Schema at Snowplow. Here's a few suggestions:
1. Semantic versioning doesn't work for schemas. (What's a patch/bug fix for a schema? It's meaningless.) Use SchemaVer instead - http://snowplowanalytics.com/blog/2014/05/13/introducing-sch...
2. Make your schema self-describing so that a given resume instance is associated with its schema version http://snowplowanalytics.com/blog/2014/05/15/introducing-sel...
3. Publish your JSON Schemas to Iglu Central, the first schema registry for JSON Schema - https://github.com/snowplow/iglu-central
1. Semantic versioning doesn't work for schemas. (What's a patch/bug fix for a schema? It's meaningless.) Use SchemaVer instead - http://snowplowanalytics.com/blog/2014/05/13/introducing-sch...
2. Make your schema self-describing so that a given resume instance is associated with its schema version http://snowplowanalytics.com/blog/2014/05/15/introducing-sel...
3. Publish your JSON Schemas to Iglu Central, the first schema registry for JSON Schema - https://github.com/snowplow/iglu-central
Adding your issues to the tracker and also thanks for the link to Iglu central!
Nice one! If I can help in any way, just let me know. Iglu and Iglu Central are very young but we're v excited about them.
I imagine you have seen http://schemastore.org/
Cool - hadn't seen that. I really like the catalog concept - we didn't have that in Iglu previously, have added a ticket for it. I'll reach out to Mads - thanks for the link!
I disagree with so many people in this discussion recommending XML without much reason. The best reason I've ever seen to pick XML over JSON is mixing text and elements, and that doesn't seem like an issue, here.
As for feedback on the schema itself, I'd probably like to see some more detail allowed for the courses under education. I remember after graduating, there really wasn't anything more substantial that I could put other than details about my courses. Using the example on your page, I think "HS1302" and "Introduction to American History" could possibly be separate fields, and I think there should be an additional details/description/highlights field.
Also, I am a consultant, and I like to list a projects section. Each project could have a name, a client, an employer (the consulting company), a date range, and details.
As for feedback on the schema itself, I'd probably like to see some more detail allowed for the courses under education. I remember after graduating, there really wasn't anything more substantial that I could put other than details about my courses. Using the example on your page, I think "HS1302" and "Introduction to American History" could possibly be separate fields, and I think there should be an additional details/description/highlights field.
Also, I am a consultant, and I like to list a projects section. Each project could have a name, a client, an employer (the consulting company), a date range, and details.
Thanks! Will copy your feedback where appropriate to the issue tracker
If only there was an extensible markup language you could employ to create a resume standard.
//
Seriously, JSON really sucks at markup (it also kinda sucks as data interchange as well, but let's not worry about that here). This 'standard' is so hand-wavy. Every property is a 'string', so why are you even bothering putting it in? Right, not really 'strings' because a bunch of fields have a JavaScript (so we're not really sticking JSON here, are we!) comments to describe it. Presumably order of object properties matters, or maybe it doesn't, or maybe it matters for some (e.g. root object / address) and not for others (eg. phone numbers). Date format? Who needs that! Which fields are optional? All of them? Some of them? None of them? I like the 'hobby' field. Complete waste of space on a real resume and a complete waste of space here as well (hah: hobby name and hobby keyword). Urgh.
It's a mess. A total mess.
//
Seriously, JSON really sucks at markup (it also kinda sucks as data interchange as well, but let's not worry about that here). This 'standard' is so hand-wavy. Every property is a 'string', so why are you even bothering putting it in? Right, not really 'strings' because a bunch of fields have a JavaScript (so we're not really sticking JSON here, are we!) comments to describe it. Presumably order of object properties matters, or maybe it doesn't, or maybe it matters for some (e.g. root object / address) and not for others (eg. phone numbers). Date format? Who needs that! Which fields are optional? All of them? Some of them? None of them? I like the 'hobby' field. Complete waste of space on a real resume and a complete waste of space here as well (hah: hobby name and hobby keyword). Urgh.
It's a mess. A total mess.
You are right, it is a mess, we are working on the specification at the moment and deciding on correct data types and semantics. If you think with a bit of love it can be made into a usable standard please come help us out at https://github.com/jsonresume/resume-schema/issues
JSON is the problem, so this will continue to be a mess. Especially if you have hopes for this to be used by many many people and especially if you hope this can be ingested by many many different systems (e.g. every resume submission server for every company). You need to formalize the structure, so you need some sort of a formal schema. You may pretend you don't need one, but you kinda have one right now. The schema you have right now is your example structure and JavaScript comments.
You do realize that there is a JSON Schema specification, not to mention that JSON more naturally matches a program's object structure for serialization and deserialization. Generally speaking XML is more flexible than any object representation should be. Objects tend to have properties, and those properties may be a given type. But XML may define some properties as attributes, and others as a single /nested child element and others as 1+ child elements, or a child element with 1+ child elements. JSON is a natural, easy to understand and comprehend map without extra content that really isn't needed. JSON maps neatly to several object streaming systems, XML does not.
I'm sorry, but XML isn't some panacea of describing or encoding document structures. It's generally a collection of fragile verbose and overly complicated tools in a few given platforms to satisfy people that think enterprise programming means implementing every pattern that loosely fits their situation instead of clean, simple, elegant solutions that hide complexity where needed instead of creating more.
JSON + JSON-Schema is no more of a mess than XML + XML Schemas. And generally far more forgiving in any modern programing environment for client/server use.
I'm sorry, but XML isn't some panacea of describing or encoding document structures. It's generally a collection of fragile verbose and overly complicated tools in a few given platforms to satisfy people that think enterprise programming means implementing every pattern that loosely fits their situation instead of clean, simple, elegant solutions that hide complexity where needed instead of creating more.
JSON + JSON-Schema is no more of a mess than XML + XML Schemas. And generally far more forgiving in any modern programing environment for client/server use.
> JSON + JSON-Schema is no more of a mess than XML + XML Schemas.
However... the increasing prevalence of complex JSON formats may eventually make some form of JSON schema necessary.
So we formally defined the schema in the repository -> https://github.com/jsonresume/resume-schema/blob/master/sche...
That part on the homepage is a documentation generator I made for any given schema, it's suppose to be more of a go to reference manual but I guess that is unclear on the homepage.
All the modules have to pass the validator which is based off the formal specification in the repository. I think that is what you mean and as far as JSON is concerned, will keep at it for a bit and see how far it can go, if it's impossible hopefully a new standard in a correct format will take off and use some of the same tooling that we have built.
That part on the homepage is a documentation generator I made for any given schema, it's suppose to be more of a go to reference manual but I guess that is unclear on the homepage.
All the modules have to pass the validator which is based off the formal specification in the repository. I think that is what you mean and as far as JSON is concerned, will keep at it for a bit and see how far it can go, if it's impossible hopefully a new standard in a correct format will take off and use some of the same tooling that we have built.
Being an asshole on the internet isn't needed to get your point across.
Nice. Although I'm not too sure what the social implications of this would be. As it is already I think employers do too much parsing of resumes rather than looking at them with human eyes. PDF resumes are awesome in that you get a blank sheet of paper to do whatever you want with to impress the employer.
There's a lot of reading between the lines that can be done in an resume. Even the fonts say something about the person. If the person is claiming to be a UI designer and their resume has poorly chosen fonts and bad kerning, I'd toss it. If they claim to be a physics researcher and the resume is written in Word, I'd toss it too. With a JSON resume you don't get any of this information.
Also, it's not entirely clear how extensible this "standard" is. Resumes take multiple forms. A computer scientist might want to list a few open source projects. A photographer might want to embed a sample or two of their work.
There's a lot of reading between the lines that can be done in an resume. Even the fonts say something about the person. If the person is claiming to be a UI designer and their resume has poorly chosen fonts and bad kerning, I'd toss it. If they claim to be a physics researcher and the resume is written in Word, I'd toss it too. With a JSON resume you don't get any of this information.
Also, it's not entirely clear how extensible this "standard" is. Resumes take multiple forms. A computer scientist might want to list a few open source projects. A photographer might want to embed a sample or two of their work.
I'm glad you pointed this out.
The organization of a resume is almost as useful an introduction to a candidate as the terms on it. It's also useful to understand how much time was put into the resume.
> If they claim to be a physics researcher and the resume is written in Word, I'd toss it too.
Hm, that's going too far, though!
The organization of a resume is almost as useful an introduction to a candidate as the terms on it. It's also useful to understand how much time was put into the resume.
> If they claim to be a physics researcher and the resume is written in Word, I'd toss it too.
Hm, that's going too far, though!
But the relationship with future performance and these subjective "reading between the lines" opinions is unclear. You need standardization to reduce bias in hiring decisions and make them as objective as possible.
Yeah, I was going to say that this project is awesome, and I like the web themes, but the PDF export needs a lot of work. I think that will be the hardest aspect to achieve. Maybe some LaTeX resume themes can be borrowed from. There are some very nice ones in LaTeX.
Maybe. As someone who likes to be creative I'd still never use someone else's template though. Even the font I use on my resume I did some editing on because I didn't like the way a couple of the glyphs looked.
I think that gets to the heart of why a standard metadata-to-pretty-resume solution has never really taken off. The people who really care about it don't even bother trying to make a one-size-fits-all solution, since it's such a customized and personal undertaking. Glad to hear I'm not the only person who's spent countless hours tweaking my resume to the nth degree.
I think this is a great idea. I love the idea of a universal data format for resumes.
However, I'm not at all convinced that JSON is the way to do it. I think the way to do it is with XML and XSLT, although I already can hear the cries of "But XML is yucky and XSLT is hard." But by using JSON, we lose some semantic markup and end up having to parse it to create some semantic markup.
Still, I hope this, or something like it, takes off. This just needs a web-based GUI tool to publish a resume so that non-geeks can make it happen.
However, I'm not at all convinced that JSON is the way to do it. I think the way to do it is with XML and XSLT, although I already can hear the cries of "But XML is yucky and XSLT is hard." But by using JSON, we lose some semantic markup and end up having to parse it to create some semantic markup.
Still, I hope this, or something like it, takes off. This just needs a web-based GUI tool to publish a resume so that non-geeks can make it happen.
The EU has developed an XML standard for CVs years ago: http://interop.europass.cedefop.europa.eu/data-model/xml-res...
year="1975" month="--03" day="---01" ???
It was a very hard decision to make and starting such a movement is unfortunately from my viewpoint much more than making rational choices about the technologies. We wanted to have a low barrier to entry and also take advantage of the large ecosystem of libraries. At the moment the majority of web technologies are using JSON so we believe that to get this standard off the ground we will need to go with the grain.
LinkedIn actually exports into a Microformat called hResume which has been around for a long time but has evidently not been able to amass a large developer community. This was another reason we decided to not start with XML.
LinkedIn actually exports into a Microformat called hResume which has been around for a long time but has evidently not been able to amass a large developer community. This was another reason we decided to not start with XML.
> We wanted to have a low barrier to entry and also take advantage of the large ecosystem of libraries.
That doesn't make sense. You wanted a low barrier to entry, but you have to mark this up yourself with JSON, install command line tools, etc. Seems to me a web app that I fill in some forms and generate a page on your site would be the quickest way to lower the barrier.
> At the moment the majority of web technologies are using JSON so we believe that to get this standard off the ground we will need to go with the grain.
I understand the desire to use what's popular. But I just don't think it's the right choice. I'm interested to see the implementation of how this is turned into a PDF though.
Right now, though, it does sound a bit like "every problem is a nail." Perhaps it'll become more clear to me as I dig in more.
Again, I do think the project is very cool and will be encouraging my students to take a look at how they can use this to promote themselves.
That doesn't make sense. You wanted a low barrier to entry, but you have to mark this up yourself with JSON, install command line tools, etc. Seems to me a web app that I fill in some forms and generate a page on your site would be the quickest way to lower the barrier.
> At the moment the majority of web technologies are using JSON so we believe that to get this standard off the ground we will need to go with the grain.
I understand the desire to use what's popular. But I just don't think it's the right choice. I'm interested to see the implementation of how this is turned into a PDF though.
Right now, though, it does sound a bit like "every problem is a nail." Perhaps it'll become more clear to me as I dig in more.
Again, I do think the project is very cool and will be encouraging my students to take a look at how they can use this to promote themselves.
Ahh I thought it might be better to start the movement at the developer level before asking regular people to opt in. So JSON was meant to be the common denominator for developers, hopefully they build tools that makes the process less technical for the general population.
We actually had to pull our PDF converter due to bugs and are currently just using a service called pdfcrowd.com.
Though the general idea is that HTML can be passed through WebKit and rendered as various image formats and PDF -> http://wkhtmltopdf.org/
Here is a link to what your first idea might look like, it automatically generates forms based of JSON specifications -> http://jeremydorn.com/json-editor/
We actually had to pull our PDF converter due to bugs and are currently just using a service called pdfcrowd.com.
Though the general idea is that HTML can be passed through WebKit and rendered as various image formats and PDF -> http://wkhtmltopdf.org/
Here is a link to what your first idea might look like, it automatically generates forms based of JSON specifications -> http://jeremydorn.com/json-editor/
Hey Thomas,
I'll start adapting resumebeacon.com to support jsonresume. I created my site as a LinkedIn resume generator, so integrating a JSON formatted feed shouldn't be much trouble. I'll start work on it tonight and post it to "show HN" when it's done.
I'll start adapting resumebeacon.com to support jsonresume. I created my site as a LinkedIn resume generator, so integrating a JSON formatted feed shouldn't be much trouble. I'll start work on it tonight and post it to "show HN" when it's done.
Hey Paul, Loving those themes. I would sort of recommend waiting until the specification grows some legs over the next week but you could go ahead as planned and just mark what you have done at v0.0.0
Sounds good. I'll check back in a week or so...
I see. Seems like a sound approach. If your thought was to get developers on board, then yes, JSON is probably the best way to do it.
> has evidently not been able to amass a large developer community
But let me guess: you will?
But let me guess: you will?
It's just as doomed as all the other attempts - recruiters don't generally care about machine readable versions of CVs (even though they should because it simplifies searching and matching).
(I've worked at three recruiters, two of the biggest in the UK)
(I've worked at three recruiters, two of the biggest in the UK)
> LinkedIn actually exports into a Microformat called hResume which has been around for a long time but has evidently not been able to amass a large developer community. This was another reason we decided to not start with XML.
So, not trying to be rude here, but have you wondered why it is that an XML resume format hasn't taken off? Other than it being based on icky XML? I mean XML+XSLT has been around for a loooong time and can more than handle exactly what this format sets out to do, and yet a standard XML resume format hasn't taken off.
So, not trying to be rude here, but have you wondered why it is that an XML resume format hasn't taken off? Other than it being based on icky XML? I mean XML+XSLT has been around for a loooong time and can more than handle exactly what this format sets out to do, and yet a standard XML resume format hasn't taken off.
There's nothing particularly "icky" about XML. That's just a silly hipster meme. XML is just a tool, it makes sense in some places, less so in others. Same deal for JSON.
I mean XML+XSLT has been around for a loooong time and can more than handle exactly what this format sets out to do, and yet a standard XML resume format hasn't taken off.
It's just as likely that the answer is "a standard resume format hasn't taken off" where the serialization format is irrelevant. Maybe not enough people are interested in working with documents and knowledge at that deeper, semantically meaningful level. Maybe sending resumes as PDF or MS Word or ODT and using simple keyword extraction has been "good enough" that nobody has felt the pull to use a better system?
What I mean is, it's entirely possible that this will fail to gain adoption for the exact same reason that the XML based one(s) did, and that the difference between JSON and XML is actually irrelevant. This is, of course, just speculation on my part. In any case, I hope this (or something like it) gains traction, since I'm a strong proponent of publishing semantically meaningful content, whether it's in RDF/XML, JSON-LD, SGML, DAML+OIL, YAML, Texinfo, Markdown, Hytime or hieroglyphics chiseled into stone tablets. :-)
I mean XML+XSLT has been around for a loooong time and can more than handle exactly what this format sets out to do, and yet a standard XML resume format hasn't taken off.
It's just as likely that the answer is "a standard resume format hasn't taken off" where the serialization format is irrelevant. Maybe not enough people are interested in working with documents and knowledge at that deeper, semantically meaningful level. Maybe sending resumes as PDF or MS Word or ODT and using simple keyword extraction has been "good enough" that nobody has felt the pull to use a better system?
What I mean is, it's entirely possible that this will fail to gain adoption for the exact same reason that the XML based one(s) did, and that the difference between JSON and XML is actually irrelevant. This is, of course, just speculation on my part. In any case, I hope this (or something like it) gains traction, since I'm a strong proponent of publishing semantically meaningful content, whether it's in RDF/XML, JSON-LD, SGML, DAML+OIL, YAML, Texinfo, Markdown, Hytime or hieroglyphics chiseled into stone tablets. :-)
Agreed. There is one difference with json (and yaml) though: it truly is more human writable (and readable), and by extension provides nicer diffs. I'd be much more happy to maintain my resume in json than in XML, even if I might be more happy exchanging/submitting resumes with (one of) the existing XML standards.
But all that's needed is a script that eats XML resumes and outputs json resumes, and vice versa.
Just like I'd rather write markdown and read (rendered) html+css.
That said, on the subject of XML not being "icky": one resource for having fun with XML: "Program Generators with XML and Java" by J. Craig Cleaveland (Prentice-Hall, 2001):
http://craigc.com/pg/
But all that's needed is a script that eats XML resumes and outputs json resumes, and vice versa.
Just like I'd rather write markdown and read (rendered) html+css.
That said, on the subject of XML not being "icky": one resource for having fun with XML: "Program Generators with XML and Java" by J. Craig Cleaveland (Prentice-Hall, 2001):
http://craigc.com/pg/
Hm, looks like there might be bit too many dependencies here for my taste:
Still, can't complain, 5 minutes and I have a resume draft that doesn't look half bad in html, and is presumably entirely reasonable to customize (not to mention it's all inn a json-file anyway, so one could just use what's in ones actual resume, and shove the json through pretty much any scripting language w/templates and generate something reasonable).
npm install resume-cli
du -hs node_modules
103M node_modules
Still, can't complain, 5 minutes and I have a resume draft that doesn't look half bad in html, and is presumably entirely reasonable to customize (not to mention it's all inn a json-file anyway, so one could just use what's in ones actual resume, and shove the json through pretty much any scripting language w/templates and generate something reasonable).
Sorry about the large dependency size, we were mainly rapidly prototyping and didn't expect so much usage. That size will drastically be reduced and we hope to have better error reporting.
Currently have 60 fresh issues on Github for the schema so after we digest those we will be improving the CLI once again.
Currently have 60 fresh issues on Github for the schema so after we digest those we will be improving the CLI once again.
> There's nothing particularly "icky" about XML.
> It's just as likely that the answer is "a standard resume format hasn't taken off" where the serialization format is irrelevant.
Just to be clear, I was taking the same position you were...
Just to be clear, I was taking the same position you were...
I honestly don't like XML, not that there aren't very verbose tools and standards to make it easier to use, but intrinsically you can't look at XML file and know how a codified representation should look like... if you have an element it will have properties and child elements... said child elements may contain children, strings, or ??? ... JSON maps much more naturally to an object model in a given language. That's just one way that by example you can show JSON, and know what you need to make.
Not to mention, XML is much more verbose, and when you wrap it in things like ws*/SOAP it gets really ugly really quickly, and if you don't map everything, it gets complicated and often fails. When you publish a service using one toolkit, it's often difficult to use the service in another toolkit (example, using Java services in .Net gets really painful at times). Unless a lot of detail is done, or an API client in that client's environment is provided.
This isn't about XML specifically but about the environment it tends to create. JSON is typically simpler to write, easier to code against and more forgiving in the tooling than XML is. Much like the differences between a scripted environment and a statically compiled environment.
Not to mention, XML is much more verbose, and when you wrap it in things like ws*/SOAP it gets really ugly really quickly, and if you don't map everything, it gets complicated and often fails. When you publish a service using one toolkit, it's often difficult to use the service in another toolkit (example, using Java services in .Net gets really painful at times). Unless a lot of detail is done, or an API client in that client's environment is provided.
This isn't about XML specifically but about the environment it tends to create. JSON is typically simpler to write, easier to code against and more forgiving in the tooling than XML is. Much like the differences between a scripted environment and a statically compiled environment.
wait... I don't understand comments like these. You're not the only one to make these claims, but I'll address yours specificially:
> but intrinsically you can't look at XML file and know how a codified representation should look like...
Let's compare:
1. need a schema to be useful as a standard 2. express their hierarchy 3. don't specify data type (although I could add that info to both if needed) 4. have a level of annoying to them (commas, colons, angle brackets, etc) which modern IDEs have taken care of for us.
> if you have an element it will have properties and child elements... said child elements may contain children, strings, or ???
I need to use documentation to use `package.json` files too, because each node may or may not contain children. Node graciously tells me if I missed something. Docbook also tells me if my XML is malformed. I see no difference here,
> JSON maps much more naturally to an object model in a given language.
It maps to a hash/dictionary. I'm not sure that qualifies as an "object model" unless you only write JavaScript.
I'd really like people to understand that XML is, like HTML, really great at describing and marking up content so that something else may process it.
> but intrinsically you can't look at XML file and know how a codified representation should look like...
Let's compare:
<book>
<title>How To Be Awesome</title>
<subtitle>Surviving on HN Posts</subtitle>
<author>
<first_name>Max</first_name>
<last_name>Power</last_name>
</author>
</book>
{
"title": "Being Awesome",
"subtitle" : "Surviving on HN Posts",
"author": {
"first_name" : "Max",
"last_name" : "Power"
}
}
1. need a schema to be useful as a standard 2. express their hierarchy 3. don't specify data type (although I could add that info to both if needed) 4. have a level of annoying to them (commas, colons, angle brackets, etc) which modern IDEs have taken care of for us.
> if you have an element it will have properties and child elements... said child elements may contain children, strings, or ???
I need to use documentation to use `package.json` files too, because each node may or may not contain children. Node graciously tells me if I missed something. Docbook also tells me if my XML is malformed. I see no difference here,
> JSON maps much more naturally to an object model in a given language.
It maps to a hash/dictionary. I'm not sure that qualifies as an "object model" unless you only write JavaScript.
I'd really like people to understand that XML is, like HTML, really great at describing and marking up content so that something else may process it.
You could also have <book title="..." subtitle="..." >... There's no real canonical representation of what an object should look like... can you have more than one title tag for a book? If you look at your xml, you don't know. Can you have more than one author tag? from the xml, you don't know... both of these, you do know looking at the json.
I'm not entirely sure, something to do with XML not being human readable maybe. All I can really say is that I don't use XML most of the time is because I'm lazy, JSON.parse() is just too easy but I also don't know XML that well and I believe that is because the large majority of RESTful interface's I work with are JSON.
Though I would love to hear someone else's thoughts on why an XML resume hasn't gained critical mass.
Though I would love to hear someone else's thoughts on why an XML resume hasn't gained critical mass.
The trick with XML is to learn XSLT. The trick with that is it's really a weird language that uses recursion and acts almost functional, but not. But if you learn that, you don't have to parse anything because you just "style" the xml.
Here's a silly playground I wrote to show my students XML.
http://xslteatime.herokuapp.com/
There's a pre-built example you can run.
Here's a silly playground I wrote to show my students XML.
http://xslteatime.herokuapp.com/
There's a pre-built example you can run.
> I'm not entirely sure, something to do with XML not being human readable maybe.
XML is perfectly human-readable...
> but I also don't know XML that well
Suddenly that statement makes sense.
XML is perfectly human-readable...
> but I also don't know XML that well
Suddenly that statement makes sense.
> At the moment the majority of web technologies are using JSON
The majority of which technologies? The CV generators that are already out there, which are the most relevant ones, don't use JSON. How are you creating a low barrier to entry by completely disregarding what people are already using?
The majority of which technologies? The CV generators that are already out there, which are the most relevant ones, don't use JSON. How are you creating a low barrier to entry by completely disregarding what people are already using?
[deleted]
Anyone that has ever used xslt in a non-trivial way most likely understands that it is a terrible answer to just about any problem. Complexity for the sake of complexity is never a good path to follow.
I've written 7 books with it and those books have been published in print, PDF, epub, and mobi. I think that's non-trivial. But if you're referring to SOAP and WS* and all that stuff from the J2EE days, the I agree. That's a terrible terrible solution.
In my opinion, it should be RDF, so that we can programmatically define a common structure, link to shared concepts (e.g. programming languages) and to other personal documents. If it's encoded XML, JSON-LD, or (my personal favorite) Turtle, that's mostly irrelevant.
XML is a horrendous technology.
JSON was a much better choice. YAML would have been better still (it's more human readable), but both beat XML hands down in any situation.
JSON was a much better choice. YAML would have been better still (it's more human readable), but both beat XML hands down in any situation.
XML was horrible for data interchange, configuration, and all the other crap people used it for.
It's one of the best tools for marking up content. It's a Markup Language! If you've never used XSLT you really should look at what it can do. Because I can transform an XML resume into something gorgeous without writing too much programming logic.
It's the reason so many technical book publishers use XML. Easy to transform content while also describing that content.
It's one of the best tools for marking up content. It's a Markup Language! If you've never used XSLT you really should look at what it can do. Because I can transform an XML resume into something gorgeous without writing too much programming logic.
It's the reason so many technical book publishers use XML. Easy to transform content while also describing that content.
It is horrible for markup too. It is far, far, far too complex and far more verbose than it needs to be. These are the hallmarks of a bad language (or metalanguage).
It is absurdly popular in bureaucratic environments. Bureaucrats adore its complex rules, ability to create arcane standards and illusion of openness. It's also good for job security. However, none of that bodes well for the rest of us.
I have used XSLT and I am absolutely appalled that something like that can even exist. It's actually worse than XML. It is a turing complete language (this means that you can make it as complex as you like, and boy oh boy does THAT happen), but its readability is AWFUL.
There is a reason we have other general purpose languages turing complete like python or javascript or even java and that is because, while they may have some warts, they have had a lot more thought put into them in order to help make them more consistent, better structured and readable than similarly committee-designed / thrown together languages like XSLT.
I can use a normal programming language transform a JSON resume into something gorgeous and I GUARANTEE it will be lot easier to read and modify than your XSLT equivalent.
Sorry to rain on your parade, but it's true.
It is absurdly popular in bureaucratic environments. Bureaucrats adore its complex rules, ability to create arcane standards and illusion of openness. It's also good for job security. However, none of that bodes well for the rest of us.
I have used XSLT and I am absolutely appalled that something like that can even exist. It's actually worse than XML. It is a turing complete language (this means that you can make it as complex as you like, and boy oh boy does THAT happen), but its readability is AWFUL.
There is a reason we have other general purpose languages turing complete like python or javascript or even java and that is because, while they may have some warts, they have had a lot more thought put into them in order to help make them more consistent, better structured and readable than similarly committee-designed / thrown together languages like XSLT.
I can use a normal programming language transform a JSON resume into something gorgeous and I GUARANTEE it will be lot easier to read and modify than your XSLT equivalent.
Sorry to rain on your parade, but it's true.
> It is horrible for markup too. It is far, far, far too complex and far more verbose than it needs to be.
Oh stop. XML syntax is freaking simple. <tag>content</tag>, <tag><child>...</child>...</tag>, or <tag attribute="value" ...></tag>. Toss in namespaces for composing other formats _if need be_ (and you don't have to use them). And... you're done for 99.9% of any use case you can think of. You have to repeat yourself when you close a tag. Whoopdedoo. Any decent editor will close them for you anyway. I think the "XML sucks" crowd are conflating very complex XML _formats_ with XML _itself_ and deciding that XML is ridiculously complex and verbose because e.g., SOAP is complex and verbose.
Just curious, do you hate HTML for similar reasons as well?
Oh stop. XML syntax is freaking simple. <tag>content</tag>, <tag><child>...</child>...</tag>, or <tag attribute="value" ...></tag>. Toss in namespaces for composing other formats _if need be_ (and you don't have to use them). And... you're done for 99.9% of any use case you can think of. You have to repeat yourself when you close a tag. Whoopdedoo. Any decent editor will close them for you anyway. I think the "XML sucks" crowd are conflating very complex XML _formats_ with XML _itself_ and deciding that XML is ridiculously complex and verbose because e.g., SOAP is complex and verbose.
Just curious, do you hate HTML for similar reasons as well?
You've forgotten:
* DOCTYPE
* Namespaces and namespace collision handling.
* The likelihood that you will receive badly formed XML and be forced to parse it anyway.
* The multiple different ways of escaping characters.
* Language identification
...I could go on.
Oh, and your parser has to handle ALL of this. It's no good assuming that "since the basics are fairly basic it doesn't matter". It doesn't matter only when you're generating XML, but somebody SOMEWHERE is going to have to consume it.
Wanna know why it's typically possible to blow up an XML parser with a memory leak or a buffer overflow but not a JSON parser? This complexity is why. Just using it creates an increased attack surface for your internet facing API.
>Just curious, do you hate HTML for similar reasons as well?
I'm not its biggest fan, and I feel like it could have been done a lot better. However, A) there isn't much alternative so bitching about it it somewhat pointless and B) at least I never have parse it (want an exercise in frustration some time? try doing THAT...).
* DOCTYPE
* Namespaces and namespace collision handling.
* The likelihood that you will receive badly formed XML and be forced to parse it anyway.
* The multiple different ways of escaping characters.
* Language identification
...I could go on.
Oh, and your parser has to handle ALL of this. It's no good assuming that "since the basics are fairly basic it doesn't matter". It doesn't matter only when you're generating XML, but somebody SOMEWHERE is going to have to consume it.
Wanna know why it's typically possible to blow up an XML parser with a memory leak or a buffer overflow but not a JSON parser? This complexity is why. Just using it creates an increased attack surface for your internet facing API.
>Just curious, do you hate HTML for similar reasons as well?
I'm not its biggest fan, and I feel like it could have been done a lot better. However, A) there isn't much alternative so bitching about it it somewhat pointless and B) at least I never have parse it (want an exercise in frustration some time? try doing THAT...).
> You've forgotten:
I was mentioning the "99.9%" use case of XML for e.g., a resume format. You don't have to specify DOCTYPEs, namespaces, etc.
> The likelihood that you will receive badly formed XML and be forced to parse it anyway.
You're supposed to fail on badly-formed XML!
> Oh, and your parser has to handle ALL of this.
So? I don't have to write an XML parser because there are numerous well-tested ones already written. I wouldn't write a JSON parser for the same reason.
> Wanna know why it's typically possible to blow up an XML parser with a memory leak or a buffer overflow but not a JSON parser?
First of all, you shouldn't speak in absolutes. You certainly could write a JSON parser that blows up for the same reasons. There's nothing inherent in JSON that makes it impossible to write a bad parser.
> at least I never have parse it (want an exercise in frustration some time? try doing THAT...).
For anything more than a trivial format you can automatically have the parser bind the content to a POJO (or your language's "plain old object" analogue).
I was mentioning the "99.9%" use case of XML for e.g., a resume format. You don't have to specify DOCTYPEs, namespaces, etc.
> The likelihood that you will receive badly formed XML and be forced to parse it anyway.
You're supposed to fail on badly-formed XML!
> Oh, and your parser has to handle ALL of this.
So? I don't have to write an XML parser because there are numerous well-tested ones already written. I wouldn't write a JSON parser for the same reason.
> Wanna know why it's typically possible to blow up an XML parser with a memory leak or a buffer overflow but not a JSON parser?
First of all, you shouldn't speak in absolutes. You certainly could write a JSON parser that blows up for the same reasons. There's nothing inherent in JSON that makes it impossible to write a bad parser.
> at least I never have parse it (want an exercise in frustration some time? try doing THAT...).
For anything more than a trivial format you can automatically have the parser bind the content to a POJO (or your language's "plain old object" analogue).
I have to agree. XML can be complicated, or can at least look complicated when using lots of namespaces and what-not, but for most purposes it's dead simple and about as easy to understand as anything else.
Truth be told, I find XML easier to read than JSON in many cases. shrug
Truth be told, I find XML easier to read than JSON in many cases. shrug
Sorry to rain on yours, but XML isn't bad. The way people used it is bad.
Just because you were forced to use bad schemas in enterprisey situations doesn't mean XML is bad. SOAP is not XML. Spring MVC is not XML. Those things use XML.
Docbook's pretty easy to follow. That, in my opinion, is a great example of XML+XSLT.
With XML I can do this:
<experience> <title>Manager</title> <company>Veridian Dynamics</company> <description> Responsible for doing all manner of things. </description> </experience>
It describes exactly what we're looking for in the same way as the JSON variant does. My editor will auto-close those tags the same way my editor will auto-close the closing curly braces in the JSON version.
Of course, we could make it suck if we just go ahead and add all sorts of extra rules and hierarchy and turn it into a monstrosity.
But I'd rather not.
Just because you were forced to use bad schemas in enterprisey situations doesn't mean XML is bad. SOAP is not XML. Spring MVC is not XML. Those things use XML.
Docbook's pretty easy to follow. That, in my opinion, is a great example of XML+XSLT.
With XML I can do this:
<experience> <title>Manager</title> <company>Veridian Dynamics</company> <description> Responsible for doing all manner of things. </description> </experience>
It describes exactly what we're looking for in the same way as the JSON variant does. My editor will auto-close those tags the same way my editor will auto-close the closing curly braces in the JSON version.
Of course, we could make it suck if we just go ahead and add all sorts of extra rules and hierarchy and turn it into a monstrosity.
But I'd rather not.
No, it IS bad and the complaint that 'people use it badly' is simply an excuse to cover for its deficiencies. In many ways, its deficiencies (which YAML/JSON do not have) are an incitement to use it badly, but that's far from the only problem with it.
I am not complaining about being forced to use bad schemas in enterprisey situations, either. That is merely the icing on the cake of the badness that is XML.
I am complaining simply because there is not one instance I have ever come across in my entire programming career (12 years now) where XML would have served me better than an alternative (assuming I had a choice). Zero.
For example:
>With XML I can do this: > ><experience> <title>Manager</title> <company>Veridian Dynamics</company> <description> Responsible for doing all manner of things. </description> </experience>
Yes, you can, but so what? You can do that in YAML and JSON too. Furthermore, your YAML/JSON parser is 10x less complex, faster, less likely to have buffer overflow security issues and less likely to have memory leaks.
Furthermore, while my app that consumes this markup will probably have to treat <experience><title>Manager<company>Veridian</experience> as valid, because consuming badly formed XML is standard and expected (your product manager will probably treat not parsing it as a bug), my app won't EVER have to treat invalid JSON as valid.
>Of course, we could make it suck
Yes, and there's a 90% chance somebody will. Whereas with JSON and YAML the chances of it being made to suck are far lower, because so many of the unnecessary avenues which are used to make XML suck are closed off in YAML.
I am not complaining about being forced to use bad schemas in enterprisey situations, either. That is merely the icing on the cake of the badness that is XML.
I am complaining simply because there is not one instance I have ever come across in my entire programming career (12 years now) where XML would have served me better than an alternative (assuming I had a choice). Zero.
For example:
>With XML I can do this: > ><experience> <title>Manager</title> <company>Veridian Dynamics</company> <description> Responsible for doing all manner of things. </description> </experience>
Yes, you can, but so what? You can do that in YAML and JSON too. Furthermore, your YAML/JSON parser is 10x less complex, faster, less likely to have buffer overflow security issues and less likely to have memory leaks.
Furthermore, while my app that consumes this markup will probably have to treat <experience><title>Manager<company>Veridian</experience> as valid, because consuming badly formed XML is standard and expected (your product manager will probably treat not parsing it as a bug), my app won't EVER have to treat invalid JSON as valid.
>Of course, we could make it suck
Yes, and there's a 90% chance somebody will. Whereas with JSON and YAML the chances of it being made to suck are far lower, because so many of the unnecessary avenues which are used to make XML suck are closed off in YAML.
I don't have to do anything with XML that I don't want to. I don't have to accept XML that doesn't conform to my schema. You're talking web services again and I'm talking about resumes. You're talking general and I'm talking about a specific place, publishing content, where XML shines. See previous comments - I use XML daily in book publishing. It is not anything like what you're making it out to be.
XML is a markup language. JSON is a serialization language. YAML is a serialization language too. I want to semantically mark up my content. And this is very different than application programming with XML.
You want to write a book with Docbook's XML? Better give it exactly what it wants, or it will reject it. It's not SOAP.
XML is a markup language. JSON is a serialization language. YAML is a serialization language too. I want to semantically mark up my content. And this is very different than application programming with XML.
You want to write a book with Docbook's XML? Better give it exactly what it wants, or it will reject it. It's not SOAP.
The way I see it we actually want to serialize a datastructure. We have many potential use cases not just presentation. If I download a thousand resumes I'm not as interested in viewing them as documents as I am in consuming them as datastructures, doing filtering / machine learning / ranking / ..
The way I look at it this is as much (and probably way more) a platform to write services on top of as it is a another hole to throw resume.xml down. And for that, json is undeniably better suited.
Nobody is trying to convince you to publish books in json.
The way I look at it this is as much (and probably way more) a platform to write services on top of as it is a another hole to throw resume.xml down. And for that, json is undeniably better suited.
Nobody is trying to convince you to publish books in json.
Give it time. As long as JSON is "the answer", people will build more layers of stuff on top of it.
Just like XML.
Just like XML.
>I don't have to accept XML that doesn't conform to my schema.
Yes you do, because otherwise people will treat your application as buggy. People have tried doing this with browsers and it never, EVER, ever works. If one app accepts malformed markup, they expect every other one to do it as well and no amount of preaching about the sanctity of well formed markup is going to change their mind.
>You're talking web services again and I'm talking about resumes.
If resumes are going to be done in markup it's so they can be consumed by web services. There is no point in having a machine readable language if it's not going to be read by machines.
>You're talking general and I'm talking about a specific place, publishing content, where XML shines.
I would rather use LaTeX for publishing content. It's complex, but it can handle layout beautifully.
Docbook is complex and it can't: http://www.docbook.org/tdg/en/html/part2.html
For simple markup, I would rather use markdown. Markdown in YAML would probably be a better solution than docbook, but docbook's the standard now, so not much you can really do about that.
Yes you do, because otherwise people will treat your application as buggy. People have tried doing this with browsers and it never, EVER, ever works. If one app accepts malformed markup, they expect every other one to do it as well and no amount of preaching about the sanctity of well formed markup is going to change their mind.
>You're talking web services again and I'm talking about resumes.
If resumes are going to be done in markup it's so they can be consumed by web services. There is no point in having a machine readable language if it's not going to be read by machines.
>You're talking general and I'm talking about a specific place, publishing content, where XML shines.
I would rather use LaTeX for publishing content. It's complex, but it can handle layout beautifully.
Docbook is complex and it can't: http://www.docbook.org/tdg/en/html/part2.html
For simple markup, I would rather use markdown. Markdown in YAML would probably be a better solution than docbook, but docbook's the standard now, so not much you can really do about that.
Hard to not see you're way too stubborn.
> Yes you do, because otherwise people will treat your application as buggy
You are mistaking HTML/Browser rendering and XML parsing. An application that parses XML for book rendering, or whatever the hell the purpose of the application is, will fail on invalid input, whether it is because of invalid tag nesting or schema invalidity.
That is NORMAL, and you would do the same with JSON, so that's not because of history of HTML and IE/Netscape/whatever that you need to change your mind about XML.
> If resumes are going to be done in markup it's so they can be consumed by web services
So if a web service was to accept a specific type of XML, it would certainly need to be made valid, if a client does not conform why the fuck do you want your service to be permissive? Seriously.
You can make a service that accepts the resume schema directly, or embed it in a CDATA if you want to.
> I would rather use LaTeX for publishing content. It's complex, but it can handle layout beautifully
Talking about apple and oranges. XML and docbook are not the same.
> Yes you do, because otherwise people will treat your application as buggy
You are mistaking HTML/Browser rendering and XML parsing. An application that parses XML for book rendering, or whatever the hell the purpose of the application is, will fail on invalid input, whether it is because of invalid tag nesting or schema invalidity.
That is NORMAL, and you would do the same with JSON, so that's not because of history of HTML and IE/Netscape/whatever that you need to change your mind about XML.
> If resumes are going to be done in markup it's so they can be consumed by web services
So if a web service was to accept a specific type of XML, it would certainly need to be made valid, if a client does not conform why the fuck do you want your service to be permissive? Seriously.
You can make a service that accepts the resume schema directly, or embed it in a CDATA if you want to.
> I would rather use LaTeX for publishing content. It's complex, but it can handle layout beautifully
Talking about apple and oranges. XML and docbook are not the same.
>You are mistaking HTML/Browser rendering and XML parsing.
I am not mistaking, I am comparing.
>An application that parses XML for book rendering, or whatever the hell the purpose of the application is, will fail on invalid input
Which will be treated as a bug if other applications DON'T fail (which some undoubtedly will).
>That is NORMAL, and you would do the same with JSON
In my experience the OPPOSITE is normal. If XML is invalid but still makes sense, you treat it as valid, because if you don't, your competitors will.
If the customer is getting XML from output X and feeding into your app, he doesn't care that output X is outputting invalid XML if your competitors' apps accept it. He'll just treat your app as the broken one, not buy it and move on with his life and you've just lost a sale. I've seen it happen MANY times. This phenomenon does NOT just apply to browsers, it's just more aptly demonstrated with browsers. NOBODY wants a browser that doesn't accept valid HTML. They never did and they never will.
And what's different about web pages to any other kind of XML? There's more of them, that's all, and people want ALL of them to work. Permissiveness in the consumers is inevitable with ANY kind of XML document that becomes popular for exactly the same reason as it is with browsers.
>that's not because of history of HTML and IE/Netscape/whatever that you need to change your mind about XML.
Yes it is because this sort-of-invalid-but-not-quite problem is a unique one to XML. JSON doesn't have it.
>So if a web service was to accept a specific type of XML, it would certainly need to be made valid
If you don't think somebody would throw invalid XML at your app and not expect it to work then you've clearly never worked with XML seriously.
If you think you can just tell the customer to go fuck themselves because the XML they got from another service doesn't validate, see my previous point.
>if a client does not conform why the fuck do you want your service to be permissive? Seriously.
Because it will make your service work where an impermissive one won't, and when your service works and competitors don't, that's called gaining marketshare.
Seriously.
>You can make a service that accepts the resume schema directly, or embed it in a CDATA if you want to.
Or you could just use JSON or YAML.
>Talking about apple and oranges. XML and docbook are not the same.
docbook IS XML.
I am not mistaking, I am comparing.
>An application that parses XML for book rendering, or whatever the hell the purpose of the application is, will fail on invalid input
Which will be treated as a bug if other applications DON'T fail (which some undoubtedly will).
>That is NORMAL, and you would do the same with JSON
In my experience the OPPOSITE is normal. If XML is invalid but still makes sense, you treat it as valid, because if you don't, your competitors will.
If the customer is getting XML from output X and feeding into your app, he doesn't care that output X is outputting invalid XML if your competitors' apps accept it. He'll just treat your app as the broken one, not buy it and move on with his life and you've just lost a sale. I've seen it happen MANY times. This phenomenon does NOT just apply to browsers, it's just more aptly demonstrated with browsers. NOBODY wants a browser that doesn't accept valid HTML. They never did and they never will.
And what's different about web pages to any other kind of XML? There's more of them, that's all, and people want ALL of them to work. Permissiveness in the consumers is inevitable with ANY kind of XML document that becomes popular for exactly the same reason as it is with browsers.
>that's not because of history of HTML and IE/Netscape/whatever that you need to change your mind about XML.
Yes it is because this sort-of-invalid-but-not-quite problem is a unique one to XML. JSON doesn't have it.
>So if a web service was to accept a specific type of XML, it would certainly need to be made valid
If you don't think somebody would throw invalid XML at your app and not expect it to work then you've clearly never worked with XML seriously.
If you think you can just tell the customer to go fuck themselves because the XML they got from another service doesn't validate, see my previous point.
>if a client does not conform why the fuck do you want your service to be permissive? Seriously.
Because it will make your service work where an impermissive one won't, and when your service works and competitors don't, that's called gaining marketshare.
Seriously.
>You can make a service that accepts the resume schema directly, or embed it in a CDATA if you want to.
Or you could just use JSON or YAML.
>Talking about apple and oranges. XML and docbook are not the same.
docbook IS XML.
> I am not mistaking, I am comparing.
Yes apples and oranges. They taste different, because they are.
> In my experience the OPPOSITE is normal. If XML is invalid but still makes sense, you treat it as valid, because if you don't, your competitors will.
If this is a business requirement you would do the same for JSON.
> If you don't think somebody would throw invalid XML at your app and not expect it to work then you've clearly never worked with XML seriously.
Nope, if you have a customer sending you an XML which should validate against a predefined schema, no, hell no. I've worked for the European office of publications, and the web services were just receiving tons of XML on a daily basis. And you know what, invalid XML were rejected that's as simple as that. If you don't respect the supplied schema, retry when correct.
> docbook IS XML.
Docbook USES XML.
Last but not least, HTML is not XML, HTML is not a subset of XML. Permissiveness has nothing to do with web services acceptance of invalid schemas.
If you call a Google service whether it uses SOAP (so XML) or REST, if the request body is invalid, you'll be rejected either way. The SOAP one won't try to parse more or resolve issues just because it is XML based.
Yes apples and oranges. They taste different, because they are.
> In my experience the OPPOSITE is normal. If XML is invalid but still makes sense, you treat it as valid, because if you don't, your competitors will.
If this is a business requirement you would do the same for JSON.
> If you don't think somebody would throw invalid XML at your app and not expect it to work then you've clearly never worked with XML seriously.
Nope, if you have a customer sending you an XML which should validate against a predefined schema, no, hell no. I've worked for the European office of publications, and the web services were just receiving tons of XML on a daily basis. And you know what, invalid XML were rejected that's as simple as that. If you don't respect the supplied schema, retry when correct.
> docbook IS XML.
Docbook USES XML.
Last but not least, HTML is not XML, HTML is not a subset of XML. Permissiveness has nothing to do with web services acceptance of invalid schemas.
If you call a Google service whether it uses SOAP (so XML) or REST, if the request body is invalid, you'll be rejected either way. The SOAP one won't try to parse more or resolve issues just because it is XML based.
> I am not mistaking, I am comparing.
Yes, you are mistaking it. HTML is "relaxed" about various parsing errors. XML absolutely is not. If the input document so much as has a closing tag missing, parsing will fail, end of story. If it doesn't match your schema, parsing will fail, end of story. I'm not sure why you keep going on about this point. You're woefully misinformed if you think XML parsers accept malformed input.
> Which will be treated as a bug if other applications DON'T fail (which some undoubtedly will).
Are you talking about "my app accepts schema A and another app accepts schema A.1, therefore if I don't accept schema A.1 people will think my app sucks"? I'm not sure why you think this is an XML-specific issue.
Yes, you are mistaking it. HTML is "relaxed" about various parsing errors. XML absolutely is not. If the input document so much as has a closing tag missing, parsing will fail, end of story. If it doesn't match your schema, parsing will fail, end of story. I'm not sure why you keep going on about this point. You're woefully misinformed if you think XML parsers accept malformed input.
> Which will be treated as a bug if other applications DON'T fail (which some undoubtedly will).
Are you talking about "my app accepts schema A and another app accepts schema A.1, therefore if I don't accept schema A.1 people will think my app sucks"? I'm not sure why you think this is an XML-specific issue.
I have to agree here. XSLT failed when they added <xsl:if>. Get your flow control out of my document format. That's what code is for. Adding <xsl:if> makes it code, horrible, horrible code.
> XSLT failed when they added <xsl:if>. Get your flow control out of my document format. That's what code is for.
XSLT isn't a document format, its by design a domain-specific programming language designed for use in transforming XML documents to other formats.
> Adding <xsl:if> makes it code, horrible, horrible code.
Its supposed to be code. Now, if you want to argue that its horrible code, that's another issue, but complaining that XSLT is code when that's the whole point of XSLT is, well, missing the point.
XSLT isn't a document format, its by design a domain-specific programming language designed for use in transforming XML documents to other formats.
> Adding <xsl:if> makes it code, horrible, horrible code.
Its supposed to be code. Now, if you want to argue that its horrible code, that's another issue, but complaining that XSLT is code when that's the whole point of XSLT is, well, missing the point.
Oh, I don't know, it's kinda handy when you need it. How often have you wished for that in CSS?
I know it's a little heavy weight, but there is already an open standard around this: http://www.hropenstandards.org/
They have a HR-JSON and HR-XML schema for HR docs..
Reinventing?
They have a HR-JSON and HR-XML schema for HR docs..
Reinventing?
It appears you have to register for an account on that site AND wait for your membership to be approved before you can even download a standard or view documentation.
If that standard is important and well designed, it should be trivial to write a converter from JSON Resume.
As Douglas Crockford once said (I believe in reference to XMLRPC) the great thing about reinventing the wheel is that you might get a round one.
If that standard is important and well designed, it should be trivial to write a converter from JSON Resume.
As Douglas Crockford once said (I believe in reference to XMLRPC) the great thing about reinventing the wheel is that you might get a round one.
You can download without being a member. There is a Download Standards page that anyone can download from. It's pretty straightforward.
(on the HR Open Standards Board of Directors)
(on the HR Open Standards Board of Directors)
Yep. I'm sure the fantastic exhibition of its fatal flaws will ensue. Maybe. Hopefully.
[deleted]
Just use HTML + hResume. hResume is based on vCard and thus the name and address fields are actually sensible rather than hacked together without considering edge cases. It lets you use prefixes and suffixes (like Dr, Prof, Rev, PhD, MD, JD etc.). It lets you format text using HTML tags. You can link to it.
If you want JSON, you can export it from the hResume using a parser.
Unlike JSON (or XML), non-programmers can read HTML in a crazy new piece of technology called a web browser without having to run it through any transformation tool. Want PDF to send to a company? There are a few WebKit PDF renderers available.
Want to style it? CSS.
Want nice fonts? WebFonts.
It's a web page. Crazy idea.
Classic version: http://www.microformats.org/wiki/hResume
New version: http://www.microformats.org/wiki/h-resume
If you want JSON, you can export it from the hResume using a parser.
Unlike JSON (or XML), non-programmers can read HTML in a crazy new piece of technology called a web browser without having to run it through any transformation tool. Want PDF to send to a company? There are a few WebKit PDF renderers available.
Want to style it? CSS.
Want nice fonts? WebFonts.
It's a web page. Crazy idea.
Classic version: http://www.microformats.org/wiki/hResume
New version: http://www.microformats.org/wiki/h-resume
Hey guys, we weren't actually ready for a lot of eyes to see this project. We were hoping to keep it small and get some feedback on important decisions about the project's trajectory.
The plan is to create a standard that developers worldwide are comfortable enough with to build upon.
To give the standard some traction, we have built tools to export to other formats such as pdf, txt and doc.
We also thought it would be cool and useful to have an NPM like system for resumes. So we built a CLI heavily inspired by NPM, to init and publish your resume to the jsonresume.org registry.
The themes right now are in bad shape, and we are looking for designers who would love to jump in during the early stages. We are thinking of building a theming version manager on top of NPM to take advantage of versions/distribution and also allow theme developers to implement their theming systems however they like (erb, mustache, md etc).
All the code is open source and available at -> http://github.com/jsonresume
Theme developers should be looking at the resumeToHTML repo -> http://github.com/jsonresume/resumeToHTML
People with comments about the standard semantics and structure are encouraged to post their ideas to Github issues. -> http://github.com/jsonresume/resume-schema We also want to formalize the standard a lot more over the coming weeks.
If the project can be pulled off professionally and driven by the community, we believe that working with resumes will be fun!
Edit: Here are some of the reasons why I personally think JSON resumes will improve HR.
(trying to figure out bullet points)
- Better searching and filtering than PDF/doc. Making recruiting a tad easier.
- Applying themes will be a lot easier.
- Applying for jobs will be easier. Instead of filling out complex forms over and over again services might start allowing you to auto-fill with your JSON resume.
- There are many services that ask for your career history such as LinkedIn, Angel.co etc. These could be autopopulated or synced with your master copy.
- You can update your resume programatically so Github projects can be inserted and any other online certificates that you might want automatically added to your resume like Mozilla Open Badges -> http://openbadges.org/
- The comment section suggests that lots of innovation could arise from it.
----------
Make sure you try the CLI! sudo npm install -g resume-cli
The plan is to create a standard that developers worldwide are comfortable enough with to build upon.
To give the standard some traction, we have built tools to export to other formats such as pdf, txt and doc.
We also thought it would be cool and useful to have an NPM like system for resumes. So we built a CLI heavily inspired by NPM, to init and publish your resume to the jsonresume.org registry.
The themes right now are in bad shape, and we are looking for designers who would love to jump in during the early stages. We are thinking of building a theming version manager on top of NPM to take advantage of versions/distribution and also allow theme developers to implement their theming systems however they like (erb, mustache, md etc).
All the code is open source and available at -> http://github.com/jsonresume
Theme developers should be looking at the resumeToHTML repo -> http://github.com/jsonresume/resumeToHTML
People with comments about the standard semantics and structure are encouraged to post their ideas to Github issues. -> http://github.com/jsonresume/resume-schema We also want to formalize the standard a lot more over the coming weeks.
If the project can be pulled off professionally and driven by the community, we believe that working with resumes will be fun!
Edit: Here are some of the reasons why I personally think JSON resumes will improve HR.
(trying to figure out bullet points)
- Better searching and filtering than PDF/doc. Making recruiting a tad easier.
- Applying themes will be a lot easier.
- Applying for jobs will be easier. Instead of filling out complex forms over and over again services might start allowing you to auto-fill with your JSON resume.
- There are many services that ask for your career history such as LinkedIn, Angel.co etc. These could be autopopulated or synced with your master copy.
- You can update your resume programatically so Github projects can be inserted and any other online certificates that you might want automatically added to your resume like Mozilla Open Badges -> http://openbadges.org/
- The comment section suggests that lots of innovation could arise from it.
----------
Make sure you try the CLI! sudo npm install -g resume-cli
I would just like to say that I think that this is a great idea(despite agreeing with others here that XML + XSLT would seem like a more logical choice). I hope it gets some traction in the long run.
I've posted an issue on github [0][1] mentioning that "firstName" and "lastName" is probably not a good representation of names. I don't actually know what the solution is, but this article [2] gives some great reasons why we tend to make incorrect assumptions about peoples names, which have the possibility of excluding some people form our tools based on their name alone.
[0] - https://github.com/jsonresume/resume-schema/issues/4 [1] - It seemed like an appropriate place to comment. Please let me know if there is somewhere else you'd prefer such comments. [2] - http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...
I've posted an issue on github [0][1] mentioning that "firstName" and "lastName" is probably not a good representation of names. I don't actually know what the solution is, but this article [2] gives some great reasons why we tend to make incorrect assumptions about peoples names, which have the possibility of excluding some people form our tools based on their name alone.
[0] - https://github.com/jsonresume/resume-schema/issues/4 [1] - It seemed like an appropriate place to comment. Please let me know if there is somewhere else you'd prefer such comments. [2] - http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...
Regarding names, I've heard of two solutions that cover enough edge cases to be suitable:
1. Asking for "Given Name" and "Surname" clears up most issues with cultures like Korea (where surname comes first).
2. Simply have a "Name" field. Accept any Unicode characters. Hope for the best.
If someone has a name that cannot be represented in written characters or cannot be rendered in Unicode (which would be amazing, since Unicode covers ancient dead languages and fictional languages like Klingon) they probably have more pressing issues than trying to serialize their resume.
1. Asking for "Given Name" and "Surname" clears up most issues with cultures like Korea (where surname comes first).
2. Simply have a "Name" field. Accept any Unicode characters. Hope for the best.
If someone has a name that cannot be represented in written characters or cannot be rendered in Unicode (which would be amazing, since Unicode covers ancient dead languages and fictional languages like Klingon) they probably have more pressing issues than trying to serialize their resume.
Mostly, people ask for firstname and lastname because they want to call you by one of them. you can avoid this problems by having a "Full name" and a "what do we call you": my full name is "Paul Biggar" but you should call me "Paul".
This solves some of the falsehoods programmers believe about names: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...
This solves some of the falsehoods programmers believe about names: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...
Still not the silver bullet.
In Germany it's not really common to call people by their first name (IT is an exception), but I would hardly put "Mr. Lastname" into "what do we call you". It all depends on the context, even in the limited scope of a resume.
In Germany it's not really common to call people by their first name (IT is an exception), but I would hardly put "Mr. Lastname" into "what do we call you". It all depends on the context, even in the limited scope of a resume.
If they're just looking for something to say on the other end of the phone when you answer, isn't "Mr. Lastname" the appropriate thing to enter in that box?
No, it's not, because calling someones phone is also culturally dependent. Because in Germany, when you are calling someone, it is expected that person picking up the call will speak up first and introduce themself. Something like: "Herr Mustermann, hallo!".
You see, if you are calling person from Germany, knowing how to address him is not enough, you shall still know how to make a call. If you don't know that, you'll be rude anyways, and if you know that, you'll also know a proper way of addressing persons in different cultures.
You see, if you are calling person from Germany, knowing how to address him is not enough, you shall still know how to make a call. If you don't know that, you'll be rude anyways, and if you know that, you'll also know a proper way of addressing persons in different cultures.
"When a recruiter or employer contacts you, how would you like to be addressed?"
Is there really any further scope that should be covered? If there are specific cultural issues, shouldn't that be hammered out later?
Really, the design question for JSON Resume is "For what purpose is a name being provided?"
Is there really any further scope that should be covered? If there are specific cultural issues, shouldn't that be hammered out later?
Really, the design question for JSON Resume is "For what purpose is a name being provided?"
[deleted]
Here's another good reference on international names and ways to deal with names - http://www.w3.org/International/questions/qa-personal-names
I agree with the names. Even just the ordering of first/last name can be difficult. I come from Korea where last name always comes before the first name in a formal setting.
Perhaps you should just require "full name" which the author of the resume would decide for him or herself.
Perhaps you should just require "full name" which the author of the resume would decide for him or herself.
Facebook takes a "family name" and a "given name", and asks you which order to display them, right?
Facebook also supports middle names too, though.
or, have both fields, which the author needs to fill in. This makes it easy to parse the data, but also makes it readable by humans, by separating it into different fields, for different purposes.
> Make sure you try the CLI! sudo npm install -g resume-cli
Regarding that: I recently reached the fed-up point with sudo or not sudo to install nodejs app and the mess it leaves behind when using sudo for just installing some local binaries.
I stumbled upon nvm[0] when installing docpad:
> The above should not require sudo (the # means sudo). If it does, we recommend reinstalling Node.js so that it doesn't. Otherwise you're likely to run into permission problems in the future. Follow the Step 1 instructions to reinstall Node.js without requiring sudo.[1]
Which led me to this:
> http://learn.bevry.me/node/install
and then this:
> https://github.com/creationix/nvm
It makes npm installs everything under $HOME and never needs to be ran with escalated privileges. `nvm install X.X` and `nvm use X.X` allows switching between node versions and installed packages.
[0] https://github.com/creationix/nvm
[1] http://docpad.org/docs/install
Regarding that: I recently reached the fed-up point with sudo or not sudo to install nodejs app and the mess it leaves behind when using sudo for just installing some local binaries.
I stumbled upon nvm[0] when installing docpad:
> The above should not require sudo (the # means sudo). If it does, we recommend reinstalling Node.js so that it doesn't. Otherwise you're likely to run into permission problems in the future. Follow the Step 1 instructions to reinstall Node.js without requiring sudo.[1]
Which led me to this:
> http://learn.bevry.me/node/install
and then this:
> https://github.com/creationix/nvm
It makes npm installs everything under $HOME and never needs to be ran with escalated privileges. `nvm install X.X` and `nvm use X.X` allows switching between node versions and installed packages.
[0] https://github.com/creationix/nvm
[1] http://docpad.org/docs/install
I built something similar a couple of years back when I was job hunting using a json and Angular.js, I called it modern resume [1]. Live example can be found here [2]. I got tired of having a resume for each format - plain text, html (website), word document, PDF. Every change had to be made in all the places. I wanted to have a single source of truth. This kind of standardization would be great!
My resume.json for science [3]
[1] https://github.com/dhawalhshah/modern-resume [2] http://dhawal.me/ [3] http://dhawal.me/js/resume.json
My resume.json for science [3]
[1] https://github.com/dhawalhshah/modern-resume [2] http://dhawal.me/ [3] http://dhawal.me/js/resume.json
While we're showing our own resume formats, here's my own, half-YAML half-Markdown base: https://github.com/stuartpb/stuartpb.com/blob/master/routes/...
Heyo another Tech alum :o) ... in good company
I am very interested into your thoughts about LateX, why we need another "standard" if we have LateX? Do you provide something in addition which is not possible with LateX?
Thanks
Thanks
I've been working on a LaTeX-based resume builder (link in profile) and I could see something like this being useful for allowing users to take their data with them and move it between services. Anything that reduces the time it takes for people to input information and see the resulting image/pdf is worth looking into, so I'll be checking this out.
but is LaTeX machine readable - can i be given a latex document, and extract the essential data from it and transform it into some other format/structure that i can use elsewhere?
I think we might be conflating 'machine-readable' and 'well-formed/structured' here...
What they're proposing is structure, not machine readability... Technically, with the state of OCR and other methods, many things like LaTeX, PDFs, .DOCs, etc are all perfectly machine readable -- the problem is getting the information out in a meaningful way.... that's usually done by standardizing on structure.
When it comes to specifying structure, XML and JSON are pretty much the front-runners (at least I think so), and since XML isn't so popular lately (since it's so verbose), JSON is in the spotlight now
What they're proposing is structure, not machine readability... Technically, with the state of OCR and other methods, many things like LaTeX, PDFs, .DOCs, etc are all perfectly machine readable -- the problem is getting the information out in a meaningful way.... that's usually done by standardizing on structure.
When it comes to specifying structure, XML and JSON are pretty much the front-runners (at least I think so), and since XML isn't so popular lately (since it's so verbose), JSON is in the spotlight now
To be fair, they're proposing a structure that lends itself to machine readability.
"Technically, with the state of OCR and other methods, many things like LaTeX, PDFs, .DOCs, etc are all perfectly machine readable"
Uh, no. What does OCR even have to do with the 'machine readability' (for your strange definition of it) of the formats you mention?
Uh, no. What does OCR even have to do with the 'machine readability' (for your strange definition of it) of the formats you mention?
Machine readability, unless I and the dictionary are mistaken, is related to whether or not you can input the data from some physical medium into a computer. It's not the same as asking whether something you read in makes sense, or is easy to parse, or is well-structured, which is what their idea is related to.
Other than the fact that most of the things I noted are ALREADY in a state that is computer usable (whether it makes sense to humans looking at computers is another question), I was trying to point out that getting the information into a computer (A.K.A. Machine readability) is not the issue we're struggling with now, it's structuring, characterizing and understanding the information.
I mentioned OCR because it's used to parse resumes to find important bits when other methods fail (or someone submits something crazy like a scanned version of their resume instead of the file) -- something that wouldn't be necessary if there was a standard (like is being proposed) to adhere to, that people could semantically find what they wanted from.
Also, if you read closely, I said with the state of OCR AND OTHER METHODS... OCR does not have anything to do with the machine readability of other methods, it's just one method people use to extract data, or for machines to "read" the document.
Other than the fact that most of the things I noted are ALREADY in a state that is computer usable (whether it makes sense to humans looking at computers is another question), I was trying to point out that getting the information into a computer (A.K.A. Machine readability) is not the issue we're struggling with now, it's structuring, characterizing and understanding the information.
I mentioned OCR because it's used to parse resumes to find important bits when other methods fail (or someone submits something crazy like a scanned version of their resume instead of the file) -- something that wouldn't be necessary if there was a standard (like is being proposed) to adhere to, that people could semantically find what they wanted from.
Also, if you read closely, I said with the state of OCR AND OTHER METHODS... OCR does not have anything to do with the machine readability of other methods, it's just one method people use to extract data, or for machines to "read" the document.
Haha +1 to this. By that logic my ass is machine readable if I take a digital photo of it.
It depends on the machine, if you're feeding your picture to a machine with image recognition capabilities, it might just be able to tell that it's your ass. Some pretty big companies are working on just that. (not on figuring out if it's your ass, but image recognition in the general sense)
The big picture is to make as many things as possible "machine readable" (things more difficult than resumes), and use machines to work faster than humans ever could.
The big picture is to make as many things as possible "machine readable" (things more difficult than resumes), and use machines to work faster than humans ever could.
Yes you can
Your References fields need a section for contact details - email or phone. Testimonials are worthless by themselves.
Edit: references should also have an optional 'organisation' field and a 'position title' field. "This reference was the technical lead at Foo Corp, my second-last job. Contactable here"
Edit: references should also have an optional 'organisation' field and a 'position title' field. "This reference was the technical lead at Foo Corp, my second-last job. Contactable here"
You could use the "correct" spelling of the word: Résumé.
It took me ages to figure out what this actually was, because your non-standard "lazy" spelling made me think this was about resuming interrupted downloads/transfers of generic JSON data. (Possibly by doing a partial parse of the data that you have got, or over a non-HTTP protocol, otherwise why not just use HTTP "Range:" headers?) I had to unlearn that before the light-bulb went off.
It took me ages to figure out what this actually was, because your non-standard "lazy" spelling made me think this was about resuming interrupted downloads/transfers of generic JSON data. (Possibly by doing a partial parse of the data that you have got, or over a non-HTTP protocol, otherwise why not just use HTTP "Range:" headers?) I had to unlearn that before the light-bulb went off.
At least in the UK - and probably other countries in the Commonwealth - we almost exclusively say "CV" ("curriculum vitae", literally "course of [my] life"). "Résumé" is not well-understood here.
I'm also from the UK, and although I'm part of the "we" who normally use the term CV, due to the incredible pervasiveness of USA culture, I (and probably most of the people I know) am perfectly aware of what a résumé is. I just never expected to see it spelled "resume".
I mean, résumé and resume have the same French root, but in English - even American English as far as I can tell - they're totally different words! Even the pronounciation is completely different. So why would someone spell résumé as resume, especially in the name/title of a project about them?
How is that going to do anything except cause confusion?
I mean, résumé and resume have the same French root, but in English - even American English as far as I can tell - they're totally different words! Even the pronounciation is completely different. So why would someone spell résumé as resume, especially in the name/title of a project about them?
How is that going to do anything except cause confusion?
Non-English loanwords enter the English language by a process of naturalization, [...] there is a tendency for accents and other diacritics that were present in the donor language to be dropped [1].
We have words with the same spelling but different meanings and pronunciations all the time - so called Heteronyms [2]. Doesn't seem that confusing to me. To me it'd be pretty weird if people who understood the word rôle were baffled by the word role.
[1] http://en.wikipedia.org/wiki/English_terms_with_diacritical_... [2] http://en.wikipedia.org/wiki/Heteronym_(linguistics)
We have words with the same spelling but different meanings and pronunciations all the time - so called Heteronyms [2]. Doesn't seem that confusing to me. To me it'd be pretty weird if people who understood the word rôle were baffled by the word role.
[1] http://en.wikipedia.org/wiki/English_terms_with_diacritical_... [2] http://en.wikipedia.org/wiki/Heteronym_(linguistics)
"Doesn't seem that confusing to me."
Really? I've always thought of heteronyms as one of the most stand-out features of English that exemplify its confusing inconsistency. More so than the homophones, because it's harder to think of the "other" meanings if you've got the wrong pronunciation in your head.
In reference to the passage you quoted about diacritics, if only you had read as far as the next-but-one paragraph, you might have noticed: "Words that retain their accents often do so to help indicate pronunciation (e.g. frappé, naïve, soufflé), or to help distinguish them from an unaccented English word (e.g. exposé, résumé, rosé)."
Really? I've always thought of heteronyms as one of the most stand-out features of English that exemplify its confusing inconsistency. More so than the homophones, because it's harder to think of the "other" meanings if you've got the wrong pronunciation in your head.
In reference to the passage you quoted about diacritics, if only you had read as far as the next-but-one paragraph, you might have noticed: "Words that retain their accents often do so to help indicate pronunciation (e.g. frappé, naïve, soufflé), or to help distinguish them from an unaccented English word (e.g. exposé, résumé, rosé)."
Even us French use C.V., not résumé...
Résumé, resume, and resumé are all accepted spellings in American English. As noted by others, many countries use the term C.V., which is likely to be a larger source of confusion for people.
Part of this is likely that many Americans do not have an easy way to type the accented 'e' character. (Short of copy/paste, I'm not even sure how I'd do it. Friends who have Macs have it easy.)
There's also the (lower these days, thankfully) risk of half-baked tools other people use proudly presenting your résumé.
I have to admit, I'm having some trouble seeing the value in this... JSON does not strike me as a great format for a document of this nature, although it's certainly possible. Offhand, I'd think XML is a more natural fit for this.
Anyway, more to the point, there has been some existing work done on developing standards for representing resumes. I would highly, highly encourage you guys to look at this and consider making whatever you do compatible with the existing work as much as possible. Consider ResumeRDF[1] for example. Maybe consider doing JSON-LD and using the FOAF and ResumeRDF vocabularies?
[1]: http://rdfs.org/resume-rdf/
Anyway, more to the point, there has been some existing work done on developing standards for representing resumes. I would highly, highly encourage you guys to look at this and consider making whatever you do compatible with the existing work as much as possible. Consider ResumeRDF[1] for example. Maybe consider doing JSON-LD and using the FOAF and ResumeRDF vocabularies?
[1]: http://rdfs.org/resume-rdf/
I just had a look at ResumeRDF.
Class: cv:Person
Person - CV subclass of WordNet person
in-range-of: cv:aboutPerson cv:referenceBy
in-domain-of: cv:gender cv:birthPlace cv:hasCitizenship cv:hasNationality cv:maritalStatus cv:noOfChildren cv:hasDriversLicense
[back to top]
That's an interesting point. And to be honest, I'm not sure what the rationale was for including those terms (I wasn't involved with defining ResumeRDF or anything).
I'm guessing it happened because they "borrowed" a generic notion of "person attributes" from some other, less specific, source, and didn't really consider the legal implications you mention.
I guess it's an open question whether or not there's any actual valid scenario where somebody would want to put that stuff. It seems unlikely to me, but maybe in other countries or something? Hmmm... dunno.
I'm guessing it happened because they "borrowed" a generic notion of "person attributes" from some other, less specific, source, and didn't really consider the legal implications you mention.
I guess it's an open question whether or not there's any actual valid scenario where somebody would want to put that stuff. It seems unlikely to me, but maybe in other countries or something? Hmmm... dunno.
In Europe, at least in Germany and Switzerland, it's normal and expected to state your birthday and place of birth. You also include a passport-sized photo of yourself, usually in the top right corner.
See for example this guide to resume writing by a German university [pdf]: https://www.uni-muenster.de/imperia/md/content/math_nat_faku...
See for example this guide to resume writing by a German university [pdf]: https://www.uni-muenster.de/imperia/md/content/math_nat_faku...
Aah, OK. That's pretty interesting, actually. Here in the US it's practically verboten to ask anything about nationality, religion, ethnicity, etc., and conversely pretty much nobody ever volunteers that stuff either.
In some countries this completely legal, and if it wants to be an international standard it should have space for it. (I hope there would be standard filters for each legal area e.g. filter out all protected characteristics for US applications)
This is exactly where XML is the only right choice. JSON is much simpler than XML, thats why lots of people like it. However for documents XML markup is more appropriate. The reasons:
- Allows extensibility with other xml standards (such as SVG and MathML in your resume, which might makes sense) - Allows linking to other stuff with XLink - Allows styling it with lots of xml styling technologies. - Better versioning support
JSON is not bad however, so if you just want to have simple plaint text cv's, json is good enough. I do agree that with XML comes bloatness, complexity, and more crap. However from a pure technical point of view, its a better option for doing resumes.
- Allows extensibility with other xml standards (such as SVG and MathML in your resume, which might makes sense) - Allows linking to other stuff with XLink - Allows styling it with lots of xml styling technologies. - Better versioning support
JSON is not bad however, so if you just want to have simple plaint text cv's, json is good enough. I do agree that with XML comes bloatness, complexity, and more crap. However from a pure technical point of view, its a better option for doing resumes.
I have a resume I've been working with for a few years now, and it was built using:
http://xmlresume.sourceforge.net/
That project seems dead now, and recent updates to my systems have resulted in me being able to build HTMLTXT but not PDF.
In the future, when looking for a job, I'll be looking at JSON instead. It might not be the best tool, but it seems to be what several _live_ and active projects are using.
http://xmlresume.sourceforge.net/
That project seems dead now, and recent updates to my systems have resulted in me being able to build HTMLTXT but not PDF.
In the future, when looking for a job, I'll be looking at JSON instead. It might not be the best tool, but it seems to be what several _live_ and active projects are using.
I looked over the website briefly, and I couldn't find an answer to this question so I'm going to ask here. I am not asking this tongue-in-cheek, these are serious questions:
* By "open source standard," what do they mean? I don't see any evidence they're on an RFC track, so this would be "standard" in what way?
* Why? I've never needed a resume in JSON format, but that is anecdotal. They don't really say why they're pursuing this on the site, except why they chose JSON.
Good luck, either way! Making something isn't easy, so I applaud any effort to do anything.
* By "open source standard," what do they mean? I don't see any evidence they're on an RFC track, so this would be "standard" in what way?
* Why? I've never needed a resume in JSON format, but that is anecdotal. They don't really say why they're pursuing this on the site, except why they chose JSON.
Good luck, either way! Making something isn't easy, so I applaud any effort to do anything.
Assuming this takes off and everyone uses it (you be the judge of those odds), I can see a standard format being really useful for both employers and job board websites.
Let's say you had a bank of resumes -- you could easily find all resumes that know Java and have had at least 2 jobs and an active GitHub repo, and automatically send out a request to their references.
Currently, you have to read an unformatted PDF and extract the info manually -- it's not the end of the world, but it gets tedious if you're dealing with lots of resumes.
Let's say you had a bank of resumes -- you could easily find all resumes that know Java and have had at least 2 jobs and an active GitHub repo, and automatically send out a request to their references.
Currently, you have to read an unformatted PDF and extract the info manually -- it's not the end of the world, but it gets tedious if you're dealing with lots of resumes.
It would be really useful for the people making the resume also. Right now the current mainstream advice is to use Microsoft Word for creation and editing and then (typically) to submit as PDF. Both of those document standards are proprietary and opaque. If you two computers that don't have the same operating system, you're probably SOL for tweaking your resumes across computers as well.
> you could easily find all resumes that know Java
Except that you're going to have people who put "J2EE" or "J2ME" or "JavaFX" or whatever else people like to specialize in instead of plain "Java".
Except that you're going to have people who put "J2EE" or "J2ME" or "JavaFX" or whatever else people like to specialize in instead of plain "Java".
You are right, I am still researching how to manage a standard formally hence why the site wasn't meant to go on HN just yet. If you have any good advice or links to advice for writing and managing standards that would be fantastic.
For example, what is an "RFC track"? I was also hoping that Github Issues might be able to replace the mailing list style of managing standards, what do you think?
For example, what is an "RFC track"? I was also hoping that Github Issues might be able to replace the mailing list style of managing standards, what do you think?
I assume they're talking about the Iternet Standards Process[0] where documents are published as IETF RFCs.
[0] http://tools.ietf.org/html/bcp9
[0] http://tools.ietf.org/html/bcp9
This is a neat idea but this schema is a bit...specific in areas. Much like XML schemas of past the great thing about the JSON interchange format is that it's insanely flexible and anything goes (essentially).
I feel like it would be a much better way of handling resume type data if it was self describing rather than using a very specific schema that ties you into a data structure that may not make sense in many cases. In that case you could simply look for different types of data to display versus a very specific format that won't hold up to every use case.
I feel like it would be a much better way of handling resume type data if it was self describing rather than using a very specific schema that ties you into a data structure that may not make sense in many cases. In that case you could simply look for different types of data to display versus a very specific format that won't hold up to every use case.
My main concern and same question for my own resume: what skill strings should be used ? Server Administrator or System Engineer ? Programmer or C++ ? etc... That's what will be one of the more challenging things to solve. Otherwise you might have a resume-format, but no way to reliably use that data as a computer, or that out of scope ?
This is why the Semantic Web has links (URIs), so that we point to unequivocal concepts. They would do much better to use JSON-LD instead of dumb strings for these CVs.
We are struggling with this part, as the other reply stated our strings are bad but they are also useful for lowering the barrier to entry, we are hoping to find a sweet spot in the middle somehow.
[deleted]
While I don't jump for opportunities to fiddle with a word processor to make a document like a resume look good, I am curious if this is partially driven by an effort to populate databases with information. While I have been unimpressed by efforts to do this by scanning a doc or pdf file, I am afraid of the possible implications for encouraging poor recruiting techniques. Having a searchable database can be nice, but there are so many other layers to finding good talent.
If you want this to take off, you really need to provide a mechanism for exporting it to a wide variety of large resume handlers (monster, various large employers, etc.) and importing (e.g. from linkedin).
Otherwise you have the xkcd problem: http://xkcd.com/927/
It's boring and tedious work, and the number of edge cases will multiply geometrically, but it's likely the only kind of thing that would make this take off.
P.S. Why not YAML?
Otherwise you have the xkcd problem: http://xkcd.com/927/
It's boring and tedious work, and the number of edge cases will multiply geometrically, but it's likely the only kind of thing that would make this take off.
P.S. Why not YAML?
We were nearly going to do a brand change because JSON and YAML are interchangeable and it doesn't really make any sense to just promote JSON in this case. I also love YAML, the problem was writing specification's seems a lot more mature when you follow the json-schema.org project. So I thought why not write it initially in JSON with the json-schema project as a basis and then just supply the tools for people who prefer YAML.
Ugh, json schema is horrible. Have you used orderly? It's far less verbose, more readable and it compiles to json schema.
I agree that making it interchangeable is best overall (especially since there is a 1:1 convertibility between the two languages).
Perhaps the brand should actually reflect this instead. JSON is preferable in a data interchange scenario, but for keeping or displaying a human readable version, YAML is better.
As before, though, it's not YAML/JSON - it's the richness of the import/export filters that will make this idea float or die. Nobody much is going to want this so that they can publish their resume on jsonresume.org. People will want to use it so they can efficiently and easily import their linkedin resume and upload it to [insert fortune 500] company's custom HR portal / top 7 job sites.
I agree that making it interchangeable is best overall (especially since there is a 1:1 convertibility between the two languages).
Perhaps the brand should actually reflect this instead. JSON is preferable in a data interchange scenario, but for keeping or displaying a human readable version, YAML is better.
As before, though, it's not YAML/JSON - it's the richness of the import/export filters that will make this idea float or die. Nobody much is going to want this so that they can publish their resume on jsonresume.org. People will want to use it so they can efficiently and easily import their linkedin resume and upload it to [insert fortune 500] company's custom HR portal / top 7 job sites.
[deleted]
Looks nice (and this is coming from someone who's pretty weary of the "hey let's put the whole world on npm" attitude). Seems to be a pretty decently-thought-out structure; after converting to YAML (my preference), it's pretty straightforward to work with.
Some comments:
- I found it a bit odd that 'resume init' only prompted for firstName and personal email; a more complete wizard would be useful. I suppose it wouldn't be hard to create a third-party "JSON resume generator" app with a nice friendly pretty interface for this (it is just JSON, after all).
- As mentioned in other comments, the "firstName" and "lastName" fields make excessive assumptions about the user's native/preferred naming convention.
- The schema only provides for a "blog" element in the "websites" array. More options would be appreciated, since not every personal website is a blog. Alternately (if the intent is really for only one website entry), providing a scalar/string "website" element would be more to-the-point.
- As someone who prefers YAML (it looks so much nicer), built-in support for YAML<->JSON conversion would be awesome for me (i.e. be able to export to / import from YAML). For now I'm fine with using yaml2json/json2yaml, but such import/export functionality would be awesome. Perhaps a command-line switch for exporting (i.e. "resume init --yaml")? Alternately...
- On the above note, would it be possible to make "resume init" output to STDOUT instead of directly to a file? That way, it would be simple to run "resume init | json2yaml > resume.yaml" (for example).
Some comments:
- I found it a bit odd that 'resume init' only prompted for firstName and personal email; a more complete wizard would be useful. I suppose it wouldn't be hard to create a third-party "JSON resume generator" app with a nice friendly pretty interface for this (it is just JSON, after all).
- As mentioned in other comments, the "firstName" and "lastName" fields make excessive assumptions about the user's native/preferred naming convention.
- The schema only provides for a "blog" element in the "websites" array. More options would be appreciated, since not every personal website is a blog. Alternately (if the intent is really for only one website entry), providing a scalar/string "website" element would be more to-the-point.
- As someone who prefers YAML (it looks so much nicer), built-in support for YAML<->JSON conversion would be awesome for me (i.e. be able to export to / import from YAML). For now I'm fine with using yaml2json/json2yaml, but such import/export functionality would be awesome. Perhaps a command-line switch for exporting (i.e. "resume init --yaml")? Alternately...
- On the above note, would it be possible to make "resume init" output to STDOUT instead of directly to a file? That way, it would be simple to run "resume init | json2yaml > resume.yaml" (for example).
Thank you! We are inundated with work right now so I can't reply fully but I will probably end up using the YAML version myself so I've created an issue to implement YAML into the CLI -> https://github.com/jsonresume/resume-cli/issues/20
Will add your other feedback to the issue tracker soon.
Will add your other feedback to the issue tracker soon.
Some things that I think would be useful to add to the schema, in no particular order:
* It's common for resumes to include a full address, so elements supporting that could be added to the location. There should probably be a way to strip this out before publishing it to a public place though.
* I'd like to see a section for volunteer activities. I do some volunteering which, while not related to my day job, is worth highlighting.
* The references section would usually include contact information for a potential employer. Generally this would be a separate page that would be given during an interview. My main resume says "References available upon request" and I have a separate document with my references in it.
The biggest win, in my mind, is that the schema captures the knowledge of what belongs on a resume. Being able to take that single source and produce multiple versions (e.g., the public one, the private one with full details, a list of references, etc), not to mention everything else that comes with a standard schema, is a huge bonus.
* It's common for resumes to include a full address, so elements supporting that could be added to the location. There should probably be a way to strip this out before publishing it to a public place though.
* I'd like to see a section for volunteer activities. I do some volunteering which, while not related to my day job, is worth highlighting.
* The references section would usually include contact information for a potential employer. Generally this would be a separate page that would be given during an interview. My main resume says "References available upon request" and I have a separate document with my references in it.
The biggest win, in my mind, is that the schema captures the knowledge of what belongs on a resume. Being able to take that single source and produce multiple versions (e.g., the public one, the private one with full details, a list of references, etc), not to mention everything else that comes with a standard schema, is a huge bonus.
Great ideas! I will start add them as issues to the schema repo -> https://github.com/jsonresume/resume-schema
Your meta-layer idea is great too, at the moment we only have password protected resumes.
We are actually building an encryption converter, so you can encrypt your resume with a passphrase, I imagine these public,private etc versions could be controlled by encryption.
Your meta-layer idea is great too, at the moment we only have password protected resumes.
We are actually building an encryption converter, so you can encrypt your resume with a passphrase, I imagine these public,private etc versions could be controlled by encryption.
In other words, Microformats have arrived in the Web 3.0 sphere. (hResume never really caught on either, despite LinkedIn supporting it.)
As someone from a country with very different resumes, my suggestion would be to be more explicit about this being about US style resumes. If you want decent rendering, you need to focus on one style anyway (too much variation), so just be open about your scope and optimise the hell out of it, saving you a lot of i18n worries (names, addresses etc.).
I have earlier written a similar json resume conversion gem - http://prat0318.github.io/json_resume I am currently working on i18n and a real time conversion web app. I would love to have something standardized and i hope it gets an active community.
I write software that interacts with CVs/Resumes for a living. Why would I use this over something based on HR-XML?
This reminds me a bit of an idea I messed around with a bit last year: http://erniemiller.org/me.json
I posted about it then (http://erniemiller.org/2013/06/19/my-happiness-formula-me-js..., but the thought at the time had been that it would be nice if prospective employees published something along the lines of things that contributed to their contentment with work.
This was eventually intended to be presented sans ratings in a little browser plugin, for recruiters and the like to score themselves honestly against the criteria, and a little bit of math would yield a compatibility rating on a click.
It wouldn't take long until such a thing evolved into a more full-featured resume such as this. I like the idea.
I posted about it then (http://erniemiller.org/2013/06/19/my-happiness-formula-me-js..., but the thought at the time had been that it would be nice if prospective employees published something along the lines of things that contributed to their contentment with work.
This was eventually intended to be presented sans ratings in a little browser plugin, for recruiters and the like to score themselves honestly against the criteria, and a little bit of math would yield a compatibility rating on a click.
It wouldn't take long until such a thing evolved into a more full-featured resume such as this. I like the idea.
Doesn't it ever dawn on anyone that employers insist on detailed, accurate information about applicants, in standardized forms, while the information available about employers is a mess? There's no standard, there's no requirement, and they can mislead in quite creative ways. Hardly seems fair.
http://www.glassdoor.com/ is a good start.
I've been thinking about exporting my resume to a similar format (hResume or equivalent) for a while; I find LinkedIn of little value for me.
I can imagine that for certain people it offers opportunities to "network", but in my case it is more an invitation for random people to spam me than a tool to connect.
Beyond the resume, I am wondering if it would be possible to build some kind of decentralized professional network, with resumes as nodes and professional/academic relationships in between, maybe even a vetting system (LinkedIn recommendations are not only time consuming but also worthless IMHO).
I can imagine that for certain people it offers opportunities to "network", but in my case it is more an invitation for random people to spam me than a tool to connect.
Beyond the resume, I am wondering if it would be possible to build some kind of decentralized professional network, with resumes as nodes and professional/academic relationships in between, maybe even a vetting system (LinkedIn recommendations are not only time consuming but also worthless IMHO).
Random Project Idea - use this as part of an API which scrapes multiple sites (like Linkedin, Github, Monster, what have you) and builds a single, canonical resume from the various sources using this standard.
I don't know that the themes, necessarily, are that useful (I don't like the idea of implicitly connecting presentation with JSON like that - i'll make my own themes thank you) but I do like the idea of a common transport format for resumes.
I don't know that the themes, necessarily, are that useful (I don't like the idea of implicitly connecting presentation with JSON like that - i'll make my own themes thank you) but I do like the idea of a common transport format for resumes.
That sounds very ideal, I'd love to automatically insert my online achievements into my resume.
[deleted]
Another possible section to add: speaking engagements (or public appearances or perhaps the more generic "public events").
You have publications, but that implies written material is produced. And should publications have a place for co-authors? It seems wrong to not acknowledge them.
You have publications, but that implies written material is produced. And should publications have a place for co-authors? It seems wrong to not acknowledge them.
Just added this as an issue yesterday -> https://github.com/jsonresume/resume-schema/issues/3
Thanks!
Thanks!
I've been more partial to schema.org's JSON-LD patterns. I'm curious what key differences made you opt for one over the other.
I could see this as a natural expansion of http://schema.org/Person
I could see this as a natural expansion of http://schema.org/Person
I'm happy that there is no 'Career Objective' section. This website[1] is down now but I think the name convey the idea.
1. http://whatthefuckismycareerobjective.com/
1. http://whatthefuckismycareerobjective.com/
http://microformats.org/wiki/h-resume looks good as you can choose how you want to display the data as well as allowing parsing to JSON if you want
Would it make sense to mimic attributes present in LinkedIn's JSON structure? Most people already have a LinkedIn profile, and it would be easy to make a tool that exports LinkedIn profiles into you new open standard.
You are correct, LinkedIn uses a Microformat called hResume, in our templates, we will export to HTML with built in support for the Microformat.
We also want to build a feature into the command line tool that lets users sync their resume.json to LinkedIn.
We also want to build a feature into the command line tool that lets users sync their resume.json to LinkedIn.
There's already a W3C Ontology for Resumes: http://www.w3.org/wiki/ResumeRDFOntology
All you have to do is use the terms with JSON-LD.
All you have to do is use the terms with JSON-LD.
I just wrote my resume in markdown and export it to txt/html/doc/PDF with Pandoc: http://johnmacfarlane.net/pandoc
Very cool! I started something like this with a WordPress implementation a few years ago and never bothered to complete it, so cool to see somebody else with a similar idea and actually finished it!
In the education section, I'd like to see an option for GPA or degree class. Be aware that some countries do not provide a GPA (for example, the UK has these classes: 1st, 2:1, 2:2, 3rd).
Added as issue to the schema repo, thanks!
Need more formal ontological definition of the "skills" field, E.g. If you type "Django" the system should infer that you have fair amount of Python skills already.
Is it just me, or does it feel just a tiny bit ridiculous to see Twitter proposed as being on a CV? GitHub, sure, but Twitter? Shouldn't we just add our WoW accounts and maybe our old ICQ numbers too?
For people interested in standardized CV, by the way: http://europass.cedefop.europa.eu/en/documents/curriculum-vi...
This site details some stuff about working with Europass: http://interop.europass.cedefop.europa.eu/
I'm surprised they didn't go for interoperability with what's already out there.
For people interested in standardized CV, by the way: http://europass.cedefop.europa.eu/en/documents/curriculum-vi...
This site details some stuff about working with Europass: http://interop.europass.cedefop.europa.eu/
I'm surprised they didn't go for interoperability with what's already out there.
Created a JSON Resume LinkedIn exporter https://github.com/mblarsen/resume-linkedin
I could see validators and other resume-specific checks coming about because of this.
Checking that dates are logical, spell checks, checking for dead links, showing employment gaps and so on.
Checking that dates are logical, spell checks, checking for dead links, showing employment gaps and so on.
Great idea! Added as an issue to the resume-schema repo
Awesome idea. I could imagine a marketplace for resume themes that is based on this. Would be easy to switch between different designs to see consistent details.
Well done.
Well done.
Isn't the look of your resume one of your competitive advantages as job-seeker?
Sorry I really don't understand the use-case. Having an API is good for styling (as you say), or doing some soft of programmatic transformation to data. I am having trouble understanding the need to do either for a resume.
Maybe it would help as metadata for a search engine, but in that case I think a plain text search would be just as effective?
I think json schema is a really nice thing to have and I'd like to see more people adopt it, but I'm having trouble coming up with the point for this use.
Sorry I really don't understand the use-case. Having an API is good for styling (as you say), or doing some soft of programmatic transformation to data. I am having trouble understanding the need to do either for a resume.
Maybe it would help as metadata for a search engine, but in that case I think a plain text search would be just as effective?
I think json schema is a really nice thing to have and I'd like to see more people adopt it, but I'm having trouble coming up with the point for this use.
Came here to say this. I feel the same way — even about the schema. Having a poorly-organized or thought out resume should be an immediate signal to employers. This eliminates that.
Of course, this is not to imply that having a really well-done resume is really worth much either.
Of course, this is not to imply that having a really well-done resume is really worth much either.
This. This is it.
I've actually written my resume in markup for a while just so that I could put it on a nice dynamically driven site. Sort of a fun weekend project (no, it's not hosted anywhere).
While I strongly doubt that this will ever be a standard, I think it's nifty, and potentially useful. It opens up easy, pretty resumes, which the world really needs (Note: I'm not being sarcastic. The number of mountains-of-text word document resumes I've gotten in the past few weeks is too high).
I've actually written my resume in markup for a while just so that I could put it on a nice dynamically driven site. Sort of a fun weekend project (no, it's not hosted anywhere).
While I strongly doubt that this will ever be a standard, I think it's nifty, and potentially useful. It opens up easy, pretty resumes, which the world really needs (Note: I'm not being sarcastic. The number of mountains-of-text word document resumes I've gotten in the past few weeks is too high).
> It opens up easy, pretty resumes, which the world really needs
People have been doing XML+XSLT for their resumes for a long time, yet it really hasn't taken off in a standard way for whatever reason. Not sure this being JSON-based will change that. I guess I'm wondering what this solution brings to the table that previous attempts didn't.
People have been doing XML+XSLT for their resumes for a long time, yet it really hasn't taken off in a standard way for whatever reason. Not sure this being JSON-based will change that. I guess I'm wondering what this solution brings to the table that previous attempts didn't.
It's already possible using LaTeX and Modern CV http://www.ctan.org/pkg/moderncv
It took me until I got to the sample before I realized the page was talking about Resumés, not resuming file uploads or something. It was very confusing.
Nice. Now create a schema for job postings as well so that one can write a crawler to find all interesting vacancies in one's favorite companies.
Looks cool, but Queensland is a state, not a region.
Looks cool, although it looks a bit U.S.-centric and techie-centric.
Other people have mentioned the firstName/lastName problem and the region/state ambiguity. I'll mention a few more items that might be helpful if you really want this to become a worldwide standard:
1. In some countries, it is not only legal but also customary for employers to ask for, and job seekers to include, various demographic information about themselves that would be considered discriminatory in the U.S. For example, sex/gender, date of birth, marriage status, and family details. It would be good to define such fields in the schema but leave them optional. Or define a catch-all field where anyone can add any key-value pair.
1-1. Don't forget the full street address, including the postal code!
1-2. Citizenship. This is very important for companies that might need to sponsor your visa and/or geeen card.
1-3. In some countries, it is customary to include a photograph of yourself in your resume. Perhaps this could take the form of a "photo" field that takes a URL.
1-4. There needs to be a field where you can write down an alternate expression of your name. Many Korean names can be written in either Hangul or Hanja. Most Japanese names are written in Kanji, but often accompanied by Hiragana to help the reader pronounce them properly. A lot of employers in these countries require both forms.
2. Since this is going to be electronically processed, perhaps it would be a good idea to include the ticker code for publicly traded companies in one's employment history? GOOG is much easier to search for than variations of "Google", "Google Inc.", etc.
3. The publications schema will need to be significantly expanded if you want scientists and other academics to even consider using this. Take a look at how academic publications are cited. At the very least, there needs to be a field to specify the type of publication, e.g. book, ebook, edited book, journal article, newspaper article, conference presentation, workshop presentation, blog post, website, etc. There should also be a "doi" field for scientific and other academic publications.
3-1. The education schema needs a "summary" field, just like the employment schema.
4. Some employers prefer to get the content of the reference from the referee him/herself, rather than having the applicant include it in the resume. (Otherwise, the applicant could modify the content.) So you need fields to put the email address (to contact the referee) and a URL (to grab the content of the reference) in the references field. Oh, and don't forget the referee's employer and title/position. Those things matter.
4-1. Bonus points if the content of the reference can be authenticated with the referee's PGP key.
4-2. Extra bonus points if the entire resume can be authenticated with the applicant's PGP key, to prevent hiring agencies from messing with the content.
Other people have mentioned the firstName/lastName problem and the region/state ambiguity. I'll mention a few more items that might be helpful if you really want this to become a worldwide standard:
1. In some countries, it is not only legal but also customary for employers to ask for, and job seekers to include, various demographic information about themselves that would be considered discriminatory in the U.S. For example, sex/gender, date of birth, marriage status, and family details. It would be good to define such fields in the schema but leave them optional. Or define a catch-all field where anyone can add any key-value pair.
1-1. Don't forget the full street address, including the postal code!
1-2. Citizenship. This is very important for companies that might need to sponsor your visa and/or geeen card.
1-3. In some countries, it is customary to include a photograph of yourself in your resume. Perhaps this could take the form of a "photo" field that takes a URL.
1-4. There needs to be a field where you can write down an alternate expression of your name. Many Korean names can be written in either Hangul or Hanja. Most Japanese names are written in Kanji, but often accompanied by Hiragana to help the reader pronounce them properly. A lot of employers in these countries require both forms.
2. Since this is going to be electronically processed, perhaps it would be a good idea to include the ticker code for publicly traded companies in one's employment history? GOOG is much easier to search for than variations of "Google", "Google Inc.", etc.
3. The publications schema will need to be significantly expanded if you want scientists and other academics to even consider using this. Take a look at how academic publications are cited. At the very least, there needs to be a field to specify the type of publication, e.g. book, ebook, edited book, journal article, newspaper article, conference presentation, workshop presentation, blog post, website, etc. There should also be a "doi" field for scientific and other academic publications.
3-1. The education schema needs a "summary" field, just like the employment schema.
4. Some employers prefer to get the content of the reference from the referee him/herself, rather than having the applicant include it in the resume. (Otherwise, the applicant could modify the content.) So you need fields to put the email address (to contact the referee) and a URL (to grab the content of the reference) in the references field. Oh, and don't forget the referee's employer and title/position. Those things matter.
4-1. Bonus points if the content of the reference can be authenticated with the referee's PGP key.
4-2. Extra bonus points if the entire resume can be authenticated with the applicant's PGP key, to prevent hiring agencies from messing with the content.
Excellent feedback and you've set the bar high which is good! I don't have the time to reply to each point at the moment but will definitely copy it over to the issue tracker.
Ugh, what's the point? Hiring by robots?
Another multi format resume/CV tool: http://ars.io/
seemed like a good idea to me, although i didn't go the full 9 and write a schema or anything.
https://github.com/ransomw/ransomw.github.io/tree/master/med...
https://github.com/ransomw/ransomw.github.io/tree/master/med...
Beginning to wish I hadn't abandoned my modular JSON to LaTeX CV builder... C'est la vie!
ahh that would have been perfect!
I keep thinking an ontology instead of JSON based resume would be a lot better.
Seems like reinventing the wheel a bit here. Why not use jcard?
Could this be used with Namecoin (where JSON values are stored in a blockchain)? Perhaps something like https://github.com/onenameio/onename
That'd be a great way to make a pointless format even more pointless. But, sure.
Gravatar Url?
We should be able to generate those from the email. Good suggestion though, I'm going to add mine to my resume.
an XSD?
this is f---ing brilliant.
As somebody who deals with hiring, who is going to use this exactly?
The only 'benefit' I see is that the crawlers/recruiters can parse your resume easier.
Great for them; usually not so great for you.
The only 'benefit' I see is that the crawlers/recruiters can parse your resume easier.
Great for them; usually not so great for you.
Are you kidding? With this, I can more easily skip over those applicants with tons of Java and C++ development experience when I'm looking for a C# developer. No more wasting time on reading resumes with completely unrelated experience!
Why would I be kidding?
You are just backing up my point that recruiters will use it to grab your data and filter you like a product.
There is absolutely no benefit to you as an engineer. Quality / noise ratio is the issue here.
You are just backing up my point that recruiters will use it to grab your data and filter you like a product.
There is absolutely no benefit to you as an engineer. Quality / noise ratio is the issue here.
lol
lickMyAsshole.json
stupid
Now, if only people will actually use this.
To clarify, I meant that when looking for a job it is a pain to retype your resume multiple times (because having a human look at candidates apparently isn't a thing, especially at larger organizations). Having a standard format, supported by many employers would have made the process much easier.
My resume is set up as http://www.microformats.org/wiki/hresume and noöne supports that, and it's been around for a while.
My resume is set up as http://www.microformats.org/wiki/hresume and noöne supports that, and it's been around for a while.
Nice try, LinkedIn.
http://interop.europass.cedefop.europa.eu/
HR-XML (also comes in a JSON variant, "HR-JSON"?):
http://www.hr-xml.org/ http://www.hropenstandards.org/
There is also Microformat (hResume):
http://microformats.org/wiki/hresume
Europass is used by the European Union, HR-XML is used by the US government. Microformats are probably used by many. This stuff is OLD news. We certainly don't have a shortage of usable standards.