In my json schema file i'm trying to force a reference property, $ref onto the user. However, the following does not work
-- sampleSchema.json --
{
"definitions": {
"items": {
"type": "object",
"properties": {
"ref": {
"type": "string"
}
}
}
},
"properties": {
"items" : {
"$ref": "#/definitions/items"
}
}
}
The desired output is this where the user must provide a reference path.
-- whatever.json --
{
"$schema" : "sampleSchema.json?reload",
"items": {
"$ref": "/myEntityReferenceOfChoice"
}
}
In in schema file if i leave the $ in , then it doesn't work. If i take it out for just 'ref' it does. Can i force the user to supply a $ref?
Im using Visual Studio 2013..
Related
I want to create several json schemas for different scenarios.
For scenario 1 I would like to specify that:
a) The property "draftenabled" must have the value true.
b) the property "draftenabled" does exist.
I have checked this post
Validating Mandatory String values in JSON Schema
and tried the following
I tried to validate this json
{
"$schema": "./test-schema.json",
"draftenabled": false,
"prefix": "hugo"
}
with this schema test-schema.json that I had created in Visual Studio Code.
{
"$schema": "http://json-schema.org/draft-04/schema#",
"properties": {
"$schema": {
"type": "string"
},
"draftenabled": {
"type": "boolean"
},
"prefix": {
"type": "string"
}
},
"additionalItems": false,
"contains": {
"properties": {
"draftenabled": {
"const": true
}
},
"required": [
"draftenabled"
]
}
}
I would have expected an error since the value for draftenabled is false rather than true.
It looks like there is some confusion around how the keywords apply to instances (data) of different types.
properties only applies to objects
additionalItems and contains only apply to arrays
Since your instance is an object, additionalItems and contains will be ignored.
Based on your description of what you want, I would do something like the following:
{
"$schema": "http://json-schema.org/draft-04/schema#",
"properties": {
"$schema": {
"type": "string"
},
"draftenabled": {
"const": "true"
},
"prefix": {
"type": "string"
}
},
"required": [
"draftenabled"
]
}
This moves the definitions you have in the contains into the main schema. You got that bit right, just in the wrong place.
You also mention that this is a "scenario 1." If there are other scenarios, I suggest creating schemas like this for each scenario then wrapping all of them together in a oneOf or anyOf:
{
"oneOf": [
{ <scenario 1> },
{ <scenario 2> },
...
]
}
I was looking around the docs and couldn't find any direct or indirect solution.
Is there any way to get validation on JSON objects without knowing exactly where the specific object is located?
For example, I want to validate the following sub-object:
{
"grandParent": {
"parent": {
"child": {
"name": "John"
}
}
}
}
The object can be part of a larger JSON file the can be structured as follows:
{
"root": {
"someKey": {
"grandParent": ...
},
"grandParent": ...,
...<go in even deeper>: {
"grandParent": ...
}
}
}
Can I create a json schema that validates the object no matter where it is?
Similar example in glob would be: root.**.grandParent.parent.child
You'll need to use a combination of additionalProperties, items, and recursive references.
First, we define the structure you want to validate. You have to define properties for each layer of the object.
Next, you want your root level to reference that definition. Because you're using pre draft 2019-09, you'll need to wrap that reference in an allOf.
Then you want to make sure that for objects, the values have the root schema applied, and for arrays, each item has the root schema applied.
The use of "$ref": "#" resolves to the root of the schema, which creates the cyclical reference.
Some implementations may not like this, but most should be able to handle it.
Here's a live demo of the below schema: https://jsonschema.dev/s/lBrZk
{
"$schema": "http://json-schema.org/draft-07/schema",
"definitions": {
"grandParentToChild": {
"properties": {
"grandParent": {
"properties": {
"parent": {
"properties": {
"child": {
"properties": {
"name": {
"type": "string"
}
}
}
}
}
}
}
}
}
},
"allOf": [
{
"$ref": "#/definitions/grandParentToChild"
}
],
"additionalProperties": {
"$ref": "#"
},
"items": {
"$ref": "#"
}
}
Given the following JSON object, how can I build json schema? Product1, Product2 and Product3 are dynamic "keys" and I could have many more like that, but each of them will have the same "value" object with required keys as packageId1, packageId2, packageId3 and their corresponding values as strings.
{
"Product1": {
"packageId1": "basicpackage",
"packageId2": "basicpackage",
"packageId3": "basicpackage"
},
"Product2": {
"packageId1": "newpackage",
"packageId2": "newpackage",
"packageId3": "newpackage"
},
"Product3": {
"packageId1": "thirdpackage",
"packageId2": "thirdpackage",
"packageId3": "thirdpackage"
}
}
I think I figured how to do it. In case anyone is interested, I am answering my own question. Also, I welcome better suggestions.
{
"title": "JSON Schema for Fulfillment Config",
"$schema": "http://json-schema.org/draft-04/schema#",
"type": "object",
"patternProperties": {
".{1,}": {
"type": "object",
"properties": {
"packageId1": { "type": "string" },
"packageId2": { "type": "string" },
"packageId3": { "type": "string" }
}
}
}
}
I have the following simple JSON schema that does the regular expression match based on the content field of my data:
{
"$schema":"http://json-schema.org/schema#",
"allOf":[
{
"properties":{
"content":{
"pattern":"some_regex"
}
}
}
}
It successfully matches the following data:
{
"content": "some_regex"
}
Now lets say I want to add a list of UUIDs to ignore to my data:
{
"content": "some_regex",
"ignoreIds" ["123", "456"]
}
The problem arises when I want to modify my schema not to match when a given value is present in the list of ignoreIds:
Here is my failed attempt:
{
"$schema": "http://json-schema.org/schema#",
"allOf": [{
"properties": {
"content": {
"pattern": "some_regex"
}
}
}, {
"properties": {
"ignoreIds": {
"not": {
// how do I say 'do not match if "123" is in the ignoreIds array'????
}
}
}
}]
}
Any help will be appreciated!
your JSON schema for the ignoreIds has to be:
"ignoreIds": {
"type": "array",
"items": {
"type": "integer",
"not": {
"enum": [131, 132, whatever numbers you want]
}
}
}
which says
any value in the array ignoreIds matching the not-enum will make the
json invalid
This works of course for an array of strings also:
"ignoreIds": {
"type": "array",
"items": {
"type": "string",
"not": {
"enum": ["131", "132"]
}
}
}
Tested with JSON Schema Lint
In a simple Elasticsearch mapping like this:
{
"personal_document": {
"analyzer": "standard",
"_timestamp": {
"enabled": true
},
"properties": {
"description": {
"type": "multi_field",
"fields": {
"sort": {
"type": "string",
"index": "not_analyzed"
},
"description": {
"type": "string",
"include_in_root": true
}
}
},
"my_nested": {
"type": "nested",
"include_in_root": true,
"properties": {
"description": {
"type": "string"
}
}
}
}
}
}
.... isn't "include_in_root": true supposed to add the field my_nested.description to the root document?
And during a query am I not supposed to see THAT field into the _source field?
and
Specifying an highlight directive on the field 'my_nested.description' would automatically retrieve the _included_in_root value_ instead of the nested field?
(something like this)
"highlight": {
"fields": {
"description": {},
"my_nested.description": {}
}
}
Or do I have some misunderstanding of the official nested type documentation?
(that is not really clear)
If the include_in_parent or include_in_root options are enabled on the nested documents then Elasticsearch internally indexes the data with nested fields flattened on the parent document. However, this is just internal for Elasticsearch and you'll never see them in the _source field.
If the user field is of type object, this document would be indexed
internally something like this...
as it is refered here.
Thus, you continue to perform actions (like the highlights that you mention) by referring to the nested document's fields. The highlight syntax that you refer to should look like this
"highlight": {
"fields": {
"my_nested.description": {}
}
}
and not
"highlight": {
"fields": {
"description": {}
}
}
You can use a wildcard for specifying highlight field:
POST /test-1/page/_search
{
"query": {
"query_string": {
"query": "Lorem ipsum"
}
},
"highlight" : {
"fields" : {
"*" : {}
}
}
}
If it's a good idea, I don't know. I guess it depends on your application.
This also works with nested documents, btw --- but seems to hickup when doing attachments on nested documents without include_in_root