![]() ![]() The value of allOf is an array of schemas.) (Also, the value of properties is an objects, only those property values again are schemas. Your proposed wording removes this point, because now any JSON schema objects can be nested, even ones which are not legal OpenAPI model schemas. Those restrictions and extensions also apply to any nested schema objects in items, allOf, properties and additionalProperties. anyOf, oneOf, not, additionalItems, patternProperties are not allowed) and extensions ( readOnly, externalDocs, xml, x-* are allowed in addition). So Swagger model schemas (or now OpenAPI model schemas) work similar to JSON schemas, with some restrictions (e.g. I think the point of the original language was to replace all places in a schema where a nested "JSON Schema object" occurs (this is just inside of those four properties, and in some which are not supported at all) with a "Swagger Schema object".The following property names are taken from JSON Schema specification but their definitionsĪre changed in Open API to disallow boolean values - only an object value representing a JSON schema applied to the property values is allowed. This seems to indicate what's going on, in more direct language What seems to be happening here operationally, is that four properties from JSON Schema are being changed in Open API while keeping the property names. Also there don't seem to be any local definitions defined - the link in the statement "the Schema Object definition is used instead." points back to this section. In particular the last sentence is too hard to follow - the definitions can't be the same and not be the same. Maybe we should instead simply redefine additionalProperties generally? I'm not totally happy with this wording, feel free to propose a better one. To make this clearer in the next version of the spec, I suggest to add the following sentence to the cited paragraph above (before the list):Īlternative values of other types (boolean) are not allowed. (I just hit an API which used booleans in several places, and fails with swagger-codegen.) In Swagger-Codegen #1318, commented that this was actually meant as "the value of additionalProperties can only be a (Swagger) Schema object", not a boolean. This would be naively interpreted as additionalProperties can have a boolean or a schema value (with a schema being interpreted as an OpenAPI schema, not a JSON schema). The Schema Object definition is used instead. JSON Schema, only where the original definition references the JSON Schema definition, Their definition is the same as the one from Were adjusted to the OpenAPI Specification. The following properties are taken from the JSON Schema definition but their definitions true is interpreted as "additional properties follow no restrictions", false means "no additional restrictions", and an object is interpreted as a JSON schema applied to the property values (the empty object is thus equivalent to true). JSON Schema allows for additionalProperties both a boolean or an object value. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |