ATS-Friendly Resume Builder Project Dropped

I have just spent almost three months experimenting with various implementations of over a dozen most popular applicant tracking systems (commonly referred to as ATS's) trying to figure out what a job seeker can do in order to improve the accuracy of how his/her resume is parsed by and imported into an ATS.

Had the experiment been successful, I would be able to alleviate the two major problems pretty much any ATS out there seems to have:

• for employers -- reduce the likelihood of resumes of well-qualified applicants getting "blackholed" because of bad resume parsers (and most of them are pretty bad);
• for job seekers -- minimize the time wasted filling in countless text boxes with the information from their resumes over and over again.

The image above was posted by someone on LinkedIn. License is unknown. I claim fair use.

My logic was very simple and -- translated into a language as non-technical as possible -- went kind of like this:

• Since job applicants have no direct control of how well an ATS parser "splits" their resumes into discrete "pieces" of data and "stuffs" those "pieces" into database "fields", the only thing they can do is help the parser do its job better by "telling" it which "pieces" should go into which "fields".
• The easiest way to "tell" a text parser which "pieces" of a text should go into which database "fields" is to mark up those "pieces" inside the text using markup tags (see an example here).
• As long as a resume contains markup language an ATS "understands", the resume should get parsed cleanly, and there should be no manual filling out forms left to do.
• Luckily (or so I thought), there is such a "common language" - HR-XML, presently known as "HR Open Standards". It allows various software applications that comprise a company's Human Resources Information System (HRIS) or software applications in different organizations (say, an outside recruiting agency and HR departments of its clients) exchange data, even if those applications come from different vendors, as long as they "speak the same language".
• Assuming that the same should apply when it comes to exchanging data between a job seeker and an ATS, I was going to develop a web application that would let users build HR-XML-compliant resumes. A user would fill out a web form just once, and the application would generate a resume for him/her with all the required XML tags embedded. When uploaded to an ATS that supports HR-XML, the resume should be parsed cleanly and all the fields of the online job application should be populated correctly.

Sounds logical, doesn't it? Well, logic doesn't always work in the real world.

Not willing to waste my time developing an application that may or may not be of help, I decided first to make sure that my assumption that an HR-XLM-compliant resume should be parsed correctly by an HR-XML-compliant ATS was correct. It turned out to be wrong. Depending on the file formats of the resumes used in the experiment, most ATS's either ignored the embedded XML or returned errors complaining about unsupported file formats.

So, looks like, until applicant tracking systems learn to "understand" resumes, which is unlikely to happen any time soon, you, people, will be forced to fill out (almost) identical online application forms over and over again.