The Last Breaking Change
json-schema.org
The Last Breaking Change
1–10 of 66 posts
Re: The Last Breaking Change
#2Admiring the chutzpah of declaring this will be the "last breaking change". We'll see!
And perhaps json schema should borrow from http header conventions of old and allow unknown elements if prefixed in some way e.g:
X-my-funky-element: true
Re: The Last Breaking Change
#3SMH
> A couple years later, they want to upgrade the validator now that supports the 2025 specification. However in that 2025 specification, we added database-field-id as a keyword, and its value is expected to be a string. Suddenly the user's schema is no longer valid. We've broken a user by adding a new keyword.
No you haven't. They chose to change. Same as if they change to another schema format altogether (eg XML). Is this implying a user is going commit to a schema (pragmatic laziness, notwithstanding) that they haven't read? Regardless, their following solution baffles...
> Therefore, no keyword addition can be considered safe, making forward compatibility impossible to guarantee.
Correct.
> Using the vocabulary requires writing a custom meta-schema that adds the vocabulary URI and references the associated meta-schema, and referencing that custom meta-schema in the schema.
I just can't fathom this ceaseless drive toward cruft. Now a meta-vocabulary (a sub-schema). That's supposed to be better? Change will come, in 10 years, 50 years, etc. Semantic versioning normalizes it in the json-schema itself. It's as good a system as any and definitely better than adding another versioned dependency.
Re: The Last Breaking Change
#4Do it like OpenAPI does.
Separate structure from properties and type. And if you want a fixed value your type is a value.
That way you don't mix the JSONSchema's schema is separate from the thing you're describing.
Re: The Last Breaking Change
#5Underscore prefixes like C.
Dedicated property to act as kitchen sinks, e.g. "custom", that says "anything in here is implementation specific".
Simply not allowing custom keywords at all, also a good option. Have users write higher level schemas that compile down to jsonschema.
All viable options.
Re: The Last Breaking Change
#6I prefer letting people use arbitrary keys, with a _caveat emptor_.
It's much cleaner and easier to use. And it the vast majority of cases there will never be a collision.
You can also pin your schema version with `$schema`, so breaking changes should be opt-in only.
Re: The Last Breaking Change
#7[deleted]
Re: The Last Breaking Change
#8SMH > A couple years later, they want to upgrade the validator now that supports the 2025 specification. However in that 2025 specification, we added database-field-id as a keyword, and its value is expected to be a string. Suddenly the user's schema is no longer valid. We've broken a user by adding a new keyword. No you haven't. They chose to change. Same as if they change to another schema format altogether (eg XML…
> But many people also said they would be less bothered if there was a defined migration path and tooling to help.
If things were left as-is (allowing unknown keywords), it would be straightforward to write a tool that checks "upgrade compatibility" for a schema. If it's using keywords that were unknown under the old JSON Schema version but are now supported, the schema must be fixed before the JSON Schema version can be upgraded.
Re: The Last Breaking Change
#9Can anyone mention some interesting projects/use-case for JSON Schema?
I have terrible WSDL flashbacks from a past project, where the abstraction layer was always either too high (something simpler was better) or too low (and written documentation was better).
Re: The Last Breaking Change
#10Instead of making a brutal narrow spec that snubs ease of use & extensibility, just to create a "last breaking change" forever spec, the spec should definitely just keep dropping new major versions when it needs to change.
This is an ugly & rough conceitedness propsed here: no one can do anythint, because we reserve the right to do anything, and we dont want to have to drop a new major version to do it.
Craven attitude. Building ultra-strict narrow protocols like this should be highly highly discouraged. This is such a mean & awful tradeoff to foist upon people; I cant see any advantage to making a brittle, narrow, but forever "safe" little path like this. Be braver.