|
557 | 557 | <section title="Identifying the root schema">
|
558 | 558 | <t>
|
559 | 559 | The root schema of a JSON Schema document SHOULD contain an "$id" keyword with
|
560 |
| - a URI (containing a scheme). This URI SHOULD either not have a fragment, or |
561 |
| - have one that is an empty string. |
| 560 | + an <xref target="RFC3986">absolute-URI</xref> (containing a scheme, but no fragment), |
| 561 | + or this absolute URI but with an empty fragment. |
562 | 562 | <!-- All of the standard meta-schemas use an empty fragment in their id/$id values. -->
|
563 | 563 | </t>
|
564 | 564 | </section>
|
|
583 | 583 | without requiring JSON Pointer references to be updated.
|
584 | 584 | </t>
|
585 | 585 | <t>
|
586 |
| - To name subschemas in a JSON Schema document, |
587 |
| - subschemas can use "$id" to give themselves a document-local identifier. |
588 |
| - This is done by setting "$id" to a URI reference consisting |
589 |
| - only of a plain name fragment (not a JSON Pointer fragment). |
590 |
| - The fragment identifier MUST begin with a letter ([A-Za-z]), followed by |
591 |
| - any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons |
592 |
| - (":"), or periods ("."). |
| 586 | + To specify such a subschema identifier, |
| 587 | + the "$id" keyword is set to a URI reference with a name fragment (not a JSON Pointer fragment). |
| 588 | + This value MUST begin with the number sign that specifies a fragment ("#"), |
| 589 | + then a letter ([A-Za-z]), |
| 590 | + followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), |
| 591 | + colons (":"), or periods ("."). |
593 | 592 | </t>
|
594 | 593 | <t>
|
595 |
| - The effect of defining a fragment-only "$id" URI reference that neither |
596 |
| - matches the above requirements nor is a valid JSON pointer |
597 |
| - is not defined. |
| 594 | + The effect of using a fragment in "$id" that isn't blank or doesn't follow the |
| 595 | + name syntax is undefined. |
598 | 596 | <cref>
|
599 | 597 | How should an "$id" URI reference containing a fragment with other components
|
600 | 598 | be interpreted? There are two cases: when the other components match
|
|
711 | 709 | </t>
|
712 | 710 | <section title="Loading a referenced schema">
|
713 | 711 | <t>
|
714 |
| - To differentiate schemas between each other in a vast ecosystem, schemas are |
| 712 | + To differentiate between schemas in a vast ecosystem, schemas are |
715 | 713 | identified by URI. As specified above, this does not necessarily mean
|
716 | 714 | anything is downloaded, but instead JSON Schema implementations SHOULD
|
717 |
| - already understand the schemas they will be using, including the URIs that |
| 715 | + understand ahead of time which schemas they will be using, and the URIs that |
718 | 716 | identify them.
|
719 | 717 | </t>
|
720 | 718 | <t>
|
|
728 | 726 | <t>
|
729 | 727 | A schema MAY (and likely will) have multiple URIs, but there is no way for a
|
730 | 728 | URI to identify more than one schema. When multiple schemas try to identify
|
731 |
| - with the same URI, validators SHOULD raise an error condition. |
| 729 | + as the same URI, validators SHOULD raise an error condition. |
732 | 730 | </t>
|
733 | 731 | </section>
|
734 | 732 | <section title="Dereferencing">
|
|
0 commit comments