Accessing Limited Node Members of JSONSchema for Traversal

[TieWay59]

Hello @Stranger6667, I appreciate your work on JSONSchema.

In the current implementation of JSONSchema, the node member is marked as pub(crate), unfortunately limiting its accessibility. I understand that this is likely done for encapsulation and safety reasons, but for my use case, I need to traverse and potentially manipulate the internal structure of the JSONSchema to perform some custom processing.

Here is the relevant code snippet:

pub struct JSONSchema {
    pub(crate) node: SchemaNode,
    config: Arc<CompilationOptions>,
}

I am wondering if there is a recommended approach or an existing method within the library that allows for traversal or access to the private node members of JSONSchema? If there is a way to achieve this without directly exposing the internals, that would be ideal for maintaining the integrity of the library's design.

Alternatively, if it's possible to provide a public API or method that facilitates the traversal of the JSONSchema tree structure, that would be incredibly helpful for my project.

My use case involves iterating over the private node members of JSONSchema to dynamically create forms that are reflective of the schema's structure. I understand that these members are currently private for encapsulation and safety reasons, but I am seeking a way to access them for form generation. I understand this might be an edge case, but I believe it could benefit others who may have similar requirements in the future. Any guidance or suggestions on this matter would be greatly appreciated.

Thank you in advance for your time and help.

[Stranger6667]

Hi @TieWay59

Thank you for opening this issue! At the moment, I am working on a complete rewrite of this crate so the internals will change a lot. However, I'll take your request into account.

[TieWay59]

@Stranger6667 Thank you for your quick reply.

If you have time, could you pls check this out https://docs.rs/taplo/0.13.0/taplo/parser/struct.Parse.html?

This is how Taplo builds its TOML parser lib. And they choose a pub syntax tree structure for storing the data.

[Stranger6667]

That makes sense!

You'd need mutable traversal, right? I.e. having some iter & iter_mut would work?
I am not entirely sure yet, whether I'd store annotations together with the main tree (likely yes), so in the end, it could be validator.nodes().iter() and validator.nodes().iter_mut().

What do you think?

[TieWay59]

LGTM. Thank you for sharing this detail. I am looking forward to seeing the new rewrite.

I'm doing my free time side-project so that I can wait. I don't mean to cause any anxiety on you. ❤

Lately, I've been trying Tree-sitter rust binding for some tree edit feature. I checked json schemas code, you don't use a Tree-sitter (maybe for better performance I guess.) Good luck to you.

[Stranger6667]

Thanks!
I’ll be happy if the new rewrite will serve your needs!

This library currently relies on serde_json::Value, so the parsing itself is outside of its scope - the rewrite will be accepting a more generic input so it will be possible to implement a custom trait to work with some other input types, likely including raw bytes, etc. The aim with the internal structure is to use an ID-tree backed by a single vector, so it has a better cache locality during traversal (something like https://github.com/causal-agent/ego-tree). I hope you find these details useful :)

[TianzeMYou]

Hello @Stranger6667

I am wondering how this rewrite will be published. Is it going to deprecate the current jsonschema or will it just be a new version? How does the timeline look like?

[Stranger6667]

@TianzeMYou

Thank you for pinging!

I am working on it in parallel, in a separate repo. At some point, I am going to move those development here, and probably there will be some breaking changes, I'll try to minimize it, but I think there are some issues with the current API that should be addressed.

Meanwhile, I am somewhere in the middle of an article that describes the new API, so there will be the possibility to discuss the upcoming changes.

I don't have the exact timeline, as it is my side project at the moment, but I plan to focus on jsonschema after I get back from vacation around mid-April.

[TianzeMYou]

Thanks for the response @Stranger6667 !

Hope you enjoyed your vacation! Please keep me updated on the article about upcoming changes, and if the timeline becomes more concrete. Looking forward to hearing from you :)

[Stranger6667]

@TianzeMYou

At this point I am pretty satisfied with the API, you can take a look here in README - https://github.com/Stranger6667/jsonschema

Maybe a few concerns about the presence of jsonschema::Validator but I am going to resolve them soon.

The next step would be resolving all references & building the validation graph.

I'll open a discussion here in this repo so you can leave your feedback on the API.

Edit: Discussion - #475