Semantic error at ... Schema "type" key must be a string
See original GitHub issueWith Swagger Editor 3.5 when opening a Swagger 2.0 description containing constructs such as
type: object
properties:
KeyDate:
type:
- string
- 'null'
I get the error message above.
Opening the same file with Swagger Editor 2.10.5 works fine, as does opening it with Swagger UI 2.x and the latest Swagger UI 3.x.
This seems to be a regression.
Is it planned to be fixed?
Issue Analytics
- State:
- Created 5 years ago
- Comments:10 (5 by maintainers)
Top Results From Across the Web
Generated Swagger.json Does Not Validate with Swagger Editor
Open the Swagger Editor. Load the Swagger file that was downloaded into the Swagger Editor (File -> Import file).
Read more >How to solve error in yaml/swagger? - Stack Overflow
(The error message indicates that there is something wrong with the responses: line, but that one is actually valid YAML. If the message...
Read more >Using $ref - Swagger
According to RFC3986, the $ref string value (JSON Reference) should contain a URI, which identifies the location of the JSON value you are...
Read more >Fix Swagger Validator errors in Power Platform connectors
The type of the enum value is '{0}' but it should be '{1}' as specified in the schema. The value must be replaced...
Read more >Semantics - JSON Schema
For a JSON Schema S, we use properties(S) to denote all keywords k1, ..., kn that appear in the key-value pair of the...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@shockey cool, works like a charm 😄
@ralfhandl awesome! Just one more note from me here…
Note that Swagger Editor doesn’t bar you from doing much of anything based on the validity of your definition - you can still save, Try-It-Out, and use the Codegen service.
We add new validators fairly frequently, and we’ll probably never have a complete set of them. OpenAPI has upwards of 30 object types, many of which nest inside of one another, so there’s a large set of things that we could validate for, that we haven’t validated against yet.
We never tag new validators (even error-level validators) as breaking changes, our stance is that we only support fully spec-compliant (as opposed to previously-validator-compliant) definitions. I know it’s not any fun to think you have a good OpenAPI document one day, and have it flagged the next, but given the problem space that our validators cover it’s the best experience that we can provide at this time.
Hopefully this sheds some light on why we do things this way 😄