What is the difference between "anyof" and "oneof" in z schema? - json

Its looking like both works fine with my input validation code. Then what is the exact difference?
Schema with oneof
[{
"id": "MyAction",
"oneOf": [{ "$ref": "A1" },
{ "$ref": "A2" }]
},
{
"id": "A1",
"properties": {
"class1": { "type": "string"},
"class2": { "type": "string"}
}
},
{
"id": "A2",
"properties": {
"class2": { "type": "string"},
"class3": { "type": "string"}
}
}
]
Schema with anyof
[{
"id": "MyAction",
"anyOf": [{ "$ref": "A1" },
{ "$ref": "A2" }]
},
{
"id": "A1",
"properties": {
"class1": { "type": "string"},
"class2": { "type": "string"}
}
},
{
"id": "A2",
"properties": {
"class2": { "type": "string"},
"class3": { "type": "string"}
}
}
]

If you look at the JSON Schema documentation, it says:
anyOf:
...
An instance validates successfully against this keyword if it
validates successfully against at least one schema defined by this
keyword's value. Note that when annotations are being collected, all
subschemas MUST be examined so that annotations are collected from
each subschema that validates successfully.
oneOf:
...
An instance validates successfully against this keyword if it
validates successfully against exactly one schema defined by this
keyword's value.
Note my emphasis in the above. anyOf means the item must validate against at least one (but possibly more than one) of the schemas. oneOf means it must validate against only one of the schemas.

I am late in the quest but as per my understanding the usage of this keyword depends on the type of the object/parent itself. for example if you are trying to define the type for a single property of the object or the element of an array. take the below example :
{
"title": "Sample JSON Schema",
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"definitions": {
"propObjectType1" : {
"name": "string",
"age": "number"
},
"propObjectType2" : {
"name": "string",
"dob": {
"type": "string",
"pattern": "\\d\\d\/\\d\\d\/\\d\\d\\d\\d"
}
}
},
"properties": {
"prop1": {
"type": "string",
"maxLength": 64
},
"prop2": {
"anyOf": [
{
"$ref": "#/definitions/propObjectType1"
},
{
"$ref": "#/definitions/propObjectType2"
}
]
},
"prop3": {
"oneOf": [
{
"$ref": "#/definitions/propObjectType1"
},
{
"$ref": "#/definitions/propObjectType2"
}
]
},
"prop4Array": {
"type": "array",
"items": {
"oneOf": [
{
"$ref": "#/definitions/propObjectType1"
},
{
"$ref": "#/definitions/propObjectType2"
}
]
}
},
"prop5Array": {
"type": "array",
"items": {
"anyOf": [
{
"$ref": "#/definitions/propObjectType1"
},
{
"$ref": "#/definitions/propObjectType2"
}
]
}
}
}
}
So in the above definition the prop2 and prop3 are the same (you can use interchangeably anyOf or oneOf) and you can define what ever you are comfortable with. but, in case of array:
when you use anyOf for the items type, the elements can be of any type out of those and the array can contain the mixed items. Means you can have one item of type 1 and another item of type 2.
when you use oneOf for the items type, the elements can be of any type out of those and the array can contain only one type of items. Means all the items must be of the same type (either type 1 or type 2).

Related

How do I inform a Json schema that it must have atleast one type of object in its Array, but other types are optional

I am working on updating a JSON schema for work.
For the json array, we have
"accountsInfo": [{
"type":"ADMIN",
"firstName":"Bill",
"lastName":"Cipher",
"emailAddress":"bcipher#gfalls.com"
}, {
"type":"USER"
"firstName":"Bugs",
"lastName":"Bunny",
"emailAddress":"whats#updoc.org"
}]
The USER type is needs to be optional for this schema, with the atleast 1 ADMIN type is required in the array. How can I do this?
Here is the portion of the schema file. It is using Json Schema 7.
"accountsInfo": {
"type": "array",
"uniqueItems": true,
"minItems": 2,
"items": [
{
"type": "object",
"required": [
"type",
"firstName",
"lastName",
"emailAddress"
],
"properties": {
"type": {
"type": "string",
"enum": [
"ADMIN",
"USER"
]
},
"firstName": {
"type": "string",
"$ref": "#/definitions/non-empty-string"
},
"lastName": {
"type": "string",
"$ref": "#/definitions/non-empty-string"
},
"emailAddress": {
"type": "string",
"format": "email"
}
}
}
]
}
You can use the "contains" keyword for this. In pseudocode: "the array must contain (at least one) item that successfully evaluates against this schema".
As a sibling keyword to "type": "object" and "items": { ... }, add:
"contains": {
"properties": {
"type": {
"const": "ADMIN"
}
}
}
Also, you have an error in your "items" keyword: if you intend for that subschema to match all items, not just the first, remove the extra array around the schema. The array form of "items" matches each item in the data against each item in the schema in turn, and you only specify a schema for the first item, so all items after the first can be anything.
"items": { .. schema .. } not "items": [ { .. schema .. } ].
If using the contains keyword as suggested, and if you are using strict mode, you may need to add "type": "array" like this:
{
"type": "array",
"contains": {
"properties": {
"type": {
"const": "ADMIN"
}
}
}
}

