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.
-