OpenAPI: exclusiveMinimum/Maximum

[cueckoo]

Originally opened by @wroge in cuelang/cue#412

What version of CUE are you using (cue version)?

$ cue version
cue version v0.2.0 darwin/amd64

Does this issue reproduce with the latest release?

yes

What did you do?

#A: {
    value: >0 | *1
}
cue def -o openapi+yaml:openapi2.yaml test.cue

What did you expect to see?

openapi: 3.0.0
info:
  title: Generated by cue.
  version: no version
paths: {}
components:
  schemas:
    A:
      type: object
      required:
        - value
      properties:
        value:
          type: number
          minimum: 0
          exclusiveMinimum: true
          default: 1

What did you see instead?

openapi: 3.0.0
info:
  title: Generated by cue.
  version: no version
paths: {}
components:
  schemas:
    A:
      type: object
      required:
        - value
      properties:
        value:
          type: number
          exclusiveMinimum: 0
          default: 1

I copied this code into the Swagger Editor and received this error:

Structural error at components.schemas.A.properties.value.exclusiveMinimum
should be boolean

[cueckoo]

Original reply by @mpvl in cuelang/cue#412 (comment)

I guess it depends on the version of JSON Schema you consider. CUE interprets it to the current standard.

Is there any particular JSON Schema version that is required for OpenAPI?

[cueckoo]

Original reply by @wroge in cuelang/cue#412 (comment)

I didn't know there was a divergence between the JSON schema and OpenAPI. OAPI Issue 1977

The list of differences is now tiny, only 4 extra keywords, with 2 notes about how exlusiveMinimum and exclusiveMaximum can be used in two ways (in order to maintain BC with OpenAPI v3.0).

[cueckoo]

Original reply by @mpvl in cuelang/cue#412 (comment)

Yeah, not the easiest thing to manage, with both CUE, OpenAPI and JSON Schema being moving targets. We're working at least to get CUE to a backwards compatibility guarantee, modulo backwards incompatible changes imposed by OpenAPI/JSON Schema.

Note there is also somewhat of a divergence between OpenAPI for CRDs versus more general OpenAPI standards.

I guess the issue is that this is not working for v3.0.0, which accepts only booleans. It seems reasonable to support this, weren't it for the fact hat OpenAPI and JSON Schema themselves are fairly fast-moving targets.

How much could people live with only supporting v3.1.0?

[cueckoo]

Original reply by @wroge in cuelang/cue#412 (comment)

I think CUE can be very useful if it knows all the inconsistencies of the other formats. However, it makes sense to wait for version 3.1.0 if all problems are automatically fixed.

[cueckoo]

Original reply by @mpvl in cuelang/cue#412 (comment)

I've changed the behavior to generate bool for OpenAPI. I've added a version option in the config and changed it such that it will start printing numbers again for v3.1.0.

See https://cue-review.googlesource.com/c/cue/+/6361

This also adds reading support in jsonschema for this legacy encoding.