JSON Schema property's properties depend on the value of another property [duplicate]

Within a JSON structure (“event bundle”), I am collecting several lists of events. These are called event lists. Each event in that list has at least a type field, whose value is dependent on which list it is stored in. Consider the following valid example:
{
"event_bundle": {
"alert_events": [
{ "type": "fooAlert1", "value": "bar" },
{ "type": "fooAlert2", "value": "bar" },
{ "type": "fooAlert3", "value": "bar" }
],
"user_events": [
{ "type": "fooUser1", "value": "bar" },
{ "type": "fooUser2", "value": "bar" },
{ "type": "fooUser3", "value": "bar" }
]
}
}
Here, alert_events can only contain events whose types are fooAlert1, fooAlert2 and fooAlert3, not others. The same goes for user_events. So, this JSON would not be valid:
{
"event_bundle": {
"alert_events": [
{ "type": "fooAlert1", "value": "bar" },
{ "type": "fooUser2", "value": "bar" },
{ "type": "foo", "value": "bar" }
],
"user_events": [
{ "type": "fooAlert1", "value": "bar" },
{ "type": "fooUser2", "value": "bar" },
{ "type": "foo", "value": "bar" }
]
}
}
It's invalid, since fooUser2 cannot appear in an event that is in an alert_events list, and fooAlert1 cannot appear in the user_events. Also, the event foo is not valid at all.
I currently have the following simple schema:
{
"type": "object",
"definitions": {
"event_list": {
"type": "array",
"items": {
"$ref": "#/definitions/event"
}
},
"event": {
"type": "object",
"required": ["type", "value"],
"properties": {
"type": { "type": "string" },
"value": { "type": ["string", "object"] },
"source": { "type": ["string", "null"] }
}
}
},
"properties": {
"event_bundle": {
"type": "object",
"properties": {
"alert_events": {
"$ref": "#/definitions/event_list"
},
"user_events": {
"$ref": "#/definitions/event_list"
}
}
}
}
}
However, this does not fully validate the allowable types.
I know I could define different event_lists with different events, but that would mean I'd have to define potentially dozens of lists and events.
Is there an easier way to say, I want to validate that event objects in an alert_events list can have one set of types, and for another list another set of types?
You cannot reference and use instance data as values in your validation.
What you are asking is business logic, and not to do with the "shape" of your JSON data, which is the remit of JSON Schema.
You would need to implement this as your application logic.

JSON Schema validating JSON with different property names

I am working with JSON Schema Draft 4 and am experiencing an issue I can't quite get my head around. Within the schema below you'll see an array, metricsGroups where any item should equal exactly oneOf the defined sub-schemas. Within the sub-schemas you'll notice that they both share the property name timestamp, but metricsGroupOne has the properties temperature and humidity whilst metricsGroupTwo has properties PIR and CO2. All properties within both metricsGroups are required.
Please see the schema below. Below the schema is an example of some data that I'd expect to be validated, but instead is deemed invalid and an explanation of my issue.
{
"type": "object",
"properties": {
"uniqueId": {
"type": "string"
},
"metricsGroups": {
"type": "array",
"minItems": 1,
"items": {
"oneOf": [
{
"type": "object",
"properties": {
"metricsGroupOne": {
"type": "array",
"minItems": 1,
"items": {
"type": "object",
"properties": {
"timestamp": {
"type": "string",
"format": "date-time"
},
"temperature": {
"type": "number"
},
"humidity": {
"type": "array",
"items": {
"type": "number"
}
}
},
"additionalProperties": false,
"required": [
"timestamp",
"temperature",
"humidity"
]
}
}
},
"required": [
"metricsGroupOne"
]
},
{
"type": "object",
"properties": {
"metricsGroupTwo": {
"type": "array",
"minItems": 1,
"items": {
"type": "object",
"properties": {
"timestamp": {
"type": "string",
"format": "date-time"
},
"PIR": {
"type": "array",
"items": {
"type": "number"
}
},
"CO2": {
"type": "number"
}
},
"additionalProperties": false,
"required": [
"timestamp",
"PIR",
"CO2"
]
}
}
},
"required": [
"metricsGroupTwo"
]
}
]
}
}
},
"additionalProperties": false,
"required": [
"uniqueId",
"metricsGroups"
]
}
Here's some data that I believe should be valid:
{
"uniqueId": "d3-52-f8-a1-89-ee",
"metricsGroups": [
{
"metricsGroupOne": [
{"timestamp": "2020-03-04T12:34:00Z", "temperature": 32.5, "humidity": [45.0] }
],
"metricsGroupTwo": [
{"timestamp": "2020-03-04T12:34:00Z", "PIR": [16, 20, 7], "CO2": 653.76 }
]
}
]
}
The issue I am facing is that both of the metricsGroup arrays in my believed to be valid data validate against both of the sub-schemas - this then invalidates the data due to the use of the oneOf keyword. I don't understand how the entry for metricsGroupOne validates against the schema for metricsGroupTwo as the property names differ and vice versa.
I'm using an node library under the hood that throws this error, but I've also tested that the same error occurs on some online validation testing websites:
jsonschemavalidator
json-schema-validator
Any help is appreciated. Thanks,
Adam
JSON Schema uses a constraints based approach. If you don't define something is not allowed, it is allowed.
What's happening here is, you haven't specificed in oneOf[1] anything which would make the first item in your instance data array invalid.
Lete me illistrate this with a simple example.
My schema. I'm going to use draft-07, but there's no difference in this principal for draft-04
{
"oneOf": [
{
"properties": {
"a": true
}
},
{
"properties": {
"b": false
}
}
]
}
And my instance:
{
"a": 1
}
This fails validation because the instance is valid when both oneOf schemas are applied.
Demo: https://jsonschema.dev/s/EfUc4
If the instance was in stead...
{
"a": 1,
"b": 1
}
This would be valid, because the instance is fails validation for the subschema oneOf[1].
If the instance was...
{
"b": 1
}
It would be valid according to oneOf[0] but not according to oneOf[1], and therefore overall would be valid because it is only valid according to one subschema.
In your case, you probably need to use additionalProperties to make properties you haven't defined in properties dissallowed. I can't tell from your question if you want to allow both properties, because your schema is defined as oneOf which seems to conflict with the instance you expect to be valid.

