Giter Club home page Giter Club logo

Comments (2)

passchieri avatar passchieri commented on July 21, 2024

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.

from jsonschema-gentypes.

passchieri avatar passchieri commented on July 21, 2024

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?

from jsonschema-gentypes.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.