|
624 | 624 | which must be resolved against another value, such as another
|
625 | 625 | URI-reference or a full URI, which is found through the lexical
|
626 | 626 | structure of the JSON document. The "$id", "$ref", and
|
627 |
| - "$dyanmicRef" core keywords, and the "base" JSON Hyper-Schema |
| 627 | + "$dynamicRef" core keywords, and the "base" JSON Hyper-Schema |
628 | 628 | keyword, are examples of this sort of behavior.
|
629 | 629 | </t>
|
630 | 630 | <t>
|
|
638 | 638 | with an instance document. The outermost dynamic scope is the
|
639 | 639 | root schema of the schema document in which processing begins.
|
640 | 640 | The path from this root schema to any particular keyword (that
|
641 |
| - includes any "$ref" and "$dyanmicRef" keywords that may have |
| 641 | + includes any "$ref" and "$dynamicRef" keywords that may have |
642 | 642 | been resolved) is considered the keyword's "validation path."
|
643 | 643 | <cref>
|
644 | 644 | Or should this be the schema object at which processing
|
645 | 645 | begins, even if it is not a root? This has some implications
|
646 |
| - for the case where "$dyanmicAnchor" is only allowed in the |
| 646 | + for the case where "$dynamicAnchor" is only allowed in the |
647 | 647 | root schema but processing begins in a subschema.
|
648 | 648 | </cref>
|
649 | 649 | </t>
|
|
658 | 658 | dynamic parent, rather than examining the local lexically enclosing parent.
|
659 | 659 | </t>
|
660 | 660 | <t>
|
661 |
| - The concept of dynamic scope is primarily used with "$dyanmicRef" and |
662 |
| - "$dyanmicAnchor", and should be considered an advanced feature |
| 661 | + The concept of dynamic scope is primarily used with "$dynamicRef" and |
| 662 | + "$dynamicAnchor", and should be considered an advanced feature |
663 | 663 | and used with caution when defining additional keywords. It also appears
|
664 | 664 | when reporting errors and collected annotations, as it may be possible
|
665 | 665 | to revisit the same lexical scope repeatedly with different dynamic
|
|
721 | 721 | <t>
|
722 | 722 | While custom identifier keywords are possible, vocabulary designers should
|
723 | 723 | take care not to disrupt the functioning of core keywords. For example,
|
724 |
| - the "$dyanmicAnchor" keyword in this specification limits its URI resolution |
725 |
| - effects to the matching "$dyanmicRef" keyword, leaving the behavior |
| 724 | + the "$dynamicAnchor" keyword in this specification limits its URI resolution |
| 725 | + effects to the matching "$dynamicRef" keyword, leaving the behavior |
726 | 726 | of "$ref" undisturbed.
|
727 | 727 | </t>
|
728 | 728 | </section>
|
|
774 | 774 | For some by-reference applicators, such as
|
775 | 775 | <xref target="ref">"$ref"</xref>, the referenced schema can be determined
|
776 | 776 | by static analysis of the schema document's lexical scope. Others,
|
777 |
| - such as "$dyanmicRef" (with "$dyanmicAnchor"), may make use of dynamic |
| 777 | + such as "$dynamicRef" (with "$dynamicAnchor"), may make use of dynamic |
778 | 778 | scoping, and therefore only be resolvable in the process of evaluating
|
779 | 779 | the schema with an instance.
|
780 | 780 | </t>
|
|
1435 | 1435 | <section title="Schema References" anchor="references">
|
1436 | 1436 | <t>
|
1437 | 1437 | Several keywords can be used to reference a schema which is to be applied to the
|
1438 |
| - current instance location. "$ref" and "$dyanmicRef" are applicator |
| 1438 | + current instance location. "$ref" and "$dynamicRef" are applicator |
1439 | 1439 | keywords, applying the referenced schema to the instance.
|
1440 | 1440 | </t>
|
1441 | 1441 | <t>
|
|
0 commit comments