How to describe this validation requirement in jsonschema?

I want to validate my API json response like this:
{
"code": 0,
"results": [
{"type":1, "abc": 123},
{"type":2, "def": 456}
]
}
I want to validate the objects within results to have a "abc" field when its type is 1, and "def" field when its type is 2. The results may contain arbitrary number of type1 and type2 objects.
Can I specify this in jsonschema? Or must I use a generic validator for elements in results and do validation myself?
You can do this using the anyOf keyword.
An instance validates successfully against this keyword if it validates successfully against at least one schema defined by this keyword's value.
http://json-schema.org/latest/json-schema-validation.html#anchor85
You need to define both types of items and then use anyOf To describe the array items for "results".
{
"type": "object",
"properties": {
"code": { "type": "integer" },
"results": {
"type": "array",
"items": { "$ref": "#/definitions/resultItems" }
}
},
"definitions": {
"resultItems": {
"type": "object",
"anyOf": [
{ "$ref": "#/definitions/type1" },
{ "$ref": "#/definitions/type2" }
]
},
"type1": {
"properties": {
"type": { "enum": [1] },
"abc": { "type": "integer" }
},
"required": ["abc"]
},
"type2": {
"properties": {
"type": { "enum": [2] },
"def": { "type": "integer" }
},
"required": ["def"]
}
}
}

A common JSON Schema for similar structure

I'm completely new to json and json schema, so I have a question (yet I don't know how much it make sense). Can we create a json schema which is common for similar type of structure. For example:
One single schema can be used to validate following json
JSON:
{
"Team_Table":
[{"Name":"New Zealand", "Match":"Six", "Won":"Six"}]
}
And
{
"Story_Taller":
[{"Story":"No Name", "Chapter":"Don't know"}]
}
Similarities:
Both have only one object in the array
Objects have string value.
Dissimilarities:
Number of properties are different
Keys are different in both
Can we do this?
Maybe this helps you along:
{
"properties": {
"Story_Taller": {
"type": "array",
"maxItems": 1,
"items": {
"properties": {
"Chapter": {
"type": "string"
},
"Story": {
"type": "string"
}
},
"additionalProperties": false
}
},
"Team_Table": {
"type": "array",
"maxItems": 1,
"items": {
"properties": {
"Name": {
"type": "string"
},
"Match": {
"type": "string"
},
"Won": {
"type": "string"
}
},
"additionalProperties": false
}
}
},
"oneOf": [
{
"title": "Story_Taller",
"required": [
"Story_Taller"
]
},
{
"title": "Team_Table",
"required": [
"Team_Table"
]
}
]
}
in (short) words:
in your JSON there must be one property of either "Story_Taller" or "Team_Table" with a maximum of 1 item
"oneOf": [ ... ]
Properties of both arrays are defined by items
"Story_Taller" must have "Chapter" and "Story" and no additional properties.
"Team_Table" must have "Name", "Match", "Won" and no additional properties.
And all of them are defined as strings.