Closed JohnScience closed 5 months ago
#/properties/basics/properties/name/type
Non-change: In my opinion, a resume without the candidate's name probably should not be considered a resume.
#/properties/basics/properties/label/type
Change: "type": "string"
=> "type": ["string", "null"]
.
Comment: Generic resumes exist.
#/properties/basics/properties/image/type
Change: "type": "string"
=> "type": ["string", "null"]
.
Comment: Presence of a photo in the resume is already debatable. Probably, this field should be optional in the stricter version of JSON resume standard as well.
#/properties/basics/properties/email/type
Non-change: Emails are so ubiquitous today that it's hard to imagine a situation where the resume without email would make sense.
#/properties/basics/properties/phone/type
Change: "type": "string"
=> "type": ["string", "null"]
.
Comment: Websites like Monster are known to be constantly scanned for phone numbers by scam callers. This resulted in some people keeping their phones off the resumes.
#/properties/basics/properties/url/type
Change: "type": "string"
=> "type": ["string", "null"]
.
Comment: While most people might have a personal page (on Mastodon/FB/Instagram), it may make no sense to have it in the resume.
P.S.
WORK IN PROGRESS
I had similar thoughts just yesterday https://github.com/jsonresume/jsonresume.org/issues/118
Will have a think and leave some thoughts later today
While drafting a new schema, I realized that type: "object"
by default has implication that its fields can be omitted. Therefore, absence of a field (such as an endDate
) is not an error.
Yeah omission and additives should be fine.
Then my use case doesn't need any changes to the schema. Sorry for bothering you!
Awesome @JohnScience
I am about to give some love to the schema repo, so let me know if you reach any other hurdles and we will try to sort out a solution.
You will likely outgrow the schema, but we are very much in support of super/sub sets.
There is also the meta
property which allows for
At Searchless, we were planning to use JSON schema standard but found out that its requirements are too strict for conversion from regular resume to JSON resume.
The current schema
rejects the following substandard "JSON resume" for multiple reasons:
It was generated by our in-house tools from https://careers.yorku.ca/files/2017/04/Sample-Resume-1st-Year-No-Work-Experience.pdf. There are many problems with it.
If we run the checks of https://www.jsonschemavalidator.net/ against it, we'll see that there are 20 errors.
What's the main problem?
null
s are necessary to represent real-world resumes. However, the schema technically does not allow fornull
values.I propose to also have the "relaxed" variant of JSON resume schema with values permitting
null
s.