Skip to content

Commit f750cc3

Browse files
committed
Add new recursive schema example.
1 parent 8575e54 commit f750cc3

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
@@ -1595,6 +1595,15 @@
15951595
a reference to its own root, identified by the empty fragment
15961596
URI reference ("#").
15971597
</t>
1598+
<t>
1599+
For an example using these keyword, see appendix
1600+
<xref target="recursive-example" format="counter" />.
1601+
<cref>
1602+
The difference between the hyper-schema meta-schema in previous
1603+
drafts and an this draft dramatically demonstrates the utility
1604+
of these keywords.
1605+
</cref>
1606+
</t>
15981607
<section title='Dynamically recursive references with "$recursiveRef"'>
15991608
<t>
16001609
The value of the "$recursiveRef" property MUST be a string which is
@@ -3358,6 +3367,81 @@ User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0
33583367
</section>
33593368
</section>
33603369

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

0 commit comments

Comments
 (0)