Henry Andrews

PR #4591 defines a deprecation policy, and the use cases for "experimental" no longer really apply. We can file a new issue for "experimental" if it comes up again.

To @darrelmiller 's concern, the experimental use cases that still apply _are_ addressed by `x-` fields, but we are no longer putting in anyting that would be experimental and not...

@pplr I want to explore your use case a bit with existing JSON Schema features. This also comes up in hyper-schema a lot so if possible I'd like to align...

@mewalig this issue is really about describing existing APIs rather than best practices for designing new ones.

@pplr > The way you use the not field is unusual. > Understanding "property": {"not": {}} meaning is not straightforward! This is why in draft-06 we defined boolean schemas: `true`...

@stueynz There is a `deepRequired` proposal for JSON Schema, although it probably won't be considered until draft-09 (which will quite possibly be out before OpenAPI updates JSON Schema support anyway,...

@fantavlik see #1622 for why method-specific validation behavior is a problem for JSON Schema compatibility, which is a goal of OAS 3.1. While this approach is better in that it...

@codyaray the way this can work is to write the _minimally_ restrictive schema (which can be passed to a plain, non-HTTP-aware JSON Schema validator in the next version of OAS...

I like `writeOnce` a lot! @karlismelderis with extensible vocabularies, it's not necessary for a keyword to get adopted into the main JSON Schema spec to be useful. You can declare...

@YousefHaggy we're trying not to add more OAS-custom fields to the Schema Object, and leave that instead to the JSON Schema project and JSON Schema's own extensibility mechanisms. This is...