Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document difference of type attribute with jsonschema spec #397

Closed
casualjim opened this issue Jun 19, 2015 · 6 comments
Closed

Document difference of type attribute with jsonschema spec #397

casualjim opened this issue Jun 19, 2015 · 6 comments

Comments

@casualjim
Copy link
Contributor

The swagger specification in a definition doesn't allow for things like

{ "type": ["string", "null"] }

But the specification markdown document currently says that the definition is taken from json schema.
That is incorrect.

@Cwellan
Copy link

Cwellan commented Jan 18, 2018

This thing is now allowed, and JSON schema Draft 4 allows it:
JSON Schema Draft 4 Link
The issue must be closed.

@MikeRalphson
Copy link
Member

Neither OpenAPI 2.0 or 3.0.x support unmodified JSON Schema Draft 04 schema objects and they specifically do not support the type property taking an array. In OpenAPI 3.0.x this must be represented as:

type: 'string'
nullable: true

@Cwellan
Copy link

Cwellan commented Jan 18, 2018

Why do you say that it specifically doesn't support the array ? How did you get the information ?
The only thing I was able to find is:

The following properties are taken directly from the JSON Schema definition and follow the same specifications:

  • ...
  • type

@MikeRalphson
Copy link
Member

If you are referring to OpenAPI 2.0 then it is a long tortuous trail, but is summed up by this comment. A published errata document would certainly help in this case.

Regarding OpenAPI 3.0.x

The following properties are taken from the JSON Schema definition but their definitions were adjusted to the OpenAPI Specification.

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

@handrews
Copy link
Member

@Cwellan see also #1389 for a compromise proposal for future versions.

@philsturgeon
Copy link
Contributor

This was fixed in #1977 so we can close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants