I'm trying to build a JSON schema (draft-06) for an existing JSON data file. The schema has gotten to big to fit in a single file and I am trying to break it up into multiple files. However I keep getting the error can't resovle refrence sectionTableSchema.txt from id http://somesite/section
I've made the following files and placed them in the same directory. These files are not hosted on a webserver.
settingsSchema.txt:
{
"title":"Settings",
"$schema":"http://json-schema.org/draft-06/schema#",
"$id":"http://somesite/settingsSchema.txt",
"properties":{
"section":{
...
...
...
"$id":"/section",
"items":{
"oneOf":[
{"$ref":"#/sectionTableSchema.txt"},
{"$ref":"#/sectionNonTableSchema.txt"}
]
},
"type":"array"
}
},
"type":"object"
}
sectionTableSchema.txt
{
"$schema":"http://json-schema.org/draft-06/schema#",
"$id":"http://somesite/sectionTableSchema.txt",
"definitions":{},
"properties":{
....
....
....
}
"type":"object"
}
I think part of my issue is that I don't understand the $id and $ref keywords enough to know what is going on between absolute uri, relative uri, json-pointers and the like.
What happens?
In the OP's example "$ref":"#/sectionTableSchema.txt" means "inside current schema file, get JSON property called sectionTableSchema.txt from root element".
How $ref works?
$ref can be presented in two parts:
Before "#" sign you can specify URI (in simple words, a path) of schema file. If you start $ref from "#" sign and, therefore, don't provide URI of schema file, this means you want to take schemas from current file.
After "#" sign you can provide a JSON pointer, e. g. a path to the property in JSON that is located in specified file (or current file, depending on provided schema URI before "#" sign).
The same information can be found in documentation.
How to reference other file correctly?
As I understand, JSON Schema drafts say you can specify a valid URI to schema file. But URIs cannot be relative, so there is no standard-defined way of referencing files with relative paths. However, in practice a lot of tools provide abilities to do this, though they are not a part of the standard and may differ from tool to tool.
In AJV you can write your reference as "$ref":"ANY-ID-YOU-WANT" and use ajv.addSchema(schemaJson, 'ANY-ID-YOU-WANT') method, where schemaJson is a variable with require'd sectionTableSchema.txt content.
Related
My goal is simple: I want to know what schema describes the given json file, meaning I need to mark it somehow. Example:
{
"Id": 100,
"name": "example"
}
What is not clear from the example below is what schema definition describes it, in other words what are the required fields and what are the other fields available in it.
I'm looking not only for validation, but rather ease-of-work with this jsonn file. For example, I'd like to use it as a configuration file. I need to know what properties are available and what properties are mandatory.
I'm looking for something like this:
{
"$schemaDefinition": "URL to the schema definition",
"Id": 100,
"name": "example"
}
What I don't know is what is the valid way doing it. I read through back and forth the json-schema.org but it doesn't discusses this. However, I remember I saw this solution somewhere.
As a result, I hope..., editor can pick up the schema and provide intellisense. Or the poor person who is going to work with the json file (configure something) knows where to look for available and mandatory configuration properties.
I have found it.
{
"$schema": "URL to the schema definition",
"Id": 100,
"name": "example"
}
If the schema file is stored in Github you have to use the url to the raw content.
Jetbrains products can pick up the schema definition without any problem.
I've stumbled upon this problem and after doing a bit of research here I am.
I have a json file which I want to validate against *Json-Schema. Now most of the libraries developed for this purpose in java, which are listed here, do a great a job in validating the file and provide well formatted reasons for it. But there's no feature of removing the invalid records completely. I tried ever-it/org package and couldn't find anything that pertains to the requirement.
For example if I'm having array inside a json object then its possible for one of the array elements to be invalid and the same I want to remove.
{ "key1" : "value1",
"key2" : [
{
"key3":"temp",
"key4":12
},
{ --> this object invalid for some reason hence should be removed
"key3":"temp",
"key4":"dsds"
},
{
"key3":"temp",
"key4":"anything"
}
]
}
Except Of Course manually removing the invalid records/objects from file by tracking the object from start with the help of error messages upon validation, Is there any already implemented solution for this?
*Json-Schema : It is basically a standard way of representing the data format and its structure for json files. There are few versions in it, draft-07 and draft-06 for instance. Read more about it here.
In any xml file i can say what namespace I refer to using xmlns-attributes to describe the namespace. It is well descibed here: What does "xmlns" in XML mean?
Then I can use a xml schema having a target namespace so that everyone knows that the schema describes that namespace. One question about that is found here: Why do we need targetNamespace?
Using json-schema we can define schemas for json documents. My mental model is that this is roughly equivalent to having a xsd file.
Now, how do I reference the schema in a json object? I can reference a schema using $schema attribute, but how do I declare the name of the schema i develop myself? I dont understand the equivalent of targetNamespace
Researching for writing the question I found the answer. The closest thing of a targetNamespace is the $id attribute. The standard states...
The "$id" keyword defines a URI for the schema, and the base URI that
other URI references within the schema are resolved against. A
subschema's "$id" is resolved against the base URI of its parent
schema. If no parent sets an explicit base with "$id", the base URI is
that of the entire document, as determined per RFC 3986 section 5
[RFC3986].
... which is kind of the mirror image of the leading text for $schema...
The "$schema" keyword is both used as a JSON Schema version identifier
and the location of a resource which is itself a JSON Schema, which
describes any schema written for this particular version. The value
of this keyword MUST be a URI [RFC3986] (containing a scheme) and this
URI MUST be normalized. The current schema MUST be valid against the
meta-schema identified by this URI.
so it is essentially the same thing.
Some things to note, however:
a) you use $schema in a schema to define what schema should be used for defining your own custom schema. It is not stated in the spec that $schema in any kind of object should indicate validation for a schema.
b) You may define in your schema that $schema should be an indication about what schema to use for validation.
c) there are other ways to indicate the schema for data. One such example is using content-type in http headers. Another is to use link http headers.
d) vscode and visual studio both interpret $schema as a reference to a schema for use in validation
The issue has been discussed at the github repo for the spec.
https://github.com/json-schema/json-schema/issues/235
https://github.com/json-schema/json-schema/issues/220#issuecomment-209452992
The BizTalk decoder pipeline component displays values of RootNode and RootNodeNamespace in the configuration of the pipeline (in BizTalk Admin Console).
When I don't specify the root, it blows up and says:
"Reason: Root node name is not specifed in Json decoder properties"
When I do specify a root, it gets added. But why does it need to add a root if I have a "root" in my JSON?
Example JSON:
{ "AppRequest": {
"DocumentName": "whatever",
"Source": "whatever"
}
}
So I would like to use the JSON above, and have a schema with a root of "AppRequest". But if I drop a file with this JSON, and specify AppRequest as the Root, then I get an extra AppRequest wrapper around the AppRequest I already have.
To me this is odd behavior, if you want to have a schema/contract first approach. I might agree on the JSON with my trading partner, then later build the schema in BizTalk; and now I'm locked in to a schema with a root, and an element under it with the same name again.
Further, the person building the JSON is probably deserializing a class, so the class name will be the "root" of that JSON file.
Yes, I could write my own decoder pipeline components ... just trying to figure out why they did it the way they did it, or if I missing something obvious.
Yes, a root node and namespace is required by the JSON Decoder.
There is a reason for this. JSON does not require the equivalent of a root node while XML does require a root node. Making it a required property eliminates any ambiguity about the conversion. It's just that simple.
Since you will typically need to use the XML Disassembler also, you can strip the JSON Encoder added rood node by essentially Debatching the content with an Envelope Schema matching the JSON Encoder root node. You can remove the Xml Namespace as well which is also a good idea.
What is the standard outcome of the following 'remove' JSON Patch with an empty "" path?
[{ "op": "remove", "path": ""}]
Should it clear the whole object, equal to assigning {}? In http://jsonpatch.com/ it says: To point to the root of the document use an empty string for the pointer. So I guess a 'remove' on the root removes the whole object, right?
I tried it with two different JSON Patch libraries with two different results:
https://github.com/java-json-tools/json-patch: deletes the whole object
https://github.com/gnieh/diffson: throws an JsResultException
What is the officially accepted, standard outcome of this? I checked in the RFC for the JSON Patch (https://www.rfc-editor.org/rfc/rfc6902) but couldn't find anything.
RFC 6902 references this for further error handling: https://www.rfc-editor.org/rfc/rfc5789#section-2.2
And to me, this part seems to fit the bill:
Resource not found: Can be specified with a 404 (Not Found) status
code when the client attempted to apply a patch document to a non-
existent resource, but the patch document chosen cannot be applied
to a non-existent resource.
Since you basically did not define any resource - not even / which would more clearly refer to the root / the entire object.
I guess the difference in the two libraries comes from that these two are usually considered identical:
/my/resource
/my/resource/
But usually the non-/ path would be automatically 301 Redirected to the path that does have /. So I would personally go with the 404 response for "path": ""