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