OpenAPI and JSON Schema don't support tuple declarations about cadl HOT 14 OPEN

Yeah for the 2nd point I would say that if you have

alias Stuff = [float64, string];

you get the following openapi3 + a warning

type: array
items: 
  anyOf:
     - type: number
       format: double
     - type: string
minLength: 2
maxLength: 2

from cadl.

In practice I haven't seen anyone generating tuples from openAPI with length constraints, though I haven't looked super broadly. It would need to be heuristic though, the tuple type for @minLength(1000) @maxLength(2000) would be ridiculous 😂

from cadl.

I guess we don't have a good support for tuples in openapi3 and not sure what we should generate here. In this specific case we could treat it as an array of part with length 1 but if you lets say have [A, B] it is a bit more complex.

from cadl.

I thought I recalled implementing this in JSON Schema, but I don't see that it's supported (crash in #2460 aside). I think a reasonable representation of tuples in JSON Schema is using an array type with a fixed length and each element's schema defined with prefixItems. I don't know if prefixItems is reasonable for OpenAPI 3.0 though, thoughts @mikekistler?

from cadl.

I don't think it is an option for openapi3 but for 3.1 it does seems to be the way

https://stackoverflow.com/questions/57464633/how-to-define-a-json-array-with-concrete-item-definition-for-every-index-i-e-a

For 3.0 we'd have to make it a oneOf all the options and of the length of the tuple

from cadl.

I guess I didn't realize that this was valid syntax. This represents a tuple? Where are the docs for tuple?

from cadl.

Looks like they are not documented under language basics and should be. They come up for various decorators which expect them, however.

from cadl.

• Separate issues for OpenAPI. - 5
• Fixing EF to not crashing (track in other issue)
• Supporting tuple declaration in JSON Schema - 5

from cadl.

For 3.0 we'd have to make it a oneOf all the options and of the length of the tuple

I think that for 3.0 it should just be an error.

from cadl.

Feels a little strong to me to be an error, specially in cases where you have something like

alias Point2D = [float64, float64];

this can be acurrately represented with

type: array
items: 
  type: number
  format: double
minLength: 2
maxLength: 2

My vote would be:

• If all the types in the tuple are the same, represent it as above with no error
• If types are different emit a warning and use anyOf

from cadl.

For your last bullet, just to be clear, are you saying the items schema is anyOf the tuple types? If so, I think that sounds reasonable. the oneOf above seems cool but I suspect the codegen from that wouldn't be pretty.

@mikekistler can you say more about why an error is appropriate here? I think in general we should strive to emit something for all TypeSpec unless there's a very good reason not to.

from cadl.

Also, just want to point out that tuples are not exactly that exotic. E.g. GeoJSON defines Position as an array of exactly length 2 or 3, where the indexes correspond to long, lat, and optionally elevation, respectively. A type like:

model Geo {
  coordinates: [float64, float64] | [float64, float64, float64]
}

would give better codegen for languages that support such types (and would be even more terse if we supported optional tuple elements, which I imagine we will one day!), over something like:

model Geo {
  @minLength(2)
  coordinates: float64[];
}

from cadl.

@timotheeguerin I feel like we should leave the maxLength out actually, that feels like as if we added additionalProperties: false to every schema... The tuple demands you provide at least those elements, any extra elements might be sent and likely ignored?

from cadl.

I guess but also if you were to look at the openapi/jsonschema for that and not see the maxLength it would look like any array and not sure you would ever regenerate a tuple seeing that

from cadl.