|
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 <xreftarget="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