Lookup references from referenced file

[leonhardpetzel]

I found, that looking up $defs in a file referenced by another file uses the original resolver and the uri designator does not get prefixed.
Attached a minimal example.

Here the most usefull part of the exception:

referencing.exceptions.PointerToNowhere: '/$defs/def_child' does not exist within {'$schema': 'https://json-schema.org/draft/2019-09/schema', 'type': 'object', 'properties': {'child': {'$schema': 'https://json-schema.org/draft/2019-09/schema', '$defs': {'def_child': {'type': 'object'}}, 'allOf': [{}]}}, 'required': ['child']}

minimal_example.zip

[passchieri]

I encountered the same issue. I think its because the child is not stored as an individual Resource in the Registry, which makes that in-file references are taken to be relative to the main schema, instead of the child schema.

I created a solution that allows referencing by id, instead of filename, and preload all sources in the registry. See pull request #946

Its not exactly solving the issue caused by in-file references in a child, but by converting all reference from reference by filename to reference by $id, the problem is prevented. You could actually use the filename as the id (by defining an $id parameter in each file), but that might be a bit confusing.

As an extension to my solution, all files could be added to the registry with a uri derived from the relative file location from the main source. Currently, all files are registered by the exact filepath provided, so its not attempted to construct the relative path between the main source an all other sources. For some common situations (e.g. all files in the same folder), its relatively simple, but to make a reliable and robust implementation, its required to all paths in some canonical form, and perform all file matching on these canonical names. This Would probably require modifications to package referencing, which is out of scope for me.

[passchieri]

I try to understand better the design choices made in the current implementation of the RefResolver. If I look at the Resolver from the referencing package, it returns a Resolved object from a call to resolver.lookup. This contains both the resolved schema, and a new Resolver that can be used for subsequent lookups in the same context. I have the impression that this is the cause for the failure of looking up relative references from an externally referenced source, as the RefResolver tries to resolve the relative references relative to the root, instead of relative to the child.

If this is true, one way to solve this, is to implement the same type of logic in the RefResolver as in the referencing.Resolver, i.e. return Resolved objects that include a new resolver from the lookup function. But I suspect that has a major impact on the whole system, as it would not only affect RefResolver, but also the API classes.

Or would there be a more localized solution to support relative references from referenced files?