29 Matching Annotations
- Aug 2023
-
ajv.js.org ajv.js.org
-
Ajv generates code to turn JSON Schemas into super-fast validation functions that are efficient for v8 optimization.
-
- Mar 2023
-
stackoverflow.com stackoverflow.com
-
Exactly my thoughts on the matter! I'm coming from XML SOAP background and concept of schema just got into my blood and JSON documents rather don't announce their schema. To me it's whether server "understands" the request or not. If server doesn't know what "sales_tax" is then it's simply 400: "I have no idea what you sent me but definitely not what I want.".
-
- Sep 2022
-
json-schema.org json-schema.org
-
A workaround you can use is to move additionalProperties to the extending schema and redeclare the properties from the extended schema.
-
Because additionalProperties only recognizes properties declared in the same subschema, it considers anything other than “street_address”, “city”, and “state” to be additional. Combining the schemas with allOf doesn’t change that.
-
It’s important to note that additionalProperties only recognizes properties declared in the same subschema as itself. So, additionalProperties can restrict you from “extending” a schema using Schema Composition keywords such as allOf. In the following example, we can see how the additionalProperties can cause attempts to extend the address schema example to fail.
-
-
stackoverflow.com stackoverflow.com
-
In your scenario, which many, many people encounter, you expect that properties defined in schema1 will be known to schema2; but this is not the case and will never be.
-
When you do: "allOf": [ { "schema1": "here" }, { "schema2": "here" } ] schema1 and schema2 have no knowledge of one another; they are evaluated in their own context.
-
I'm not sure if there's a reason why additionalProperties only looks at the sibling-level when checking allowed properties but IMHO this should be changed.
-
It's unfortunate that additionalProperties only takes the immediate, sibling-level properties into account
-
additionalProperties applies to all properties that are not accounted-for by properties or patternProperties in the immediate schema.
annotation meta: may need new tag: applies to siblings only or applies to same level only
-
additionalProperties here applies to all properties, because there is no sibling-level properties entry - the one inside allOf does not count.
-
You have stumbled upon the most common problem in JSON Schema, that is, its fundamental inability to do inheritance as users expect; but at the same time it is one of its core features.
Tags
- failed to deliver on expectations
- should be changed
- tree structure
- important point
- inheritance (programming)
- I agree
- JSON Schema: problem: can't use additionalProperties with allOf to make a union
- JSON Schema: additionalProperties: can't see the properties inside of an allOf
- unfortunate
- unmet expectations
- JSON Schema: additionalProperties
- expected behavior
- JSON Schema
- local
Annotators
URL
-
-
github.com github.com
-
unevaluatedProperties is like additionalProperties, except that it can "see through" $ref and "see inside" allOf, anyOf, oneOf, if, then, else
-
I think the answer lies here: Cant see into oneOf or allOf etc. This, I think, is the distinguishing difference between additionalProperties and unevaluatedProperties.
-
However, unevaluatedProperties has dynamic behavior, meaning that the set of properties to which it applies cannot be determined from static analysis of the schema (either the immediate schema object or any subschemas of that object).
annotation meta: may need new tag:
dynamic behavior vs. static analysis [not quite parallel]
or can we reuse something else like?: lexical semantics vs. run-time semantics
-
unevaluatedProperties is similar to additionalProperties in that it has a single subschema, and it applies that subschema to instance properties that are not a member of some set.
-
Tags
- JSON Schema: oneOf/allOf
- distinguishing difference
- JSON Schema: problem: can't use additionalProperties with allOf to make a union
- JSON Schema: additionalProperties: can't see the properties inside of an allOf
- JSON Schema: unevaluatedProperties
- dynamic behavior
- similar but different
- static analysis
- important distinction
- aha moment
Annotators
URL
-
-
-
Also, some Specification constraints cannot be represented with the JSON Schema so it's highly recommended to employ other methods to ensure compliance.
-
-
stackoverflow.com stackoverflow.com
-
What I want is to use "additionalProperties: false" to validate a union of schemas, but it seems it isn't possible. I already tried with sevaral different combination, but I didn't make it works.
-
additionalProperties: false works on it, but not along with allOf, because only validate one schema or another.
-
-
-
allOf takes an array of object definitions that are validated independently but together compose a single object.
-
-
github.com github.com
-
The latest (draft 2020-12) version of JSON Schema supports the unevaluatedProperties vocabulary (see here). This is quite a useful feature, and facilitates stricter validation while composing properties from multiple sub-schemas (using e.g. allOf) than would otherwise possible.
-
OAS 3.1 uses all of JSON Schema draft 2020-12 including unevaluatedProperties. You won't find direct references to unevealuatedProperties in the OAS spec because it links to the JSON Schema spec instead of duplicating it's contents.
-
-
-
This object is a superset of the JSON Schema Specification Draft 2020-12.
-
-
gist.github.com gist.github.com
-
linked from: https://github.com/json-schema-org/json-schema-spec/issues/515#issuecomment-369842228
refactored using:
-
-
github.com github.com
-
JSON Schema allows for additionalProperties both a boolean or an object value. 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).
-