6 ms·

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

by bphogan 12y ago

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.

thomasfromcdnjs 12y ago
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.
- xienze 12y ago
  > 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.
  - thomasfromcdnjs 12y ago
    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.
    - xienze 12y ago
      > 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.
    - bphogan 12y ago
      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/ http://xslteatime.herokuapp.com/ There's a pre-built example you can run.
  - mindcrime 12y ago
    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. :-)
    - e12e 12y ago
      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/ http://craigc.com/pg/
      - e12e 12y ago
        Hm, looks like there might be bit too many dependencies here for my taste: npm install resume-cli du -hs node_modules 103M node_modules All this, and it doesn't provide line numbers when reporting errors due to an extra comma in the json file? Nor does it (yet) have LaTeX output... 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).
  - tracker1 12y ago
    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.
    - bphogan 12y ago
      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: <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> vs { "title": "Being Awesome", "subtitle" : "Surviving on HN Posts", "author": { "first_name" : "Max", "last_name" : "Power" } } To me, it seems that both of those: 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.
- bphogan 12y ago
  > 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.
  - thomasfromcdnjs 12y ago
    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/ 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/ http://jeremydorn.com/json-editor/
    - bphogan 12y ago
      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.
    - Paul_Dessert 12y ago
      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.
- deleted 12y ago
  [deleted]
- esbranson 12y ago
  > has evidently not been able to amass a large developer community But let me guess: you will?
  - zimpenfish 12y ago
    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)
- 59nadir 12y ago
  > 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?
crdoconnor 12y ago
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.
- bphogan 12y ago
  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.
  - crdoconnor 12y ago
    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.
    - xienze 12y ago
      > 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?
bstar77 12y ago
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.
- bphogan 12y ago
  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.
fs111 12y ago
The EU has developed an XML standard for CVs years ago: http://interop.europass.cedefop.europa.eu/data-model/xml-resources/ http://interop.europass.cedefop.europa.eu/data-model/xml-res...
- Qantourisc 12y ago
  year="1975" month="--03" day="---01" ???
icebraining 12y ago
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.

by bphogan 12y ago

thomasfromcdnjs 12y ago

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.

xienze 12y ago
> 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.
- thomasfromcdnjs 12y ago
  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.
  - xienze 12y ago
    > 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.
  - bphogan 12y ago
    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/ http://xslteatime.herokuapp.com/ There's a pre-built example you can run.
- mindcrime 12y ago
  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. :-)
  - e12e 12y ago
    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/ http://craigc.com/pg/
    - e12e 12y ago
      Hm, looks like there might be bit too many dependencies here for my taste: npm install resume-cli du -hs node_modules 103M node_modules All this, and it doesn't provide line numbers when reporting errors due to an extra comma in the json file? Nor does it (yet) have LaTeX output... 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).
- tracker1 12y ago
  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.
  - bphogan 12y ago
    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: <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> vs { "title": "Being Awesome", "subtitle" : "Surviving on HN Posts", "author": { "first_name" : "Max", "last_name" : "Power" } } To me, it seems that both of those: 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.
bphogan 12y ago
> 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.
- thomasfromcdnjs 12y ago
  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/ 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/ http://jeremydorn.com/json-editor/
  - bphogan 12y ago
    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.
  - Paul_Dessert 12y ago
    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.
deleted 12y ago
[deleted]
esbranson 12y ago
> has evidently not been able to amass a large developer community But let me guess: you will?
- zimpenfish 12y ago
  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)
59nadir 12y ago
> 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?

crdoconnor 12y ago

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.

bphogan 12y ago
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.
- crdoconnor 12y ago
  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.
  - xienze 12y ago
    > 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?

bstar77 12y ago

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.

bphogan 12y ago
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.

fs111 12y ago

The EU has developed an XML standard for CVs years ago: http://interop.europass.cedefop.europa.eu/data-model/xml-resources/ http://interop.europass.cedefop.europa.eu/data-model/xml-res...

Qantourisc 12y ago
year="1975" month="--03" day="---01" ???

icebraining 12y ago

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.