You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The JSON Resume schema serves a diverse community with varying needs. Many users have requested additions to the schema for their specific use cases – from tracking certification expiration dates to adding academic teaching experience, from including language proficiency standards to extending work highlights with additional metadata. While each request has merit for specific users, adding fields for every specialized need would make the schema increasingly complex and harder to maintain.
This proposal suggests a flexible solution: adding an optional custom field to every object in JSON Resume, including the root object. This approach would allow users to extend their resumes with implementation-specific data while maintaining compatibility with existing tools. Users could address their unique requirements immediately through custom fields, while the core schema remains focused on widely-used fields that serve the majority of users.
For example, academic institutions could add teaching-specific fields to work entries, certification authorities could include renewal requirements, and language schools could add proficiency standards – all without requiring changes to the core schema. This flexibility would enable innovation and experimentation while ensuring that resumes remain compatible across the JSON Resume ecosystem.
How it works
Resume authors would be able to add a custom object to any object in their resume to store additional properties. For example, adding detailed certification information:
The custom field can also elegantly handle metadata for array fields like keywords and highlights. Instead of modifying these arrays to accept objects (which would break existing tooling), metadata can be stored in the parent object's custom field:
This approach maintains compatibility with existing tools that expect simple string arrays while allowing rich metadata to be associated with each array item.
Common Use Cases
This extension mechanism supports many real-world needs:
Adding industry-specific certifications and qualifications
Including internal company information for HR systems
Supporting region-specific requirements (like Chinese personal identifiers or European Union GDPR preferences)
Enabling integration with applicant tracking systems
Adding metadata for automated processing
Supporting experimental features before they become part of the standard schema
Schema Implementation
To implement this proposal, the schema would need to be modified to allow a custom field in every object, including the root level. Here's how the schema changes would look:
Adds the custom field to every object in the schema
Maintains backward compatibility since the field is optional
Allows any valid JSON in the custom object through additionalProperties: true
Benefits
This approach provides several key advantages:
Complete backward compatibility with existing tools and theme formatters
A standardized way to extend any object in the schema
Flexibility to support various use cases without bloating schema
Gradual adoption path - the custom field is entirely optional
Clear separation between standard fields and custom fields
Reduced maintenance burden, as specialized fields needed by a small subset of users can be implemented through custom properties rather than requiring schema changes
Natural evolution path for the schema, as maintainers can analyze commonly used custom fields across resumes to identify which properties merit inclusion in future versions of the standard schema
Would love to hear the community's thoughts on this approach and any suggestions for refinement.
The text was updated successfully, but these errors were encountered:
The JSON Resume schema serves a diverse community with varying needs. Many users have requested additions to the schema for their specific use cases – from tracking certification expiration dates to adding academic teaching experience, from including language proficiency standards to extending work highlights with additional metadata. While each request has merit for specific users, adding fields for every specialized need would make the schema increasingly complex and harder to maintain.
This proposal suggests a flexible solution: adding an optional
custom
field to every object in JSON Resume, including the root object. This approach would allow users to extend their resumes with implementation-specific data while maintaining compatibility with existing tools. Users could address their unique requirements immediately through custom fields, while the core schema remains focused on widely-used fields that serve the majority of users.For example, academic institutions could add teaching-specific fields to work entries, certification authorities could include renewal requirements, and language schools could add proficiency standards – all without requiring changes to the core schema. This flexibility would enable innovation and experimentation while ensuring that resumes remain compatible across the JSON Resume ecosystem.
How it works
Resume authors would be able to add a
custom
object to any object in their resume to store additional properties. For example, adding detailed certification information:Or adding company-specific information to a work entry:
The
custom
field can be added to any object in the resume, including the root object and all nested objects:Extending Array Fields
The
custom
field can also elegantly handle metadata for array fields likekeywords
andhighlights
. Instead of modifying these arrays to accept objects (which would break existing tooling), metadata can be stored in the parent object'scustom
field:This approach maintains compatibility with existing tools that expect simple string arrays while allowing rich metadata to be associated with each array item.
Common Use Cases
This extension mechanism supports many real-world needs:
Schema Implementation
To implement this proposal, the schema would need to be modified to allow a
custom
field in every object, including the root level. Here's how the schema changes would look:This schema change:
custom
field definitioncustom
field to every object in the schemaadditionalProperties: true
Benefits
This approach provides several key advantages:
custom
field is entirely optionalWould love to hear the community's thoughts on this approach and any suggestions for refinement.
The text was updated successfully, but these errors were encountered: