adapt-authoring-jsonschema 0.0.1 → 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.eslintignore +1 -1
- package/.eslintrc +14 -14
- package/.github/ISSUE_TEMPLATE/bug_report.yml +55 -55
- package/.github/ISSUE_TEMPLATE/feature_request.yml +22 -22
- package/.github/dependabot.yml +11 -11
- package/.github/pull_request_template.md +25 -25
- package/.github/workflows/labelled_prs.yml +16 -16
- package/.github/workflows/new.yml +19 -19
- package/.github/workflows/releases.yml +25 -0
- package/adapt-authoring.json +13 -13
- package/bin/check.js +43 -43
- package/conf/config.schema.json +25 -25
- package/docs/plugins/schemas-reference.js +74 -74
- package/docs/plugins/schemas-reference.md +6 -6
- package/docs/schema-examples.md +143 -143
- package/docs/schemas-introduction.md +77 -77
- package/docs/writing-a-schema.md +193 -193
- package/errors/errors.json +52 -52
- package/index.js +5 -5
- package/lib/JsonSchema.js +268 -268
- package/lib/JsonSchemaModule.js +209 -209
- package/lib/Keywords.js +74 -74
- package/lib/XSSDefaults.js +142 -142
- package/lib/typedefs.js +47 -47
- package/package.json +64 -29
- package/schema/base.schema.json +13 -13
package/docs/writing-a-schema.md
CHANGED
|
@@ -1,194 +1,194 @@
|
|
|
1
|
-
# Writing a schema
|
|
2
|
-
|
|
3
|
-
This page outlines the various elements of an Adapt data schema, and gives tips on how to start writing your own schemas. If you're new to schemas, head over to [this page](/introduction-to-schemas), which goes over the basics.
|
|
4
|
-
|
|
5
|
-
> For some specific schema examples, see [this page](/schema-examples).
|
|
6
|
-
|
|
7
|
-
## Quick links
|
|
8
|
-
- [Defining a schema](#defining-a-schema)
|
|
9
|
-
- [Defining schema inheritance](#defining-schema-inheritance)
|
|
10
|
-
- [Custom schema keywords](#custom-schema-keywords)
|
|
11
|
-
- [Custom Adapt properties](#custom-adapt-properties)
|
|
12
|
-
- [Custom Backbone Forms properties](#custom-backbone-forms-properties)
|
|
13
|
-
|
|
14
|
-
## Defining schema inheritance
|
|
15
|
-
|
|
16
|
-
You may find when defining your schemas that you want to extend or modify existing schemas, or split up your schemas in such a way as you can share properties across multiple schemas. For this purpose, you can use the `$merge` and `$patch` keywords.
|
|
17
|
-
|
|
18
|
-
The main difference between merge and patch schemas is how they're accessed:
|
|
19
|
-
- `$merge` schemas are considered 'complete' schemas, and are accessed directly (e.g. the UI will request the MCQ schema by name when rendering the MCQ form page)
|
|
20
|
-
- `$patch` schemas are not considered 'complete' schemas, but rather are 'attached' to another schema when that schema is requested (e.g. the UI will request the `course` schema which will include the relevant extension `$patch` schemas).
|
|
21
|
-
|
|
22
|
-
### `$merge` schemas
|
|
23
|
-
|
|
24
|
-
Merge schemas are useful when you have a schema which needs to directly inherit from another existing schema. As an example, all Adapt framework content schemas extend from a base `content` schema, which defines the basic attributes such as `title` and `body`.
|
|
25
|
-
|
|
26
|
-
Every `$merge` schema must define the base schema it inherits from (as a `source` attribute), and any additional properties (nested under a `with` attribute). For example:
|
|
27
|
-
|
|
28
|
-
```
|
|
29
|
-
{
|
|
30
|
-
"$anchor": "example-schema",
|
|
31
|
-
"$schema": "https://json-schema.org/draft/2020-12/schema",
|
|
32
|
-
"type": "object",
|
|
33
|
-
"$merge": {
|
|
34
|
-
"source": {
|
|
35
|
-
"$ref": "base-schema"
|
|
36
|
-
}
|
|
37
|
-
"with": {
|
|
38
|
-
"properties": {
|
|
39
|
-
"myAttribute": {
|
|
40
|
-
"type": "string"
|
|
41
|
-
}
|
|
42
|
-
}
|
|
43
|
-
}
|
|
44
|
-
}
|
|
45
|
-
}
|
|
46
|
-
```
|
|
47
|
-
|
|
48
|
-
### `$patch` schemas
|
|
49
|
-
|
|
50
|
-
`$patch` schemas are useful when looking to augment an existing schema with extra attributes or override existing schema properties (as an example, many Adapt framework extensions will define their own `$patch`schema for the `course` schema which will define extra `_globals` properties specific to that extension).
|
|
51
|
-
|
|
52
|
-
`$patch` schemas are almost identical to `$merge` schemas, with the only difference being that the `$merge` is replaced with the `$patch` keyword:
|
|
53
|
-
|
|
54
|
-
```
|
|
55
|
-
{
|
|
56
|
-
"$anchor": "example-schema",
|
|
57
|
-
"$schema": "https://json-schema.org/draft/2020-12/schema",
|
|
58
|
-
"type": "object",
|
|
59
|
-
"$patch": {
|
|
60
|
-
"source": {
|
|
61
|
-
"$ref": "base-schema"
|
|
62
|
-
}
|
|
63
|
-
"with": {
|
|
64
|
-
"properties": {
|
|
65
|
-
"myAttribute": {
|
|
66
|
-
"type": "string"
|
|
67
|
-
}
|
|
68
|
-
}
|
|
69
|
-
}
|
|
70
|
-
}
|
|
71
|
-
}
|
|
72
|
-
```
|
|
73
|
-
|
|
74
|
-
## Custom schema keywords
|
|
75
|
-
|
|
76
|
-
In addition to the standard keywords defined in the JSON schema specification, the Adapt authoring tool jsonschema module defines a number of extra custom keywords which add extra convenient functionality when validating incoming data.
|
|
77
|
-
|
|
78
|
-
The following custom keywords are available:
|
|
79
|
-
|
|
80
|
-
### `isDate`
|
|
81
|
-
This keyword will parse any string value into a valid JavaScript Date.
|
|
82
|
-
|
|
83
|
-
#### Example
|
|
84
|
-
```
|
|
85
|
-
"myDateAttribute": {
|
|
86
|
-
"type": "string",
|
|
87
|
-
"isDate": true
|
|
88
|
-
}
|
|
89
|
-
```
|
|
90
|
-
|
|
91
|
-
### `isDirectory`
|
|
92
|
-
This keyword will resolve any path values using a number of default directory values. This is very useful when making use of the existing app directories (e.g. you want to store data in the app's temp folder). The following are supported values:
|
|
93
|
-
- `$ROOT` will resolve to the main app root folder
|
|
94
|
-
- `$DATA` will resolve to the app's data folder
|
|
95
|
-
- `$TEMP` will resolve to the app's temp folder
|
|
96
|
-
|
|
97
|
-
#### Example
|
|
98
|
-
```
|
|
99
|
-
"myDirectoryAttribute": {
|
|
100
|
-
"type": "string",
|
|
101
|
-
"isDirectory": true,
|
|
102
|
-
"default": "$TEMP/myfolder" // will be replace $TEMP with the correct path to the temp folder
|
|
103
|
-
}
|
|
104
|
-
```
|
|
105
|
-
|
|
106
|
-
### `isInternal`
|
|
107
|
-
This keyword will ensure that the attribute is **not** returned when a web API request is made. This is useful for restricting sensitive information like passwords. Note that this keyword only applies to the web APIs, and not when accessing data programatically.
|
|
108
|
-
|
|
109
|
-
#### Example
|
|
110
|
-
```
|
|
111
|
-
"myInternalAttribute": {
|
|
112
|
-
"type": "string",
|
|
113
|
-
"isInternal": true
|
|
114
|
-
}
|
|
115
|
-
```
|
|
116
|
-
|
|
117
|
-
### `isReadOnly`
|
|
118
|
-
This keyword will ensures that the attribute is **not** modified when a web API request is made. Note that this keyword only applies to the web APIs, and not when accessing data programatically.
|
|
119
|
-
|
|
120
|
-
#### Example
|
|
121
|
-
```
|
|
122
|
-
"myReadOnlyAttribute": {
|
|
123
|
-
"type": "string",
|
|
124
|
-
"isReadOnly": true
|
|
125
|
-
}
|
|
126
|
-
```
|
|
127
|
-
|
|
128
|
-
### `isTimeMs`
|
|
129
|
-
This keyword is very useful when defining time values, as it allows a human-readable input value to be automatically converted into milliseconds.
|
|
130
|
-
|
|
131
|
-
#### Example
|
|
132
|
-
```
|
|
133
|
-
"myTimeAttribute": {
|
|
134
|
-
"type": "string",
|
|
135
|
-
"isTimeMs": true,
|
|
136
|
-
"default": "7d" // will be converted to the equivalent of 7 days in milliseconds (604800000)
|
|
137
|
-
}
|
|
138
|
-
```
|
|
139
|
-
|
|
140
|
-
## Custom Adapt properties
|
|
141
|
-
|
|
142
|
-
The `_adapt` keyword is used to group schema properties which are non-standard to the JSON schema specification and related to various Adapt-specific features.
|
|
143
|
-
|
|
144
|
-
Property | Type | Description
|
|
145
|
-
--- | --- | ---
|
|
146
|
-
`editorOnly` | `Boolean` | Determines whether the attribute should be included in output JSON
|
|
147
|
-
`isSetting` | `Boolean` | Attribute will appear in the ‘Settings’ section of the form
|
|
148
|
-
`translatable` | `Boolean` | Whether the attribute is a language-specific string for translation
|
|
149
|
-
|
|
150
|
-
### Example
|
|
151
|
-
```
|
|
152
|
-
"myAttribute": {
|
|
153
|
-
"type": "string",
|
|
154
|
-
"_adapt": {
|
|
155
|
-
"editorOnly": true,
|
|
156
|
-
"translatable": true
|
|
157
|
-
}
|
|
158
|
-
}
|
|
159
|
-
```
|
|
160
|
-
|
|
161
|
-
## Custom Backbone forms properties
|
|
162
|
-
|
|
163
|
-
The Adapt authoring tool uses the [Backbone Forms](https://github.com/powmedia/backbone-forms) library to render forms from the data schemas into a user-friendly HTML form. The `_backboneForms` keyword is used to group schema properties which apply to Backbone Forms.
|
|
164
|
-
|
|
165
|
-
Property | Type | Description
|
|
166
|
-
--- | --- | ---
|
|
167
|
-
`type` | `String` | Override the type of Backbone Forms input to be used (by default, the type will be inferred from the schema property's type value). Accepted types: `Asset`, `Text`, `Number`, `Password`, `TextArea`, `Checkbox`, `Checkboxes`, `Select`, `Radio`, `Object`, `Date`, `DateTime`, `List`. See the [Backbone Forms docs](https://github.com/powmedia/backbone-forms#schema-definition) for more information.
|
|
168
|
-
`showInUi` | `Boolean` | Determines whether the attribute will be rendered in forms
|
|
169
|
-
`media` | `String` | When using a `type` of `Asset`, you can also restrict the AAT UI to only show assets of a specific type. The AAT stores the asset type based in its [MIME type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types) (e.g. files with a MIME type of `image/png` and `image/jpeg` would both have a type of `image`).
|
|
170
|
-
`editorAttrs` | `Object` | Extra options passed to the Backbone Forms input. See the [Backbone Forms docs](https://github.com/powmedia/backbone-forms#schema-definition) for more information.
|
|
171
|
-
|
|
172
|
-
> The Adapt authoring tool will attempt to infer the type of a form input using the `type` value in the schema. In most cases this will suffice, so check that you definitely need to override the default behaviour before defining additional `_backboneForms` properties.
|
|
173
|
-
|
|
174
|
-
### Example
|
|
175
|
-
|
|
176
|
-
```
|
|
177
|
-
"myAttribute": {
|
|
178
|
-
"type": "string",
|
|
179
|
-
"_backboneForms": {
|
|
180
|
-
"type": "Asset",
|
|
181
|
-
"showInUi": false,
|
|
182
|
-
"media": "image"
|
|
183
|
-
}
|
|
184
|
-
}
|
|
185
|
-
```
|
|
186
|
-
|
|
187
|
-
In many cases, you'll only want to customise the type of an input. If this is the case, the `_backboneForms` property can also be a string value, e.g.
|
|
188
|
-
|
|
189
|
-
```
|
|
190
|
-
"myAttribute": {
|
|
191
|
-
"type": "string",
|
|
192
|
-
"_backboneForms": "Number"
|
|
193
|
-
}
|
|
1
|
+
# Writing a schema
|
|
2
|
+
|
|
3
|
+
This page outlines the various elements of an Adapt data schema, and gives tips on how to start writing your own schemas. If you're new to schemas, head over to [this page](/introduction-to-schemas), which goes over the basics.
|
|
4
|
+
|
|
5
|
+
> For some specific schema examples, see [this page](/schema-examples).
|
|
6
|
+
|
|
7
|
+
## Quick links
|
|
8
|
+
- [Defining a schema](#defining-a-schema)
|
|
9
|
+
- [Defining schema inheritance](#defining-schema-inheritance)
|
|
10
|
+
- [Custom schema keywords](#custom-schema-keywords)
|
|
11
|
+
- [Custom Adapt properties](#custom-adapt-properties)
|
|
12
|
+
- [Custom Backbone Forms properties](#custom-backbone-forms-properties)
|
|
13
|
+
|
|
14
|
+
## Defining schema inheritance
|
|
15
|
+
|
|
16
|
+
You may find when defining your schemas that you want to extend or modify existing schemas, or split up your schemas in such a way as you can share properties across multiple schemas. For this purpose, you can use the `$merge` and `$patch` keywords.
|
|
17
|
+
|
|
18
|
+
The main difference between merge and patch schemas is how they're accessed:
|
|
19
|
+
- `$merge` schemas are considered 'complete' schemas, and are accessed directly (e.g. the UI will request the MCQ schema by name when rendering the MCQ form page)
|
|
20
|
+
- `$patch` schemas are not considered 'complete' schemas, but rather are 'attached' to another schema when that schema is requested (e.g. the UI will request the `course` schema which will include the relevant extension `$patch` schemas).
|
|
21
|
+
|
|
22
|
+
### `$merge` schemas
|
|
23
|
+
|
|
24
|
+
Merge schemas are useful when you have a schema which needs to directly inherit from another existing schema. As an example, all Adapt framework content schemas extend from a base `content` schema, which defines the basic attributes such as `title` and `body`.
|
|
25
|
+
|
|
26
|
+
Every `$merge` schema must define the base schema it inherits from (as a `source` attribute), and any additional properties (nested under a `with` attribute). For example:
|
|
27
|
+
|
|
28
|
+
```
|
|
29
|
+
{
|
|
30
|
+
"$anchor": "example-schema",
|
|
31
|
+
"$schema": "https://json-schema.org/draft/2020-12/schema",
|
|
32
|
+
"type": "object",
|
|
33
|
+
"$merge": {
|
|
34
|
+
"source": {
|
|
35
|
+
"$ref": "base-schema"
|
|
36
|
+
}
|
|
37
|
+
"with": {
|
|
38
|
+
"properties": {
|
|
39
|
+
"myAttribute": {
|
|
40
|
+
"type": "string"
|
|
41
|
+
}
|
|
42
|
+
}
|
|
43
|
+
}
|
|
44
|
+
}
|
|
45
|
+
}
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
### `$patch` schemas
|
|
49
|
+
|
|
50
|
+
`$patch` schemas are useful when looking to augment an existing schema with extra attributes or override existing schema properties (as an example, many Adapt framework extensions will define their own `$patch`schema for the `course` schema which will define extra `_globals` properties specific to that extension).
|
|
51
|
+
|
|
52
|
+
`$patch` schemas are almost identical to `$merge` schemas, with the only difference being that the `$merge` is replaced with the `$patch` keyword:
|
|
53
|
+
|
|
54
|
+
```
|
|
55
|
+
{
|
|
56
|
+
"$anchor": "example-schema",
|
|
57
|
+
"$schema": "https://json-schema.org/draft/2020-12/schema",
|
|
58
|
+
"type": "object",
|
|
59
|
+
"$patch": {
|
|
60
|
+
"source": {
|
|
61
|
+
"$ref": "base-schema"
|
|
62
|
+
}
|
|
63
|
+
"with": {
|
|
64
|
+
"properties": {
|
|
65
|
+
"myAttribute": {
|
|
66
|
+
"type": "string"
|
|
67
|
+
}
|
|
68
|
+
}
|
|
69
|
+
}
|
|
70
|
+
}
|
|
71
|
+
}
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
## Custom schema keywords
|
|
75
|
+
|
|
76
|
+
In addition to the standard keywords defined in the JSON schema specification, the Adapt authoring tool jsonschema module defines a number of extra custom keywords which add extra convenient functionality when validating incoming data.
|
|
77
|
+
|
|
78
|
+
The following custom keywords are available:
|
|
79
|
+
|
|
80
|
+
### `isDate`
|
|
81
|
+
This keyword will parse any string value into a valid JavaScript Date.
|
|
82
|
+
|
|
83
|
+
#### Example
|
|
84
|
+
```
|
|
85
|
+
"myDateAttribute": {
|
|
86
|
+
"type": "string",
|
|
87
|
+
"isDate": true
|
|
88
|
+
}
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
### `isDirectory`
|
|
92
|
+
This keyword will resolve any path values using a number of default directory values. This is very useful when making use of the existing app directories (e.g. you want to store data in the app's temp folder). The following are supported values:
|
|
93
|
+
- `$ROOT` will resolve to the main app root folder
|
|
94
|
+
- `$DATA` will resolve to the app's data folder
|
|
95
|
+
- `$TEMP` will resolve to the app's temp folder
|
|
96
|
+
|
|
97
|
+
#### Example
|
|
98
|
+
```
|
|
99
|
+
"myDirectoryAttribute": {
|
|
100
|
+
"type": "string",
|
|
101
|
+
"isDirectory": true,
|
|
102
|
+
"default": "$TEMP/myfolder" // will be replace $TEMP with the correct path to the temp folder
|
|
103
|
+
}
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
### `isInternal`
|
|
107
|
+
This keyword will ensure that the attribute is **not** returned when a web API request is made. This is useful for restricting sensitive information like passwords. Note that this keyword only applies to the web APIs, and not when accessing data programatically.
|
|
108
|
+
|
|
109
|
+
#### Example
|
|
110
|
+
```
|
|
111
|
+
"myInternalAttribute": {
|
|
112
|
+
"type": "string",
|
|
113
|
+
"isInternal": true
|
|
114
|
+
}
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
### `isReadOnly`
|
|
118
|
+
This keyword will ensures that the attribute is **not** modified when a web API request is made. Note that this keyword only applies to the web APIs, and not when accessing data programatically.
|
|
119
|
+
|
|
120
|
+
#### Example
|
|
121
|
+
```
|
|
122
|
+
"myReadOnlyAttribute": {
|
|
123
|
+
"type": "string",
|
|
124
|
+
"isReadOnly": true
|
|
125
|
+
}
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
### `isTimeMs`
|
|
129
|
+
This keyword is very useful when defining time values, as it allows a human-readable input value to be automatically converted into milliseconds.
|
|
130
|
+
|
|
131
|
+
#### Example
|
|
132
|
+
```
|
|
133
|
+
"myTimeAttribute": {
|
|
134
|
+
"type": "string",
|
|
135
|
+
"isTimeMs": true,
|
|
136
|
+
"default": "7d" // will be converted to the equivalent of 7 days in milliseconds (604800000)
|
|
137
|
+
}
|
|
138
|
+
```
|
|
139
|
+
|
|
140
|
+
## Custom Adapt properties
|
|
141
|
+
|
|
142
|
+
The `_adapt` keyword is used to group schema properties which are non-standard to the JSON schema specification and related to various Adapt-specific features.
|
|
143
|
+
|
|
144
|
+
Property | Type | Description
|
|
145
|
+
--- | --- | ---
|
|
146
|
+
`editorOnly` | `Boolean` | Determines whether the attribute should be included in output JSON
|
|
147
|
+
`isSetting` | `Boolean` | Attribute will appear in the ‘Settings’ section of the form
|
|
148
|
+
`translatable` | `Boolean` | Whether the attribute is a language-specific string for translation
|
|
149
|
+
|
|
150
|
+
### Example
|
|
151
|
+
```
|
|
152
|
+
"myAttribute": {
|
|
153
|
+
"type": "string",
|
|
154
|
+
"_adapt": {
|
|
155
|
+
"editorOnly": true,
|
|
156
|
+
"translatable": true
|
|
157
|
+
}
|
|
158
|
+
}
|
|
159
|
+
```
|
|
160
|
+
|
|
161
|
+
## Custom Backbone forms properties
|
|
162
|
+
|
|
163
|
+
The Adapt authoring tool uses the [Backbone Forms](https://github.com/powmedia/backbone-forms) library to render forms from the data schemas into a user-friendly HTML form. The `_backboneForms` keyword is used to group schema properties which apply to Backbone Forms.
|
|
164
|
+
|
|
165
|
+
Property | Type | Description
|
|
166
|
+
--- | --- | ---
|
|
167
|
+
`type` | `String` | Override the type of Backbone Forms input to be used (by default, the type will be inferred from the schema property's type value). Accepted types: `Asset`, `Text`, `Number`, `Password`, `TextArea`, `Checkbox`, `Checkboxes`, `Select`, `Radio`, `Object`, `Date`, `DateTime`, `List`. See the [Backbone Forms docs](https://github.com/powmedia/backbone-forms#schema-definition) for more information.
|
|
168
|
+
`showInUi` | `Boolean` | Determines whether the attribute will be rendered in forms
|
|
169
|
+
`media` | `String` | When using a `type` of `Asset`, you can also restrict the AAT UI to only show assets of a specific type. The AAT stores the asset type based in its [MIME type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types) (e.g. files with a MIME type of `image/png` and `image/jpeg` would both have a type of `image`).
|
|
170
|
+
`editorAttrs` | `Object` | Extra options passed to the Backbone Forms input. See the [Backbone Forms docs](https://github.com/powmedia/backbone-forms#schema-definition) for more information.
|
|
171
|
+
|
|
172
|
+
> The Adapt authoring tool will attempt to infer the type of a form input using the `type` value in the schema. In most cases this will suffice, so check that you definitely need to override the default behaviour before defining additional `_backboneForms` properties.
|
|
173
|
+
|
|
174
|
+
### Example
|
|
175
|
+
|
|
176
|
+
```
|
|
177
|
+
"myAttribute": {
|
|
178
|
+
"type": "string",
|
|
179
|
+
"_backboneForms": {
|
|
180
|
+
"type": "Asset",
|
|
181
|
+
"showInUi": false,
|
|
182
|
+
"media": "image"
|
|
183
|
+
}
|
|
184
|
+
}
|
|
185
|
+
```
|
|
186
|
+
|
|
187
|
+
In many cases, you'll only want to customise the type of an input. If this is the case, the `_backboneForms` property can also be a string value, e.g.
|
|
188
|
+
|
|
189
|
+
```
|
|
190
|
+
"myAttribute": {
|
|
191
|
+
"type": "string",
|
|
192
|
+
"_backboneForms": "Number"
|
|
193
|
+
}
|
|
194
194
|
```
|
package/errors/errors.json
CHANGED
|
@@ -1,52 +1,52 @@
|
|
|
1
|
-
{
|
|
2
|
-
"INVALID_SCHEMA": {
|
|
3
|
-
"data": {
|
|
4
|
-
"errors": "all validation errors",
|
|
5
|
-
"schemaName": "Schema name"
|
|
6
|
-
},
|
|
7
|
-
"description": "Invalid schema",
|
|
8
|
-
"statusCode": 400
|
|
9
|
-
},
|
|
10
|
-
"MISSING_SCHEMA": {
|
|
11
|
-
"data": {
|
|
12
|
-
"schemaName": "Schema name"
|
|
13
|
-
},
|
|
14
|
-
"description": "Schema is not registered in the cache",
|
|
15
|
-
"statusCode": 500
|
|
16
|
-
},
|
|
17
|
-
"MISSING_SCHEMA_NAME": {
|
|
18
|
-
"description": "Schema name is not defined",
|
|
19
|
-
"statusCode": 400
|
|
20
|
-
},
|
|
21
|
-
"MODIFY_PROTECTED_ATTR": {
|
|
22
|
-
"data": {
|
|
23
|
-
"attribute": "The protected attribute"
|
|
24
|
-
},
|
|
25
|
-
"description": "Attempted to modify a protected data attribute",
|
|
26
|
-
"statusCode": 400
|
|
27
|
-
},
|
|
28
|
-
"SCHEMA_EXISTS": {
|
|
29
|
-
"data": {
|
|
30
|
-
"filepath": "File path to the schema",
|
|
31
|
-
"schemaName": "Schema name"
|
|
32
|
-
},
|
|
33
|
-
"description": "A schema already exists with the specified name",
|
|
34
|
-
"statusCode": 400
|
|
35
|
-
},
|
|
36
|
-
"SCHEMA_LOAD_FAILED": {
|
|
37
|
-
"data": {
|
|
38
|
-
"schemaName": "Schema name"
|
|
39
|
-
},
|
|
40
|
-
"description": "Failed to load a JSON schema",
|
|
41
|
-
"statusCode": 500
|
|
42
|
-
},
|
|
43
|
-
"VALIDATION_FAILED": {
|
|
44
|
-
"data": {
|
|
45
|
-
"data": "the data failing validation",
|
|
46
|
-
"errors": "all validation errors",
|
|
47
|
-
"schemaName": "Schema name"
|
|
48
|
-
},
|
|
49
|
-
"description": "Data validation failed",
|
|
50
|
-
"statusCode": 400
|
|
51
|
-
}
|
|
52
|
-
}
|
|
1
|
+
{
|
|
2
|
+
"INVALID_SCHEMA": {
|
|
3
|
+
"data": {
|
|
4
|
+
"errors": "all validation errors",
|
|
5
|
+
"schemaName": "Schema name"
|
|
6
|
+
},
|
|
7
|
+
"description": "Invalid schema",
|
|
8
|
+
"statusCode": 400
|
|
9
|
+
},
|
|
10
|
+
"MISSING_SCHEMA": {
|
|
11
|
+
"data": {
|
|
12
|
+
"schemaName": "Schema name"
|
|
13
|
+
},
|
|
14
|
+
"description": "Schema is not registered in the cache",
|
|
15
|
+
"statusCode": 500
|
|
16
|
+
},
|
|
17
|
+
"MISSING_SCHEMA_NAME": {
|
|
18
|
+
"description": "Schema name is not defined",
|
|
19
|
+
"statusCode": 400
|
|
20
|
+
},
|
|
21
|
+
"MODIFY_PROTECTED_ATTR": {
|
|
22
|
+
"data": {
|
|
23
|
+
"attribute": "The protected attribute"
|
|
24
|
+
},
|
|
25
|
+
"description": "Attempted to modify a protected data attribute",
|
|
26
|
+
"statusCode": 400
|
|
27
|
+
},
|
|
28
|
+
"SCHEMA_EXISTS": {
|
|
29
|
+
"data": {
|
|
30
|
+
"filepath": "File path to the schema",
|
|
31
|
+
"schemaName": "Schema name"
|
|
32
|
+
},
|
|
33
|
+
"description": "A schema already exists with the specified name",
|
|
34
|
+
"statusCode": 400
|
|
35
|
+
},
|
|
36
|
+
"SCHEMA_LOAD_FAILED": {
|
|
37
|
+
"data": {
|
|
38
|
+
"schemaName": "Schema name"
|
|
39
|
+
},
|
|
40
|
+
"description": "Failed to load a JSON schema",
|
|
41
|
+
"statusCode": 500
|
|
42
|
+
},
|
|
43
|
+
"VALIDATION_FAILED": {
|
|
44
|
+
"data": {
|
|
45
|
+
"data": "the data failing validation",
|
|
46
|
+
"errors": "all validation errors",
|
|
47
|
+
"schemaName": "Schema name"
|
|
48
|
+
},
|
|
49
|
+
"description": "Data validation failed",
|
|
50
|
+
"statusCode": 400
|
|
51
|
+
}
|
|
52
|
+
}
|
package/index.js
CHANGED
|
@@ -1,5 +1,5 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* Validation of data against JSON schemas
|
|
3
|
-
* @namespace jsonschema
|
|
4
|
-
*/
|
|
5
|
-
export { default } from './lib/JsonSchemaModule.js'
|
|
1
|
+
/**
|
|
2
|
+
* Validation of data against JSON schemas
|
|
3
|
+
* @namespace jsonschema
|
|
4
|
+
*/
|
|
5
|
+
export { default } from './lib/JsonSchemaModule.js'
|