Skip to content

Commit 0e3ef5f

Browse files
authoredFeb 14, 2025
Merge pull request #1564 from json-schema-org/gregsdennis/contentSchema
clarify that contentSchema holds a subschema and when/how it applies
2 parents b23b791 + 87f6201 commit 0e3ef5f

File tree

1 file changed

+21
-8
lines changed

1 file changed

+21
-8
lines changed
 

‎specs/jsonschema-validation.md

+21-8
Original file line numberDiff line numberDiff line change
@@ -548,19 +548,32 @@ defined by [RFC 2046](https://www.rfc-editor.org/info/rfc2046).
548548

549549
### `contentSchema`
550550

551-
If the instance is a string, and if `contentMediaType` is present, this property
552-
contains a schema which describes the structure of the string.
551+
If the instance is a string, and if `contentMediaType` is present, this
552+
keyword's subschema describes the structure of the string.
553553

554554
This keyword MAY be used with any media type that can be mapped into JSON
555555
Schema's data model. Specifying such mappings is outside of the scope of this
556556
specification.
557557

558-
The value of this property MUST be a valid JSON schema. It SHOULD be ignored if
559-
`contentMediaType` is not present. Accessing the schema through the schema
560-
location IRI included as part of the annotation will ensure that it is correctly
561-
processed as a subschema. Using the extracted annotation value directly is only
562-
safe if the schema is an embedded resource with both `$schema` and an
563-
absolute IRI `$id`.
558+
The value of this property MUST be a valid JSON schema. The subschema is
559+
produced as an annotation.
560+
561+
Since `contentMediaType` is required to provide instruction on how to interpret
562+
string content, `contentSchema` SHOULD NOT produce an annotation if
563+
`contentMediaType` is not present.
564+
565+
Note that evaluating the `contentSchema` subschema in-place (i.e. as part of its
566+
parent schema) will ensure that it is correctly processed. Independent use of
567+
the extracted subschema (as returned in an annotation) is only safe if the
568+
subschema is an embedded resource which defines both a `$schema` and an absolute
569+
IRI `$id`.[^7]
570+
571+
[^7] Processing a non-resource subschema in place will ensure that any
572+
references (e.g. `$ref`) are always resolved properly. This isn't a problem when
573+
the subschema is itself a resource. See
574+
https://github.com/json-schema-org/json-schema-spec/issues/1381 for several
575+
examples where processing this subschema independently can cause `$ref`
576+
resolution failure.
564577

565578
### Example
566579

0 commit comments

Comments
 (0)
Failed to load comments.