Overview
Proposals are formal documents that precisely define specification changes for new JSON Schema features. They serve as the bridge between initial concepts and stable implementation.When to Create a Proposal
A proposal should be created when:- Rough consensus has been reached on a feature concept in a GitHub issue
- At least two Core Team members have implemented prototypes
- The community is ready to move from discussion to formal specification
Proposal Structure
All proposals use the official Proposal Template and must include the following sections:Required Sections
Current Status
Explain where the proposal is in its journey (free text, not tied to the formal lifecycle stages).
Overview
Include three key subsections:Problem Statement: What problem exists that needs solving?Solution: What is the proposed solution? Include examples of use.Limitations: Are there any limitations inherent to the proposal?
Change Details
Define the precise specification changes. These changes will be made verbatim to the specification.Example format:The proposal should include:
- The following section will be added to the JSON Schema Core specification as a subsection of “Keywords for Applying Subschemas Conditionally”.
-
The following subschema will be added to the Applicator Vocabulary schema at
/properties/{keyword}with the keyword schema definition in JSON format.
Accompanying Documentation
Draft ADR (Architectural Decision Record)
Along with the proposal document, create a draft ADR using the file name:- Context and problem statement
- Decision drivers
- Considered options (with pros and cons)
- Decision outcome and justification
- Additional information from the “Concept” discussion
The draft ADR will be completed, dated, and moved to the
adr folder when the feature becomes stable.Experimental Keywords in Meta-schemas
When a proposal is created, the proposed keywords are added to the vocabulary meta-schemas in:- Latest published release
- The
mainbranch of the repository
Experimental Keyword Format
The subschema for experimental keywords contains only a$comment:
This approach allows the keyword without validating its syntax, since the syntax may change during experimentation. It permits different implementations to support different variations of each proposal.
Adding Tests
Tests for the proposal must be added to the JSON Schema Test Suite during the proposal stage. This allows implementations to verify their support for the experimental feature.Moving to Stable
A proposal moves from experimentation to stable when:Implementation Support
At least 5 implementations support the feature
Usage Evidence
Sufficient evidence of real-world use
Stability Period
No changes requested for 6 weeks
Integration Process
When a feature becomes stable:- The feature is incorporated into the specification in the
mainbranch as specified by the proposal - The draft ADR is completed, dated, and moved to the
adrfolder - The vocabulary meta-schema in
mainis updated to include a subschema that validates the feature’s syntax requirements - Tests are incorporated into the main test suite
- Upon publication of the new release, the meta-schema for the previous release will have the keyword removed
Proposal Removal
If a proposal cannot advance to stable status, it may be removed:- Proposal document is moved to an
archivesubfolder - Keyword is removed from meta-schemas
- Tests are moved to an
archivesubfolder
Removal of a feature that hasn’t reached stable status is not considered a breaking change.