Skip to content

Commit ef68f56

Browse files
committed
update note about processing contentSchema subschema in context
1 parent d1c8642 commit ef68f56

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
@@ -546,10 +546,18 @@ Since `contentMediaType` is required to provide instruction on how to interpret
546546
string content, the annotation schema produced by this keyword has no meaning if
547547
`contentMediaType` is not present.
548548

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

554562
### Example
555563

0 commit comments

Comments
 (0)