You may use jsonSchemaLint for testing purposes.
I have this JsonSchema, which sets format as "full-date". All Draft-6 validators (Json.Net) accepts the schema as valid.
{
"title": "MyTestSchema",
"type": "object",
"properties": {
"MyDateValue": {
"type": "string",
"format": "full-date",
"description": "We expect yyyy-MM-dd"
}
}
}
But it is unable to identify this Json object is wrong:
{
"MyDateValue": "2017-10-1"
}
When I switch the schema from "full-date" to "date" only, it works:
{
"title": "MyTestSchema",
"type": "object",
"properties": {
"MyDateValue": {
"type": "string",
"format": "date",
"description": "We expect yyyy-MM-dd"
}
}
}
Is the one on the top ("full-date") correct term as Json rules? Please refer some documentation.
The value should be date and not full-date please refer
this documentation
Following are the valid values
date-time : This SHOULD be a date in ISO 8601 format of YYYY-MM-
DDThh:mm:ssZ in UTC time. This is the recommended form of date/
timestamp.
date : This SHOULD be a date in the format of YYYY-MM-DD. It is
recommended that you use the "date-time" format instead of "date"
unless you need to transfer only the date part.
time : This SHOULD be a time in the format of hh:mm:ss. It is
recommended that you use the "date-time" format instead of "time"
unless you need to transfer only the time part.
utc-millisec : This SHOULD be the difference, measured in
milliseconds, between the specified time and midnight, 00:00 of
January 1, 1970 UTC. The value SHOULD be a number (integer or
float).
source : here
Referring to this issue on github here, turns out it was ok to create your own schema code, with the knowledge that the validators might not be able to capture it.
"It's technically always correct because format is extensible. However, user-defined formats will be ignored by validators that don't recognize them. And of course, if someone else is using a validator that they have configured to recognize the same name but treat it differently, then you will have an interoperability problem. However, with this particular value, full-date, it depends on your version of JSON Schema.
In draft-04 or draft-06, full-date is not an official format. Although anyone who adds it as a custom format and does not have it mean the same thing it means in RFC 3339 is asking for trouble, so you're probably fine using it this way even in those versions.
In the forthcoming (next week? hopefully?) draft-07, full-date is part of the reserved RFC 3339 format namespace, and if implemented, MUST be compatible with RFC 3339's definition of full-date. draft-07 also defines date as a synonym for full-date and recommends using it instead, as date is more common in the wild as far as I know.
Either way, this usage you're showing here is probably pretty safe since it matches RFC 3339, and as of draft-07 the standard does not enforce support but does enforce that, if implemented, it must behave as expected by RFC 3339."
Related
I'm converting date columns from an internal date/time format to something Vega-Lite can parse, and am uncertain what my target should be. In version 4, there was a date time definition object, that went something like this {"year": 2006, "month": "jan", "date": 1}, and I seem to remember that working. However some recent plots fail silently when I do that, and I seem to need to use ISO-8601 string formats.
What's the proper way to encode a date and time column in version 5?
You can specify a format object with a parse property to parse your dates in whatever format they're in.
https://vega.github.io/vega-lite/docs/data.html
Specific date formats can be provided (e.g., {foo: "date:'%m%d%Y'"}),
using the d3-time-format syntax.
To be able to deserialize polymorphic types, I use a type discriminator across many of my JSON objects. E.g., { "$type": "SomeType", "otherProperties": "..." }
For the JSON schemas of concrete types, I specify a const value for type.
{
"type": "object",
"properties": {
"$type": { "const": "SomeType" },
"otherProperties": { "type": "string" }
}
}
This works, but distributes the chosen "$type" property name throughout many different JSON schemas. In fact, we are considering renaming it to "__type" to play more nicely with BSON.
Could I have prevented having to rename this property in all affected schemas?
I tried searching for a way to load the property name from elsewhere. As far as I can tell $ref only works for property values.
JSON Schema has no ability to dynamically load in key values from other location like you are asking. Specifically because the value will be different, and you want only the key to be loaded from elsewhere.
While you can't do this with JSON Schema, you could use a templating tool such as Jsonnet. I've seen this work well at scale.
This would require you have a pre-processing step, but it sounds like that's something you're planning for already, creating some sort of pipeline to generate your schemas.
A word of warning, watch out for existing schema generation tooling. It is often only good for scaffolding, and requires lots of modifications. It sounds like you're building your own, which is likely a better approach.
I am trying to store decimal numbers with restricted number of decimal places in my JSON data, and initially, I wanted to do it using strings. However, the schema does not support this. So as of right now, I am restricted to using this:
{"type": "number", "multipleOf" : 0.1} <- 1 decimal place
{"type": "number", "multipleOf" : 0.01} <- 2 decimal places
This works fine in dev, but I know from first hand experience how quickly floats can break down in actual applications. So my first choice is still finding some way to store them as strings in my data. Is this possible with the current implementation of JSON Schema?
This is not something that is possible with JSON Schema for numbers.
If you can represent your number as a string, you can use regex in the JSON Schema to check this sort of thing.
Look up the pattern key word.
As per the previous answer, If you are happy to represent the number as a string, you can use a regex pattern.
The below will restrict a number to 15sf (potentially useful if you are concerned about floating point expressibility):
{
"type": "string",
"pattern": "^(?!(?:.*?[1-9]){15,})([-+]?\\s*\\d+\\.?\\d*?)$"
}
I have a number of requests types I might be sent.
There's a request-type property that may have values "add", "update", "delete" (for example).
Depending on the request type, I will get different properties
If the request type is "add", then I will get additional propertie "add-red", "add-blue", "foo" for example
If the request type is "update,, then "update-xxx", "update-yyy", "update-xxx"
and if "delete" then "foo", "bar"...
Note that some additional properties could appear for more than one request type (see "foo" in the above example)
So I want to validate differently depending on the value of "request-type".
I tried to to
"oneOf": [
{
...
"properties": { "request-type" : { "enum": ["add"] }
"add-red": { ...}
}
},
{
...
"properties": { "request-type" : { "enum": ["update"] }
"update-xxx": { ...}
}
}
In the hope that the validator would match the value of the first when deciding which of the "oneOf" would be selected.
This appears itself to be "valid" (in that the VS Code validator thinks it's a valid schema) but doesn't do what I want - it seems when I write the corresponding JSON it always matches the first, and will only accept "add" as its value).
So how should I do this? I can define the JSON format here, so I can require the use of something I can validate somehow.
It's nearly a duplicate of this: JSON schema anyOf validation based on one of properties except I think the answer there requires distinct sets of additional properties for each request type.
EDIT: According to the answer to validation of json schema having oneOf keyword
it looks like my approach should work so maybe this is just a limitation of the intellisense in MS VS Code?
EDIT2: And this gives another approach: writing more complex json schemas that have dependencies upon other keys
I'll have to experiment some more and maybe end up deleting this!
Answering my own question - the approach of the question works fine. Using a validator like http://www.jsonschemavalidator.net/, I get the behaviour I expect.
It's just that Visual Studio Code's intellisense can't interpret it in a way that means it can provide useful guidance (and to be fair, it's a difficult problem as it means partially matching all the of the alternatives in the "oneOf" to see which ones might still be valid)
Im trying to use json-schema validation at some project, and want to ask about the "required" field.
In current doc there is a specifiaction:
The value of this keyword MUST be an array. This array MUST have at least one element. Elements of this array MUST be strings, and MUST be unique.
But in another examples in the web, i can find something like:
"properties": {
"foo": {
"required": true
}
}
What is a valid way to define required fields?
In version 3 of JSON Schema it was a boolean.
In the latest version, 4, it is now an array of strings.
The validator you are using may still be implementing the old specification.