docs: corrections
Evgeny Poberezkin
parent
05e2b38d67
commit
4687ed3465
|
|
@ -7,7 +7,7 @@ Thank you for your help making Ajv better! Every contribution is appreciated. If
|
|||
- [Bug reports](#bug-reports)
|
||||
- [Change proposals](#changes)
|
||||
- [Browser and compatibility issues](#compatibility)
|
||||
- [JSON schema standard](#json-schema)
|
||||
- [JSON Schema standard](#json-schema)
|
||||
- [Ajv usage questions](#usage)
|
||||
- [Code](#code)
|
||||
- [Development](#development)
|
||||
|
|
@ -33,7 +33,7 @@ Please make sure to include the following information in the issue:
|
|||
|
||||
1. What version of Ajv are you using? Does the issue happen if you use the latest version?
|
||||
2. Ajv options object (see https://github.com/epoberezkin/ajv#options).
|
||||
3. JSON schema and the data you are validating (please make it as small as possible to reproduce the issue).
|
||||
3. JSON Schema and the data you are validating (please make it as small as possible to reproduce the issue).
|
||||
4. Your code (please use `options`, `schema` and `data` as variables).
|
||||
5. Validation result, data AFTER validation, error messages.
|
||||
6. What results did you expect?
|
||||
|
|
@ -75,11 +75,9 @@ Please include this information:
|
|||
6. Results and error messages in your platform.
|
||||
|
||||
|
||||
#### <a name="json-schema"></a>Using JSON schema standard
|
||||
#### <a name="json-schema"></a>Using JSON Schema standard
|
||||
|
||||
Ajv implements JSON schema standard draft 4 and the proposed extensions for the next version of the standard (available when you use the option `v5: true`).
|
||||
|
||||
If the issue is related to using v5 extensions please submit it as a [bug report](https://github.com/epoberezkin/ajv/issues/new).
|
||||
Ajv implements JSON Schema standard draft-04 and draft-06/07.
|
||||
|
||||
If it is a general issue related to using the standard keywords included in JSON Schema or implementing some advanced validation logic please ask the question on [Stack Overflow](http://stackoverflow.com/questions/ask?tags=jsonschema,ajv) (my account is [esp](http://stackoverflow.com/users/1816503/esp)) or submitting the question to [JSON-Schema.org](https://github.com/json-schema-org/json-schema-spec/issues/new). Please mention @epoberezkin.
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ This way to define keywords is useful for:
|
|||
__Please note__: In cases when validation flow is different depending on the schema and you have to use `if`s, this way to define keywords will have worse performance than compiled keyword returning different validation functions depending on the schema.
|
||||
|
||||
|
||||
Example. `constant` keyword (a synonym for draft6 keyword `const`, it is equivalent to `enum` keyword with one item):
|
||||
Example. `constant` keyword (a synonym for draft-06 keyword `const`, it is equivalent to `enum` keyword with one item):
|
||||
|
||||
```javascript
|
||||
ajv.addKeyword('constant', {
|
||||
|
|
@ -88,7 +88,7 @@ The access to the parent data object and the current property name allow to crea
|
|||
|
||||
The function should return validation result as boolean. It can return an array of validation errors via `.errors` property of itself (otherwise a standard error will be used).
|
||||
|
||||
In some cases it is the best approach to define keywords, but it has the performance cost of an extra function call during validation. If keyword logic can be expressed via some other JSON-schema then `macro` keyword definition is more efficient (see below).
|
||||
In some cases it is the best approach to define keywords, but it has the performance cost of an extra function call during validation. If keyword logic can be expressed via some other JSON Schema then `macro` keyword definition is more efficient (see below).
|
||||
|
||||
All custom keywords types can have an optional `metaSchema` property in their definitions. It is a schema against which the value of keyword will be validated during schema compilation.
|
||||
|
||||
|
|
@ -134,7 +134,7 @@ See note on custom errors and asynchronous keywords in the previous section.
|
|||
|
||||
"Macro" function is called during schema compilation. It is passed schema, parent schema and [schema compilation context](#schema-compilation-context) and it should return another schema that will be applied to the data in addition to the original schema.
|
||||
|
||||
It is the most efficient approach (in cases when the keyword logic can be expressed with another JSON-schema) because it is usually easy to implement and there is no extra function call during validation.
|
||||
It is the most efficient approach (in cases when the keyword logic can be expressed with another JSON Schema) because it is usually easy to implement and there is no extra function call during validation.
|
||||
|
||||
In addition to the errors from the expanded schema macro keyword will add its own error in case validation fails.
|
||||
|
||||
|
|
|
|||
6
FAQ.md
6
FAQ.md
|
|
@ -29,7 +29,7 @@ No. In many cases there is a module responsible for the validation in the applic
|
|||
|
||||
Doing this would create a precedent where validated data is used in error messages, creating a vulnerability (e.g., when ajv is used to validate API data/parameters and error messages are logged).
|
||||
|
||||
Since the property name is already in the params object, in an application you can modify messages in any way you need. ajv-errors package will allow to modify messages as well - templating is [not there yet](https://github.com/epoberezkin/ajv-errors/issues/4), though.
|
||||
Since the property name is already in the params object, in an application you can modify messages in any way you need. ajv-errors package allows modifying messages as well.
|
||||
|
||||
|
||||
## Additional properties inside compound keywords anyOf, oneOf, etc.
|
||||
|
|
@ -39,7 +39,7 @@ See [#127](https://github.com/epoberezkin/ajv/issues/127), [#129](https://github
|
|||
|
||||
##### Why the keyword `additionalProperties: false` fails validation when some properties are "declared" inside a subschema in `anyOf`/etc.?
|
||||
|
||||
The keyword `additionalProperties` creates the restriction on validated data based on its own value (`false` or schema object) and on the keywords `properties` and `patternProperties` in the SAME schema object. JSON-schema validators must NOT take into account properties used in other schema objects.
|
||||
The keyword `additionalProperties` creates the restriction on validated data based on its own value (`false` or schema object) and on the keywords `properties` and `patternProperties` in the SAME schema object. JSON Schema validators must NOT take into account properties used in other schema objects.
|
||||
|
||||
While you can expect that the schema below would allow the objects either with properties `foo` and `bar` or with properties `foo` and `baz` and all other properties will be prohibited, this schema will only allow objects with one property `foo` (an empty object and any non-objects will also be valid):
|
||||
|
||||
|
|
@ -84,5 +84,5 @@ There were many conversations about the meaning of `$ref` in [JSON Schema GitHub
|
|||
|
||||
There are two possible approaches:
|
||||
|
||||
1. Write code to traverse schema and replace every `$ref` with the referenced schema. An additional limitation is that `"$ref"` inside keywords "properties", "patternProperties" and "dependencies" means property name (or pattern) rather than the reference to another schema.
|
||||
1. Traverse schema (e.g. with json-schema-traverse) and replace every `$ref` with the referenced schema.
|
||||
2. Use a specially constructed JSON Schema with a [custom keyword](https://github.com/epoberezkin/ajv/blob/master/CUSTOM.md) to traverse and modify your schema.
|
||||
|
|
|
|||
38
KEYWORDS.md
38
KEYWORDS.md
|
|
@ -1,7 +1,7 @@
|
|||
# JSON Schema validation keywords
|
||||
|
||||
|
||||
In a simple way, JSON schema is an object with validation keywords.
|
||||
In a simple way, JSON Schema is an object with validation keywords.
|
||||
|
||||
The keywords and their values define what rules the data should satisfy to be valid.
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ __Examples__
|
|||
_invalid_: `[]`, `{}`, `null`, `true`
|
||||
|
||||
|
||||
All examples above are JSON schemas that only require data to be of certain type to be valid.
|
||||
All examples above are JSON Schemas that only require data to be of certain type to be valid.
|
||||
|
||||
Most other keywords apply only to a particular type of data. If the data is of different type, the keyword will not apply and the data will be considered valid.
|
||||
|
||||
|
|
@ -88,11 +88,11 @@ Most other keywords apply only to a particular type of data. If the data is of d
|
|||
|
||||
The value of keyword `maximum` (`minimum`) should be a number. This value is the maximum (minimum) allowed value for the data to be valid.
|
||||
|
||||
Draft 4: The value of keyword `exclusiveMaximum` (`exclusiveMinimum`) should be a boolean value. These keyword cannot be used without `maximum` (`minimum`). If this keyword value is equal to `true`, the data should not be equal to the value in `maximum` (`minimum`) keyword to be valid.
|
||||
Draft-04: The value of keyword `exclusiveMaximum` (`exclusiveMinimum`) should be a boolean value. These keyword cannot be used without `maximum` (`minimum`). If this keyword value is equal to `true`, the data should not be equal to the value in `maximum` (`minimum`) keyword to be valid.
|
||||
|
||||
Draft 6: The value of keyword `exclusiveMaximum` (`exclusiveMinimum`) should be a number. This value is the exclusive maximum (minimum) allowed value for the data to be valid (the data equal to this keyword value is invalid).
|
||||
Draft-06/07: The value of keyword `exclusiveMaximum` (`exclusiveMinimum`) should be a number. This value is the exclusive maximum (minimum) allowed value for the data to be valid (the data equal to this keyword value is invalid).
|
||||
|
||||
Ajv supports both draft 4 and draft 6 syntaxes.
|
||||
Ajv supports both draft-04 and draft-06/07 syntaxes.
|
||||
|
||||
|
||||
__Examples__
|
||||
|
|
@ -112,8 +112,8 @@ __Examples__
|
|||
|
||||
|
||||
3. _schema_:
|
||||
draft 4: `{ "minimum": 5, "exclusiveMinimum": true }`
|
||||
draft 6: `{ "exclusiveMinimum": 5 }`
|
||||
draft-04: `{ "minimum": 5, "exclusiveMinimum": true }`
|
||||
draft-06/07: `{ "exclusiveMinimum": 5 }`
|
||||
|
||||
_valid_: `6`, `7`, any non-number (`"abc"`, `[]`, `{}`, `null`, `true`)
|
||||
|
||||
|
|
@ -365,7 +365,7 @@ __Examples__
|
|||
|
||||
### `contains`
|
||||
|
||||
The value of the keyword is a JSON-schema. The array is valid if it contains at least one item that is valid according to this schema.
|
||||
The value of the keyword is a JSON Schema. The array is valid if it contains at least one item that is valid according to this schema.
|
||||
|
||||
__Example__
|
||||
|
||||
|
|
@ -424,7 +424,7 @@ _invalid_: `{}`, `{"a": 1}`, `{"c": 3, "d":4}`
|
|||
|
||||
### `properties`
|
||||
|
||||
The value of the keyword should be a map with keys equal to data object properties. Each value in the map should be a JSON schema. For data object to be valid the corresponding values in data object properties should be valid according to these schemas.
|
||||
The value of the keyword should be a map with keys equal to data object properties. Each value in the map should be a JSON Schema. For data object to be valid the corresponding values in data object properties should be valid according to these schemas.
|
||||
|
||||
__Please note__: `properties` keyword does not require that the properties mentioned in it are present in the object (see examples).
|
||||
|
||||
|
|
@ -451,7 +451,7 @@ _invalid_: `{"foo": 1}`, `{"foo": "a", "bar": 1}`
|
|||
|
||||
### `patternProperties`
|
||||
|
||||
The value of this keyword should be a map where keys should be regular expressions and the values should be JSON schemas. For data object to be valid the values in data object properties that match regular expression(s) should be valid according to the corresponding schema(s).
|
||||
The value of this keyword should be a map where keys should be regular expressions and the values should be JSON Schemas. For data object to be valid the values in data object properties that match regular expression(s) should be valid according to the corresponding schema(s).
|
||||
|
||||
When the value in data object property matches multiple regular expressions it should be valid according to all the schemas for all matched regular expressions.
|
||||
|
||||
|
|
@ -478,7 +478,7 @@ _invalid_: `{"foo": 1}`, `{"foo": "a", "bar": "b"}`
|
|||
|
||||
### `additionalProperties`
|
||||
|
||||
The value of the keyword should be either a boolean or a JSON schema.
|
||||
The value of the keyword should be either a boolean or a JSON Schema.
|
||||
|
||||
If the value is `true` the keyword is ignored.
|
||||
|
||||
|
|
@ -552,7 +552,7 @@ __Examples__
|
|||
|
||||
### `dependencies`
|
||||
|
||||
The value of the keyword is a map with keys equal to data object properties. Each value in the map should be either an array of unique property names ("property dependency") or a JSON schema ("schema dependency").
|
||||
The value of the keyword is a map with keys equal to data object properties. Each value in the map should be either an array of unique property names ("property dependency") or a JSON Schema ("schema dependency").
|
||||
|
||||
For property dependency, if the data object contains a property that is a key in the keyword value, then to be valid the data object should also contain all properties from the array of properties.
|
||||
|
||||
|
|
@ -596,7 +596,7 @@ __Examples__
|
|||
|
||||
### `propertyNames`
|
||||
|
||||
The value of this keyword is a JSON schema.
|
||||
The value of this keyword is a JSON Schema.
|
||||
|
||||
For data object to be valid each property name in this object should be valid according to this schema.
|
||||
|
||||
|
|
@ -623,7 +623,7 @@ This keyword is only provided for backward compatibility, it will be removed in
|
|||
|
||||
The value of this keyword should be a map where keys should be regular expressions and the values should be objects with the following properties:
|
||||
|
||||
- `schema` (required) - should be a JSON schema. For data object to be valid the values in data object properties that match regular expression(s) should be valid according to the corresponding `schema`(s).
|
||||
- `schema` (required) - should be a JSON Schema. For data object to be valid the values in data object properties that match regular expression(s) should be valid according to the corresponding `schema`(s).
|
||||
- `maximum` / `minimum` (optional) - should be integers. For data object to be valid the number of properties that match regular expression(s) should be within limits set by `minimum`(s) and `maximum`(s).
|
||||
|
||||
|
||||
|
|
@ -732,7 +732,7 @@ _invalid_: `{ "foo": 1 }`, `{ "bar": 1 }`, `{ "foo": 1, "bar": 2 }`
|
|||
|
||||
### `not`
|
||||
|
||||
The value of the keyword should be a JSON schema. The data is valid if it is invalid according to this schema.
|
||||
The value of the keyword should be a JSON Schema. The data is valid if it is invalid according to this schema.
|
||||
|
||||
|
||||
__Examples__
|
||||
|
|
@ -763,7 +763,7 @@ __Examples__
|
|||
|
||||
### `oneOf`
|
||||
|
||||
The value of the keyword should be an array of JSON schemas. The data is valid if it matches exactly one JSON schema from this array. Validators have to validate data against all schemas to establish validity according to this keyword.
|
||||
The value of the keyword should be an array of JSON Schemas. The data is valid if it matches exactly one JSON Schema from this array. Validators have to validate data against all schemas to establish validity according to this keyword.
|
||||
|
||||
|
||||
__Example__
|
||||
|
|
@ -786,7 +786,7 @@ _invalid_: `2`, `3`, `4.5`, `5.5`
|
|||
|
||||
### `anyOf`
|
||||
|
||||
The value of the keyword should be an array of JSON schemas. The data is valid if it is valid according to one or more JSON schemas in this array. Validators only need to validate data against schemas in order until the first schema matches (or until all schemas have been tried). For this reason validating against this keyword is faster than against "oneOf" keyword in most cases.
|
||||
The value of the keyword should be an array of JSON Schemas. The data is valid if it is valid according to one or more JSON Schemas in this array. Validators only need to validate data against schemas in order until the first schema matches (or until all schemas have been tried). For this reason validating against this keyword is faster than against "oneOf" keyword in most cases.
|
||||
|
||||
|
||||
__Example__
|
||||
|
|
@ -809,7 +809,7 @@ _invalid_: `4.5`, `5.5`
|
|||
|
||||
### `allOf`
|
||||
|
||||
The value of the keyword should be an array of JSON schemas. The data is valid if it is valid according to all JSON schemas in this array.
|
||||
The value of the keyword should be an array of JSON Schemas. The data is valid if it is valid according to all JSON Schemas in this array.
|
||||
|
||||
|
||||
__Example__
|
||||
|
|
@ -832,7 +832,7 @@ _invalid_: `1.5`, `2.5`, `4`, `4.5`, `5`, `5.5`, any non-number
|
|||
|
||||
### `if`/`then`/`else`
|
||||
|
||||
These keywords allow to implement conditional validation. Their values should be valid JSON-schemas (object or boolean).
|
||||
These keywords allow to implement conditional validation. Their values should be valid JSON Schemas (object or boolean).
|
||||
|
||||
If `if` keyword is absent, the validation succeds.
|
||||
|
||||
|
|
|
|||
2
LICENSE
2
LICENSE
|
|
@ -1,6 +1,6 @@
|
|||
The MIT License (MIT)
|
||||
|
||||
Copyright (c) 2015 Evgeny Poberezkin
|
||||
Copyright (c) 2015-2017 Evgeny Poberezkin
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
|
|
|
|||
34
README.md
34
README.md
|
|
@ -62,7 +62,7 @@ ajv.addMetaSchema(require('ajv/lib/refs/json-schema-draft-06.json'));
|
|||
|
||||
## Performance
|
||||
|
||||
Ajv generates code using [doT templates](https://github.com/olado/doT) to turn JSON schemas into super-fast validation functions that are efficient for v8 optimization.
|
||||
Ajv generates code using [doT templates](https://github.com/olado/doT) to turn JSON Schemas into super-fast validation functions that are efficient for v8 optimization.
|
||||
|
||||
Currently Ajv is the fastest and the most standard compliant validator according to these benchmarks:
|
||||
|
||||
|
|
@ -79,12 +79,12 @@ Performance of different validators by [json-schema-benchmark](https://github.co
|
|||
|
||||
## Features
|
||||
|
||||
- Ajv implements full JSON Schema [draft 6](http://json-schema.org/) and draft 4 standards:
|
||||
- Ajv implements full JSON Schema [draft-06/07](http://json-schema.org/) and draft-04 standards:
|
||||
- all validation keywords (see [JSON Schema validation keywords](https://github.com/epoberezkin/ajv/blob/master/KEYWORDS.md))
|
||||
- full support of remote refs (remote schemas have to be added with `addSchema` or compiled to be available)
|
||||
- support of circular references between schemas
|
||||
- correct string lengths for strings with unicode pairs (can be turned off)
|
||||
- [formats](#formats) defined by JSON Schema draft 4 standard and custom formats (can be turned off)
|
||||
- [formats](#formats) defined by JSON Schema draft-07 standard and custom formats (can be turned off)
|
||||
- [validates schemas against meta-schema](#api-validateschema)
|
||||
- supports [browsers](#using-in-browser) and Node.js 0.10-8.x
|
||||
- [asynchronous loading](#asynchronous-schema-compilation) of referenced schemas during compilation
|
||||
|
|
@ -97,7 +97,7 @@ Performance of different validators by [json-schema-benchmark](https://github.co
|
|||
- [custom keywords](#defining-custom-keywords)
|
||||
- draft-6 keywords `const`, `contains` and `propertyNames`
|
||||
- draft-6 boolean schemas (`true`/`false` as a schema to always pass/fail).
|
||||
- keywords `switch`, `patternRequired`, `formatMaximum` / `formatMinimum` and `formatExclusiveMaximum` / `formatExclusiveMinimum` from [JSON-schema extension proposals](https://github.com/json-schema/json-schema/wiki/v5-Proposals) with [ajv-keywords](https://github.com/epoberezkin/ajv-keywords) package
|
||||
- keywords `switch`, `patternRequired`, `formatMaximum` / `formatMinimum` and `formatExclusiveMaximum` / `formatExclusiveMinimum` from [JSON Schema extension proposals](https://github.com/json-schema/json-schema/wiki/v5-Proposals) with [ajv-keywords](https://github.com/epoberezkin/ajv-keywords) package
|
||||
- [$data reference](#data-reference) to use values from the validated data as values for the schema keywords
|
||||
- [asynchronous validation](#asynchronous-validation) of custom formats and keywords
|
||||
|
||||
|
|
@ -186,11 +186,11 @@ __Please note__: some frameworks, e.g. Dojo, may redefine global require in such
|
|||
|
||||
CLI is available as a separate npm package [ajv-cli](https://github.com/jessedc/ajv-cli). It supports:
|
||||
|
||||
- compiling JSON-schemas to test their validity
|
||||
- compiling JSON Schemas to test their validity
|
||||
- BETA: generating standalone module exporting a validation function to be used without Ajv (using [ajv-pack](https://github.com/epoberezkin/ajv-pack))
|
||||
- migrate schemas to draft-07 (using [json-schema-migrate](https://github.com/epoberezkin/json-schema-migrate))
|
||||
- validating data file(s) against JSON-schema
|
||||
- testing expected validity of data against JSON-schema
|
||||
- validating data file(s) against JSON Schema
|
||||
- testing expected validity of data against JSON Schema
|
||||
- referenced schemas
|
||||
- custom meta-schemas
|
||||
- files in JSON and JavaScript format
|
||||
|
|
@ -200,7 +200,7 @@ CLI is available as a separate npm package [ajv-cli](https://github.com/jessedc/
|
|||
|
||||
## Validation keywords
|
||||
|
||||
Ajv supports all validation keywords from draft 4 of JSON-schema standard:
|
||||
Ajv supports all validation keywords from draft-07 of JSON Schema standard:
|
||||
|
||||
- [type](https://github.com/epoberezkin/ajv/blob/master/KEYWORDS.md#type)
|
||||
- [for numbers](https://github.com/epoberezkin/ajv/blob/master/KEYWORDS.md#keywords-for-numbers) - maximum, minimum, exclusiveMaximum, exclusiveMinimum, multipleOf
|
||||
|
|
@ -210,7 +210,7 @@ Ajv supports all validation keywords from draft 4 of JSON-schema standard:
|
|||
- [for all types](https://github.com/epoberezkin/ajv/blob/master/KEYWORDS.md#keywords-for-all-types) - enum, [const](https://github.com/epoberezkin/ajv/blob/master/KEYWORDS.md#const)
|
||||
- [compound keywords](https://github.com/epoberezkin/ajv/blob/master/KEYWORDS.md#compound-keywords) - not, oneOf, anyOf, allOf, [if/then/else](https://github.com/epoberezkin/ajv/blob/master/KEYWORDS.md#ifthenelse)
|
||||
|
||||
With [ajv-keywords](https://github.com/epoberezkin/ajv-keywords) package Ajv also supports validation keywords from [JSON Schema extension proposals](https://github.com/json-schema/json-schema/wiki/v5-Proposals) for JSON-schema standard:
|
||||
With [ajv-keywords](https://github.com/epoberezkin/ajv-keywords) package Ajv also supports validation keywords from [JSON Schema extension proposals](https://github.com/json-schema/json-schema/wiki/v5-Proposals) for JSON Schema standard:
|
||||
|
||||
- [patternRequired](https://github.com/epoberezkin/ajv/blob/master/KEYWORDS.md#patternrequired-proposed) - like `required` but with patterns that some property should match.
|
||||
- [formatMaximum, formatMinimum, formatExclusiveMaximum, formatExclusiveMinimum](https://github.com/epoberezkin/ajv/blob/master/KEYWORDS.md#formatmaximum--formatminimum-and-exclusiveformatmaximum--exclusiveformatminimum-proposed) - setting limits for date, time, etc.
|
||||
|
|
@ -369,7 +369,7 @@ var validData = {
|
|||
|
||||
## $merge and $patch keywords
|
||||
|
||||
With the package [ajv-merge-patch](https://github.com/epoberezkin/ajv-merge-patch) you can use the keywords `$merge` and `$patch` that allow extending JSON-schemas with patches using formats [JSON Merge Patch (RFC 7396)](https://tools.ietf.org/html/rfc7396) and [JSON Patch (RFC 6902)](https://tools.ietf.org/html/rfc6902).
|
||||
With the package [ajv-merge-patch](https://github.com/epoberezkin/ajv-merge-patch) you can use the keywords `$merge` and `$patch` that allow extending JSON Schemas with patches using formats [JSON Merge Patch (RFC 7396)](https://tools.ietf.org/html/rfc7396) and [JSON Patch (RFC 6902)](https://tools.ietf.org/html/rfc6902).
|
||||
|
||||
To add keywords `$merge` and `$patch` to Ajv instance use this code:
|
||||
|
||||
|
|
@ -443,7 +443,7 @@ The advantages of using custom keywords are:
|
|||
|
||||
If a keyword is used only for side-effects and its validation result is pre-defined, use option `valid: true/false` in keyword definition to simplify both generated code (no error handling in case of `valid: true`) and your keyword functions (no need to return any validation result).
|
||||
|
||||
The concerns you have to be aware of when extending JSON-schema standard with custom keywords are the portability and understanding of your schemas. You will have to support these custom keywords on other platforms and to properly document these keywords so that everybody can understand them in your schemas.
|
||||
The concerns you have to be aware of when extending JSON Schema standard with custom keywords are the portability and understanding of your schemas. You will have to support these custom keywords on other platforms and to properly document these keywords so that everybody can understand them in your schemas.
|
||||
|
||||
You can define custom keywords with [addKeyword](#api-addkeyword) method. Keywords are defined on the `ajv` instance level - new instances will not have previously defined keywords.
|
||||
|
||||
|
|
@ -960,14 +960,14 @@ Custom formats can be also added via `formats` option.
|
|||
|
||||
Add custom validation keyword to Ajv instance.
|
||||
|
||||
Keyword should be different from all standard JSON schema keywords and different from previously defined keywords. There is no way to redefine keywords or to remove keyword definition from the instance.
|
||||
Keyword should be different from all standard JSON Schema keywords and different from previously defined keywords. There is no way to redefine keywords or to remove keyword definition from the instance.
|
||||
|
||||
Keyword must start with a letter, `_` or `$`, and may continue with letters, numbers, `_`, `$`, or `-`.
|
||||
It is recommended to use an application-specific prefix for keywords to avoid current and future name collisions.
|
||||
|
||||
Example Keywords:
|
||||
- `"xyz-example"`: valid, and uses prefix for the xyz project to avoid name collisions.
|
||||
- `"example"`: valid, but not recommended as it could collide with future versions of JSON schema etc.
|
||||
- `"example"`: valid, but not recommended as it could collide with future versions of JSON Schema etc.
|
||||
- `"3-example"`: invalid as numbers are not allowed to be the first character in a keyword
|
||||
|
||||
Keyword definition is an object with the following properties:
|
||||
|
|
@ -1078,7 +1078,7 @@ Defaults:
|
|||
- _unknownFormats_: handling of unknown formats. Option values:
|
||||
- `true` (default) - if an unknown format is encountered the exception is thrown during schema compilation. If `format` keyword value is [$data reference](#data-reference) and it is unknown the validation will fail.
|
||||
- `[String]` - an array of unknown format names that will be ignored. This option can be used to allow usage of third party schemas with format(s) for which you don't have definitions, but still fail if another unknown format is used. If `format` keyword value is [$data reference](#data-reference) and it is not in this array the validation will fail.
|
||||
- `"ignore"` - to log warning during schema compilation and always pass validation (the default behaviour in versions before 5.0.0). This option is not recommended, as it allows to mistype format name and it won't be validated without any error message. This behaviour is required by JSON-schema specification.
|
||||
- `"ignore"` - to log warning during schema compilation and always pass validation (the default behaviour in versions before 5.0.0). This option is not recommended, as it allows to mistype format name and it won't be validated without any error message. This behaviour is required by JSON Schema specification.
|
||||
- _schemas_: an array or object of schemas that will be added to the instance. In case you pass the array the schemas must have IDs in them. When the object is passed the method `addSchema(value, key)` will be called for each schema in this object.
|
||||
- _logger_: sets the logging method. Default is the global `console` object that should have methods `log`, `warn` and `error`. Option values:
|
||||
- custom logger - it should have methods `log`, `warn` and `error`. If any of these methods is missing an exception will be thrown.
|
||||
|
|
@ -1130,7 +1130,7 @@ Defaults:
|
|||
##### Advanced options
|
||||
|
||||
- _meta_: add [meta-schema](http://json-schema.org/documentation.html) so it can be used by other schemas (true by default). If an object is passed, it will be used as the default meta-schema for schemas that have no `$schema` keyword. This default meta-schema MUST have `$schema` keyword.
|
||||
- _validateSchema_: validate added/compiled schemas against meta-schema (true by default). `$schema` property in the schema can either be http://json-schema.org/schema or http://json-schema.org/draft-04/schema or absent (draft-4 meta-schema will be used) or can be a reference to the schema previously added with `addMetaSchema` method. Option values:
|
||||
- _validateSchema_: validate added/compiled schemas against meta-schema (true by default). `$schema` property in the schema can be http://json-schema.org/draft-07/schema or absent (draft-07 meta-schema will be used) or can be a reference to the schema previously added with `addMetaSchema` method. Option values:
|
||||
- `true` (default) - if the validation fails, throw the exception.
|
||||
- `"log"` - if the validation fails, log error.
|
||||
- `false` - skip schema validation.
|
||||
|
|
@ -1234,7 +1234,7 @@ If you have published a useful plugin please submit a PR to add it to the next s
|
|||
- [osprey-method-handler](https://github.com/mulesoft-labs/osprey-method-handler) - Express middleware for validating requests and responses based on a RAML method object, used in [osprey](https://github.com/mulesoft/osprey) - validating API proxy generated from a RAML definition
|
||||
- [har-validator](https://github.com/ahmadnassri/har-validator) - HTTP Archive (HAR) validator
|
||||
- [jsoneditor](https://github.com/josdejong/jsoneditor) - a web-based tool to view, edit, format, and validate JSON http://jsoneditoronline.org
|
||||
- [JSON Schema Lint](https://github.com/nickcmaynard/jsonschemalint) - a web tool to validate JSON/YAML document against a single JSON-schema http://jsonschemalint.com
|
||||
- [JSON Schema Lint](https://github.com/nickcmaynard/jsonschemalint) - a web tool to validate JSON/YAML document against a single JSON Schema http://jsonschemalint.com
|
||||
- [objection](https://github.com/vincit/objection.js) - SQL-friendly ORM for Node.js
|
||||
- [table](https://github.com/gajus/table) - formats data into a string table
|
||||
- [ripple-lib](https://github.com/ripple/ripple-lib) - a JavaScript API for interacting with [Ripple](https://ripple.com) in Node.js and the browser
|
||||
|
|
@ -1243,7 +1243,7 @@ If you have published a useful plugin please submit a PR to add it to the next s
|
|||
- [react-form-controlled](https://github.com/seeden/react-form-controlled) - React controlled form components with validation
|
||||
- [rabbitmq-schema](https://github.com/tjmehta/rabbitmq-schema) - a schema definition module for RabbitMQ graphs and messages
|
||||
- [@query/schema](https://www.npmjs.com/package/@query/schema) - stream filtering with a URI-safe query syntax parsing to JSON Schema
|
||||
- [chai-ajv-json-schema](https://github.com/peon374/chai-ajv-json-schema) - chai plugin to us JSON-schema with expect in mocha tests
|
||||
- [chai-ajv-json-schema](https://github.com/peon374/chai-ajv-json-schema) - chai plugin to us JSON Schema with expect in mocha tests
|
||||
- [grunt-jsonschema-ajv](https://github.com/SignpostMarv/grunt-jsonschema-ajv) - Grunt plugin for validating files against JSON Schema
|
||||
- [extract-text-webpack-plugin](https://github.com/webpack-contrib/extract-text-webpack-plugin) - extract text from bundle into a file
|
||||
- [electron-builder](https://github.com/electron-userland/electron-builder) - a solution to package and build a ready for distribution Electron app
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
{
|
||||
"$schema": "http://json-schema.org/draft-07/schema#",
|
||||
"$id": "https://raw.githubusercontent.com/epoberezkin/ajv/master/lib/refs/data.json#",
|
||||
"description": "Meta-schema for $data reference (JSON-schema extension proposal)",
|
||||
"description": "Meta-schema for $data reference (JSON Schema extension proposal)",
|
||||
"type": "object",
|
||||
"required": [ "$data" ],
|
||||
"properties": {
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
[
|
||||
{
|
||||
"description": "JSON schema for a standard RAML object (#27)",
|
||||
"description": "JSON Schema for a standard RAML object (#27)",
|
||||
"schema": {
|
||||
"title": "A JSON schema for a standard RAML object",
|
||||
"title": "A JSON Schema for a standard RAML object",
|
||||
"$schema": "http://json-schema.org/draft-04/schema#",
|
||||
"type": "object",
|
||||
"required": [
|
||||
|
|
|
|||
Loading…
Reference in New Issue