I did something similar while in grad school when I was applying to jobs several years ago, except I made it so that I could customize the output.
I found myself spending so much time manipulating my resume to match each job description I was applying to, that I put all of my experiences, interests, etc. into a sqllite db. Using that, I created a UI to quickly select which items I wanted in this iteration of my resume, and then spit it out in a few different HTML formats that could be easily converted to txt or pdf. I eventually intended to do ngram matching with job description bullet points, but I got hired and moved onto other projects.
The sqllite db was overkill. Honestly I think what would have been better would have been a json format not unlike http://jsonresume.org, because it allows for more attributes, some of which could be used to group experience.
This markdown is nice because it's humanly intelligible, but what if you want to give hidden attributes to the different items - attributes which shouldn't be in the final media file?
Clojure people like EDN instead of JSON. :) When I hire contractors, I ask for an EDN formatted resume, submitted via curl to a quick web app. I validate it on the server side. People enjoyed it (at least the ones who succeeded).
It's too bad the EDN standard ain't an actual standard or proper spec. I had to rail on those people for fucking ages to get any ambiguities fixed and last I gave a damn it still:
1. Wasn't congruent with what Clojure's parser allows
2. Defined by whatever Hickey feels this year
I've worked on more than one edn parser in non-Clojure languages, it was Total Hell.
Hitching your wagon to EDN isn't advisable, there are better formats if you need them.
I don't think that "Whatever Rich Hickey feels this year" is a serious pain point. Rich isn't fickle with changes; quite the opposite. Clojure has evolved, but Rich explains himself well.
This usage scenario had occurred to me, but didn't seem like a priority in the first version. It does seem like this is where vanilla markdown would fall down, but fortunately pandoc supports header attributes in markdown source [0], and filters with which you can programmatically alter the internal representation. So potentially, this seems doable without having to use a more structured representation like jsonresume.
I found myself spending so much time manipulating my resume to match each job description I was applying to, that I put all of my experiences, interests, etc. into a sqllite db. Using that, I created a UI to quickly select which items I wanted in this iteration of my resume, and then spit it out in a few different HTML formats that could be easily converted to txt or pdf. I eventually intended to do ngram matching with job description bullet points, but I got hired and moved onto other projects.
The sqllite db was overkill. Honestly I think what would have been better would have been a json format not unlike http://jsonresume.org, because it allows for more attributes, some of which could be used to group experience.
This markdown is nice because it's humanly intelligible, but what if you want to give hidden attributes to the different items - attributes which shouldn't be in the final media file?