Skip to content

Commit 48f3f5f

Browse files
committed
Add new recursive schema example.
1 parent a2df8f9 commit 48f3f5f

File tree

1 file changed

+84
-0
lines changed

1 file changed

+84
-0
lines changed

jsonschema-core.xml

Lines changed: 84 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1603,6 +1603,15 @@
16031603
a reference to its own root, identified by the empty fragment
16041604
URI reference ("#").
16051605
</t>
1606+
<t>
1607+
For an example using these keyword, see appendix
1608+
<xref target="recursive-example" format="counter" />.
1609+
<cref>
1610+
The difference between the hyper-schema meta-schema in previous
1611+
drafts and an this draft dramatically demonstrates the utility
1612+
of these keywords.
1613+
</cref>
1614+
</t>
16061615
<section title='Dynamically recursive references with "$recursiveRef"'>
16071616
<t>
16081617
The value of the "$recursiveRef" property MUST be a string which is
@@ -3379,6 +3388,81 @@ User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0
33793388
</section>
33803389
</section>
33813390

3391+
<section title="Example of recursive schema extension" anchor="recursive-example">
3392+
<figure>
3393+
<preamble>
3394+
Consider the following two schemas describing a simple
3395+
recursive tree structure, where each node in the tree
3396+
can have a "data" field of any type. The first schema
3397+
allows and ignores other instance properties. The second is
3398+
more strict and only allows the "data" and "children" properties.
3399+
An example instance with "data" misspelled as "daat" is also shown.
3400+
</preamble>
3401+
<artwork>
3402+
<![CDATA[
3403+
// tree schema, extensible
3404+
{
3405+
"$schema": "https://json-schema.org/draft/2019-08/schema",
3406+
"$id": "https://example.com/tree",
3407+
"$recursiveAnchor": true,
3408+
3409+
"type": "object",
3410+
"properties": {
3411+
"data": true,
3412+
"children": {
3413+
"type": "array",
3414+
"items": {
3415+
"$recursiveRef": "#"
3416+
}
3417+
}
3418+
}
3419+
}
3420+
3421+
// strict-tree schema, guards against misspelled properties
3422+
{
3423+
"$schema": "https://json-schema.org/draft/2019-08/schema",
3424+
"$id": "https://example.com/strict-tree",
3425+
"$recursiveAnchor": true,
3426+
3427+
"$ref": "tree",
3428+
"unevaluatedProperties": false
3429+
}
3430+
3431+
// instance with misspelled field
3432+
{
3433+
"children": [ { "daat": 1 } ]
3434+
}
3435+
]]>
3436+
</artwork>
3437+
</figure>
3438+
<t>
3439+
If we apply the "strict-tree" schema to the instance, we will follow
3440+
the "$ref" to the "tree" schema, examine its "children" subschema,
3441+
and find the "$recursiveAnchor" in its "items" subschema.
3442+
At this point, the dynamic path is
3443+
"#/$ref/properties/children/items/$recursiveRef".
3444+
</t>
3445+
<t>
3446+
The base URI at this point is "https://example.com/tree", so the
3447+
"$recursiveRef" initially resolves to "https://example.com/tree#".
3448+
Since "$recursiveAnchor" is true, we examine the dynamic path to
3449+
see if there is a different base URI to use. We find
3450+
"$recursiveAnchor" with a true value at the dynamic paths of
3451+
"#" and "#/$ref".
3452+
</t>
3453+
<t>
3454+
The outermost is "#", which is the root schema of the "strict-tree"
3455+
schema, so we use its base URI of "https://example.com/strict-tree",
3456+
which produces a final resolved URI of
3457+
"https://example.com/strict-tree#" for the "$recursiveRef".
3458+
</t>
3459+
<t>
3460+
This way, the recursion in the "tree" schema recurses to the root
3461+
of "strict-tree", instead of only applying "strict-tree" to the
3462+
instance root, but applying "tree" to instance children.
3463+
</t>
3464+
</section>
3465+
33823466
<section title="Working with vocabularies">
33833467
<section title="Best practices for vocabulary and meta-schema authors">
33843468
<t>

0 commit comments

Comments
 (0)