New 3.1 rule for mixed `maximum` and `exclusiveMaximum`

[tatomyr]

Is your feature request related to a problem? Please describe.

In OAS3.1's JSON Schema, maximum and exclusiveMaximum both are numbers and it doesn't make sense to specify both. However, technically this is possible, and we don't detect such cases.

Same goes for the minimum and exclusiveMinimum pair.

Describe the solution you'd like

It would be helpful to show at least warnings for schemas in OAS 3.1 where those keywords are used together like in the screenshot:

Describe alternatives you've considered

Adding this check to the struct rule, but it doesn't really make sense as it's not strictly prohibited to have those two keywords together.

Additional context

Discovered while reviewing https://github.com/Redocly/redocly-cli/pull/2300.

[jeremyfiel]

what is your thinking for writing this rule? They are redundant or will you check for conflicting constraints?

[tatomyr]

@jeremyfiel they are mutually exclusive. So yes, check for conflicting constraints.

[jeremyfiel]

I think these two rules should be sufficient.

Maybe a better description can be suggested..

This rule is only valid for Oas3_1 /Oas3_2 rules.

rules:
  rule/schema-mutually-exclusive-maximum-keywords:
    severity: warn
    message: these two keywords can provide conflicting validation constraints, it's recommended to define only one of them.
    subject: 
      type: Schema
    assertions: 
      defined: true
      mutuallyExclusive: 
        - exclusiveMaximum
        - maximum
  rule/schema-mutually-exclusive-minimum-keywords:
    severity: warn
    message: these two keywords can provide conflicting validation constraints, it's recommended to define only one of them.
    subject: 
      type: Schema
    assertions: 
      defined: true
      mutuallyExclusive: 
        - exclusiveMinimum
        - minimum

[tatomyr]

Nice solution @jeremyfiel! Could you maybe add it to our Cookbook? Maybe it worth creating a separate ruleset that will include configurable rules like this? 🤔

[jeremyfiel]

I think these can probably be added to 3.1/3.2 recommended

what do you think?

[tatomyr]

We cannot add a configurable rule to built-in rulesets. We either have to transform it to a proper built-in rule or create an external ruleset which we can extend from recommended and use it instead (something like recommended-extended). I have to think more on that, but you can start small from creating your own ruleset at our Cookbook, which you'll be able to reuse with something like the following: redocly lint openapi.yaml --extends=https://link-to-the-ruleset 🙂.