@@ -418,7 +418,7 @@ they do not know how to process or explicitly choose not to process.
418
418
## Keyword Behaviors {#keyword-behaviors}
419
419
420
420
JSON Schema keywords may exhibit one or more behaviors. This specification
421
- defines three such behaviors:
421
+ defines three such behaviors[ ^ 7 ] :
422
422
423
423
- Assertions validate that an instance satisfies constraints, producing a
424
424
boolean result: ` true ` if the constraints are satisfied; ` false ` otherwise.
@@ -427,6 +427,12 @@ defines three such behaviors:
427
427
- Applicators apply subschemas to parts of the instance and combine their
428
428
results.
429
429
430
+ [ ^ 7 ] : This specification also defines several operational directive keywords,
431
+ such as ` $id ` and ` $schema ` . As such, these keywords do not exhibit these
432
+ behaviors. However, it is recommended that extensions avoid defining additional
433
+ directive keywords as they could interfere with schema processing and produce
434
+ unexpected or undesirable results.
435
+
430
436
Extension keywords SHOULD be defined using these behaviors, keeping in mind that
431
437
annotations in particular are extremely flexible. Complex behavior is usually
432
438
better delegated to applications on the basis of annotation data than
@@ -589,8 +595,14 @@ identifying such referenced schemas is defined by the keyword.
589
595
Applicator keywords also behave as assertions by defining how subschema or
590
596
referenced schema boolean [ assertion] ( #assertions ) results are modified and/or
591
597
combined to produce the boolean result of the applicator. Applicators may apply
592
- any boolean logic operation to the assertion results of subschemas, but MUST NOT
593
- introduce new assertion conditions of their own.
598
+ any boolean logic operation to the assertion results of subschemas, but SHOULD
599
+ NOT introduce new assertion conditions of their own.[ ^ 2 ]
600
+
601
+ [ ^ 2 ] : It is recommended that keywords have a single resposibility. An example of
602
+ this in action is the separation between ` properties ` , which verifies object
603
+ property values have the right data _ if_ they exist, and ` required ` , which
604
+ verifies that object properties exist. Separating these concerns allows for more
605
+ reusable components.
594
606
595
607
[ Annotation] ( #annotations ) results from subschemas are preserved in accordance
596
608
with {{collect}} so that applications can decide how to interpret multiple
0 commit comments