diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 5343194f..dfdafe13 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1392,7 +1392,10 @@ RFC 3986 section 5.1.2 regarding encapsulating entities, if an "$id" in a subschema is a relative IRI-reference, the base IRI for resolving that reference is the IRI of - the parent schema resource. + the parent schema resource. Note that an "$id" consisting of an empty IRI or + of the empty fragment only will result in the embedded resource having + the same IRI as the encapsulating resource, which SHOULD be considered + an error per section . If no parent schema object explicitly identifies itself as a resource @@ -1456,11 +1459,21 @@ fragment "#foo" when used in a IRI. See below for full examples. + + +
+ + A schema MAY (and likely will) have multiple IRIs, but there is no way + for an IRI to identify more than one schema. When multiple schemas + attempt to identify as the same IRI through the use of "$id", "$anchor", + "$dynamicAnchor", or any other mechanism, implementations SHOULD raise + an error condition. Otherwise the result is undefined, and even if + documented will not be interoperable. + - The effect of specifying the same fragment name multiple times within - the same resource, using any combination of "$anchor" and/or - "$dynamicAnchor", is undefined. Implementations MAY - raise an error if such usage is detected. + Note that due to the semantics of JSON Pointer fragments, schema IRIs + that differ only by the presence or absence of an empty fragment MUST + be considered duplicates.
@@ -1671,11 +1684,6 @@ be noted within a schema document as it is processed, producing associations as shown in appendix . - - A schema MAY (and likely will) have multiple IRIs, but there is no way for a - IRI to identify more than one schema. When multiple schemas try to identify - as the same IRI, validators SHOULD raise an error condition. -