Skip to content

Commit 6342ec3

Browse files
committed
update note about processing contentSchema subschema in context
1 parent 8e0466f commit 6342ec3

File tree

1 file changed

+12
-4
lines changed

1 file changed

+12
-4
lines changed

specs/jsonschema-validation.md

Lines changed: 12 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -547,10 +547,18 @@ Since `contentMediaType` is required to provide instruction on how to interpret
547547
string content, the annotation schema produced by this keyword has no meaning if
548548
`contentMediaType` is not present.
549549

550-
Accessing the schema through the schema location IRI included as part of the
551-
annotation will ensure that it is correctly processed as a subschema. Using the
552-
extracted annotation value directly is only safe if the subschema is an embedded
553-
resource with both `$schema` and an absolute IRI `$id`.
550+
Note that evaluating the `contentSchema` subschema in-place (i.e. as part of its
551+
parent schema) will ensure that it is correctly processed. Independent use of
552+
the extracted subschema (as returned in an annotation) is only safe if the
553+
subschema is an embedded reource which defines both a `$schema` and an absolute
554+
IRI `$id`.[^7]
555+
556+
[^7] Processing a non-resource subschema in place will ensure that any
557+
references (e.g. `$ref`) are always resolved properly. This isn't a problem when
558+
the subschema is itself a resource. See
559+
https://github.com/json-schema-org/json-schema-spec/issues/1381 for several
560+
examples where processing this subschema independently can cause `$ref`
561+
resolution failure.
554562

555563
### Example
556564

0 commit comments

Comments
 (0)