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.
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.
> 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.
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/
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
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)
> 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.
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. :-)
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):
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).
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.
> 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...
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.
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>
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.
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.
> 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?
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 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 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.
> 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?
* 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...).
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
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.
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 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.
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.
>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.
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
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.
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 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 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.
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.