dynamicAnchor behaviour #362
-
Context
SamplesSample
|
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 69 replies
-
Sample 2 is a valid schema, but the They are not equivalent. |
Beta Was this translation helpful? Give feedback.
-
Yes, that is the purpose of JSON Schema. Any implementation of JSON Schema should be able to read any kind of schema written by others. That's what a JSON Schema implementation is. We're getting a bit off topic here, but I would like to learn more about what existing implementations don't provide that you need. |
Beta Was this translation helpful? Give feedback.
-
So, what I understand so far about "$dynamicAnchor" is this: when a
I explained why I was thinking that the |
Beta Was this translation helpful? Give feedback.
-
Technically, yes, but there's is no good reason for a schema author to do so. I expect that to change in a future release so that you can only reference a dynamic anchor with a dynamic reference.
No
Yes. In fact, there's no reason to use a dynamic reference if it's not expected to resolve to external resource in at least some cases.
As you are evaluating a schema, you may end up in multiple schema documents as you follow references. At the time the dynamic reference is evaluated, any schema documents that you've visited while evaluating the schema up to that point is in scope. We call this set of visited schemas the "dynamic scope". So, to answer the question directly, the dynamic reference in
Throw an error.
Throw an error. |
Beta Was this translation helpful? Give feedback.
-
There is a way to enforce the correct behaviour. A very nice one... You can combine the functionalities of // tree schema, extensible {
"$id": "https://example.com/tree",
"$anchor": "_node",
"type": "object",
"properties": {
"data": true,
"children": {
"type": "array",
"items": {
"$ref": "#_node"
}
}
}
} // strict-tree schema, guards against misspelled properties {
"$id": "https://example.com/strict-tree",
"$anchor": "_node",
"$ref": "tree",
"unevaluatedProperties": false
} Having the functionalities combined would be 100% garantied that a dynamic reference cannot access a regular anchor and a regular reference would not access a dynamic anchor. From the performance perspective would also be a gain because unwanted anchors are excluded automatically from search. This technique is also used in other dynamic searches like text fragment which uses a prefix after |
Beta Was this translation helpful? Give feedback.
-
The quote is from selected answer. I think I got this very wrong. You were talking (as I understand now) about a single {
"$id": "http://example/first",
"properties": {"...":"..."}
} {
"$id": "http://example/first/second",
"properties": {"...":"..."}
} This would be a totally different thing since in a dynamic scope could end up even hundreds of records in that lookup table, while if is just a single There are some extra questions now... |
Beta Was this translation helpful? Give feedback.
Technically, yes, but there's is no good reason for a schema author to do so. I expect that to change in a future release so that you can only reference a dynamic anchor with a dynamic reference.
No
Yes. In fact, there's no reason to use a dynamic reference if it's not expected to resolve to external resource in at least some cases.
As you are evaluating a sc…