Allow 'type' to be array, based on JSON Schema Draft4(partial solution for 'oneOf' problem).

[IvanGoncharov]

Spin off from #333, see this comment.

JSON Schema Draft4 supports arrays as values of type properties:

The value of this keyword MUST be either a string or an array. If it is an array, elements of the array MUST be strings and MUST be unique.
String values MUST be one of the seven primitive types defined by the core specification.

So you can write:

{
  "type": ["string", "array"],
  "items": {
     "type": "string"
  }
}

And it validates both string and array of strings.

It can be easily implemented in static-typed languages. Let's imagine following OpenAPI spec:

swagger: '2.0'
info:
  version: 0.0.0
  title: Simple API
paths:
  /:
    get:
      responses:
        200:
          description: OK
          schema: '#/definitions/Data'
definitions:
  Data:
    type:
      - string
      - array
    items:
      type: string

Based on it you can generate base class Data and two childs DataString and DataArray.
An appropriate class can be easily chosen based on data themselves based on type of actual JSON value.
So functional it's very similar to how discriminator works.

I think such step towards JSON Schema resolves a lot of oneOf controversial without introducing too many problems for underlining tools.

[fehguy]

parent issue #579

[webron]

Tackling PR: #741

[brendo]

Couldn't help but notice this wasn't tackled in #741? The spec still states:

type - Value MUST be a string. Multiple types via an array are not supported.

Are there plans to support this in 3.x?

[fehguy]

No, you can use oneOf or anyOf to do effectively the same thing. But arrays in types are not supported.

[brendo]

You can, but the error message for using oneOf is awful and creates a terrible developer experience. Have a look at these examples, firstly using oneOf (which produces two errors, not the expected four?), and then with multiple types (one clear error message).

[fehguy]

sure, that's a tooling concern though, no? This is more about the specification definition than an existing implementation.

[brendo]

Good point.

For this particular issue then, is it more of a "won't implement" rather than an proposal?

There was a rather large discussion in #333 (and I assume #1026 will go that way too) that hinted supporting something like this could make life difficult for tools that consume Open API. My impression from that is that this wouldn't be rolled into the spec anytime soon...

[fehguy]

It's my belief that it won't be implemented right now, but there is a process to roll up open proposals into possible next-spec changes.