|
1210 | 1210 | must be repeated in the root of each schema document intended
|
1211 | 1211 | for use as a meta-schema. This is demonstrated in
|
1212 | 1212 | <xref target="example-meta-schema">the example meta-schema</xref>.
|
| 1213 | + <cref> |
| 1214 | + This requirement allows implementations to find all vocabulary |
| 1215 | + requirement information in a single place for each meta-schema. |
| 1216 | + As schema extensibility means that there are endless potential |
| 1217 | + ways to combine more fine-grained meta-schemas by reference, |
| 1218 | + requiring implementations to anticipate all possibilities and |
| 1219 | + search for vocabularies in referenced meta-schemas would |
| 1220 | + be overly burdensome. |
| 1221 | + </cref> |
1213 | 1222 | </t>
|
1214 | 1223 | </section>
|
1215 | 1224 | </section>
|
|
1310 | 1319 | </section>
|
1311 | 1320 | <section title="Example Meta-Schema With Vocabulary Declarations"
|
1312 | 1321 | anchor="example-meta-schema">
|
| 1322 | + <t> |
| 1323 | + This meta-schema explicitly declares both the Core and Applicator vocabularies, |
| 1324 | + together with an extension vocabulary, and combines their meta-schemas with |
| 1325 | + an "allOf". The extension vocabulary's meta-schema, which describes only the |
| 1326 | + keywords in that vocabulary, is shown after the main example meta-schema. |
| 1327 | + </t> |
| 1328 | + <t> |
| 1329 | + The main example meta-schema also restricts the usage of the Applicator |
| 1330 | + vocabulary by forbidding the keywords prefixed with "unevaluated", which |
| 1331 | + are particularly complex to implement. This does not change the semantics |
| 1332 | + or set of keywords defined by the Applicator vocabulary. It just ensures |
| 1333 | + that schemas using this meta-schema that attempt to use the keywords |
| 1334 | + prefixed with "unevaluted" will fail validation against this meta-schema. |
| 1335 | + </t> |
| 1336 | + <t> |
| 1337 | + Finally, this meta-schema describes the syntax of a keyword, "localKeyword", |
| 1338 | + that is not part of any vocabulary. Presumably, the implementors and users |
| 1339 | + of this meta-schema will understand the semantics of "localKeyword". |
| 1340 | + JSON Schema does not define any mechanism for expressing keyword semantics |
| 1341 | + outside of vocabularies, making them unsuitable for use except in a |
| 1342 | + specific environment in which they are understood. |
| 1343 | + </t> |
1313 | 1344 | <figure>
|
1314 | 1345 | <preamble>
|
1315 |
| - This meta-schema explicitly declares both the Core and Applicator |
1316 |
| - vocabularies, and combines their meta-schemas with an "allOf". |
1317 |
| - It additionally restricts the usage of the Applicator vocabulary |
1318 |
| - by forbidding the keyword prefixed with "unevaluated". It also |
1319 |
| - describes a keyword, "localKeyword", that is not part of either |
1320 |
| - vocabulary. Note that it is its own meta-schema, |
1321 |
| - as it relies on both the Core vocabulary (as all schemas do) |
1322 |
| - and the Applicator vocabulary (for "allOf"). |
| 1346 | + This meta-schema combines several vocabularies for general use. |
1323 | 1347 | </preamble>
|
1324 | 1348 | <artwork>
|
1325 | 1349 | <![CDATA[
|
1326 | 1350 | {
|
1327 |
| - "$schema": "https://json-schema.org/draft/2019-08/core-app-example#", |
1328 |
| - "$id": "https://json-schema.org/draft/2019-08/core-app-example", |
| 1351 | + "$schema": "https://json-schema.org/draft/2019-08/schema", |
| 1352 | + "$id": "https://example.com/meta/general-use-example", |
1329 | 1353 | "$recursiveAnchor": true,
|
1330 | 1354 | "$vocabulary": {
|
1331 | 1355 | "https://json-schema.org/draft/2019-08/vocab/core": true,
|
1332 |
| - "https://json-schema.org/draft/2019-08/vocab/applicator": true |
| 1356 | + "https://json-schema.org/draft/2019-08/vocab/applicator": true, |
| 1357 | + "https://json-schema.org/draft/2019-08/vocab/validation": true, |
| 1358 | + "https://example.com/vocab/example-vocab": true |
1333 | 1359 | },
|
1334 | 1360 | "allOf": [
|
1335 | 1361 | {"$ref": "https://json-schema.org/draft/2019-08/meta/core"},
|
1336 |
| - {"$ref": "https://json-schema.org/draft/2019-08/meta/applicator"} |
| 1362 | + {"$ref": "https://json-schema.org/draft/2019-08/meta/applicator"}, |
| 1363 | + {"$ref": "https://json-schema.org/draft/2019-08/meta/validation"}, |
| 1364 | + {"$ref": "https://example.com/meta/example-vocab", |
1337 | 1365 | ],
|
1338 | 1366 | "patternProperties": {
|
1339 | 1367 | "^unevaluated.*$": false
|
1340 | 1368 | },
|
1341 | 1369 | "properties": {
|
1342 |
| - "$comment": "Not in vocabulary, but validated if used", |
1343 | 1370 | "localKeyword": {
|
| 1371 | + "$comment": "Not in vocabulary, but validated if used", |
1344 | 1372 | "type": "string"
|
1345 | 1373 | }
|
1346 | 1374 | }
|
1347 | 1375 | }
|
1348 | 1376 | ]]>
|
1349 | 1377 | </artwork>
|
1350 |
| - <postamble> |
1351 |
| - As shown above, even though each of the referenced standard |
1352 |
| - meta-schemas declares its corresponding vocabulary, this new |
1353 |
| - meta-schema must re-declare them for itself. It would be |
1354 |
| - valid to leave the core vocabulary out of the "$vocabulary" keyword, |
1355 |
| - but it needs to be referenced through the "allOf" keyword in order |
1356 |
| - for its terms to be validated. There is no special case for |
1357 |
| - validation of core keywords. |
1358 |
| - </postamble> |
| 1378 | + </figure> |
| 1379 | + <figure> |
| 1380 | + <preamble> |
| 1381 | + This meta-schema describes only a single extension vocabulary. |
| 1382 | + </preamble> |
| 1383 | + <artwork> |
| 1384 | +<![CDATA[ |
| 1385 | +{ |
| 1386 | + "$schema": "https://json-schema.org/draft/2019-08/schema", |
| 1387 | + "$id": "https://example.com/meta/example-vocab", |
| 1388 | + "$recursiveAnchor": true, |
| 1389 | + "$vocabulary": { |
| 1390 | + "https://example.com/vocab/example-vocab": true, |
| 1391 | + }, |
| 1392 | + "type": ["object", "boolean"], |
| 1393 | + "properties": { |
| 1394 | + "minDate": { |
| 1395 | + "type": "string", |
| 1396 | + "pattern": "\d\d\d\d-\d\d-\d\d", |
| 1397 | + "format": "date", |
| 1398 | + } |
| 1399 | + } |
| 1400 | +} |
| 1401 | +]]> |
| 1402 | + </artwork> |
1359 | 1403 | </figure>
|
| 1404 | + <t> |
| 1405 | + As shown above, even though each of the single-vocabulary meta-schemas |
| 1406 | + referenced in the general-use meta-schema's "allOf" declares its |
| 1407 | + corresponding vocabulary, this new meta-schema must re-declare them. |
| 1408 | + </t> |
1360 | 1409 | <t>
|
1361 | 1410 | The standard meta-schemas that combine all vocabularies defined by
|
1362 | 1411 | the Core and Validation specification, and that combine all vocabularies
|
|
1365 | 1414 | meta-schemas may be found in the Validation and Hyper-Schema specifications,
|
1366 | 1415 | respectively.
|
1367 | 1416 | </t>
|
| 1417 | + <t> |
| 1418 | + While the general-use meta-schema can validate the syntax of "minDate", |
| 1419 | + it is the vocabulary that defines the logic behind the semantic meaning |
| 1420 | + of "minDate". Without an understanding of the semantics (in this example, |
| 1421 | + that the instance value must be a date equal to or after the date |
| 1422 | + provided as the keyword's value in the schema), an implementation can |
| 1423 | + only validate the syntactic usage. In this case, that means validating |
| 1424 | + that it is a date-formatted string (using "pattern" to ensure that it is |
| 1425 | + validated even when "format" functions purely as an annotation, as explained |
| 1426 | + in the <xref target="json-schema-validation">Validation specification</xref>. |
| 1427 | + </t> |
1368 | 1428 | </section>
|
1369 | 1429 | </section>
|
1370 | 1430 |
|
|
1600 | 1660 | <artwork>
|
1601 | 1661 | <![CDATA[
|
1602 | 1662 | {
|
1603 |
| - "$schema": "https://json-schema.org/draft/2019-08/schema#", |
| 1663 | + "$schema": "https://json-schema.org/draft/2019-08/schema", |
1604 | 1664 | "$id": "https://example.com/original",
|
1605 | 1665 |
|
1606 | 1666 | "properties": {
|
|
1614 | 1674 | }
|
1615 | 1675 |
|
1616 | 1676 | {
|
1617 |
| - "$schema": "https://json-schema.org/draft/2019-08/schema#", |
| 1677 | + "$schema": "https://json-schema.org/draft/2019-08/schema", |
1618 | 1678 | "$id": "https://example.com/extension",
|
1619 | 1679 |
|
1620 | 1680 | "$ref": "original",
|
|
1713 | 1773 | <artwork>
|
1714 | 1774 | <![CDATA[
|
1715 | 1775 | {
|
1716 |
| - "$schema": "https://json-schema.org/draft/2019-08/schema#", |
| 1776 | + "$schema": "https://json-schema.org/draft/2019-08/schema", |
1717 | 1777 | "$id": "https://example.com/original",
|
1718 | 1778 | "$recursiveAnchor": true,
|
1719 | 1779 |
|
|
1728 | 1788 | }
|
1729 | 1789 |
|
1730 | 1790 | {
|
1731 |
| - "$schema": "https://json-schema.org/draft/2019-08/schema#", |
| 1791 | + "$schema": "https://json-schema.org/draft/2019-08/schema", |
1732 | 1792 | "$id": "https://example.com/extension",
|
1733 | 1793 | "$recursiveAnchor": true,
|
1734 | 1794 |
|
|
0 commit comments