Add default injection

[wassupxP]

Hi,
First of all, thank you for this library. The performance difference over pure Python jsonschema is massive, and it's made a real difference for us.

Unfortunately, we're missing two things that would make jsonschema_rs a complete solution rather than requiring a second post-processing layer. If this was already discussed (or is already present and I just didn't find it), I apologize.

1. Default injection

Fill missing instance keys from default values declared in the schema.
I guess this is a controversial topic, as this is discussed in multiple places already (e.g., https://www.learnjsonschema.com/2020-12/meta-data/default/ / https://python-jsonschema.readthedocs.io/en/stable/faq/#why-doesn-t-my-schema-s-default-property-set-the-default-on-my-instance ), but we believe it would be incredibly useful as an optional feature.

2. Schema metadata access - for keys that have default values.

Retrieve the sub-schema governing a given instance path - specifically to read custom annotation keywords on fields that may not even be present in the instance yet (because they'll be filled from default).
Our specific use case: we mark certain fields in the schema with is_path: true to indicate that their values are paths and should be normalized after validation. This works fine for fields the user actually provides - we can iterate over the annotations. But for fields that are absent and would be filled using the default values, there's no way to know which of those injected values are paths and which aren't, without walking the schema tree ourselves. If we had access to the part of the schema that's being used for the validation of the current instance, we could easily get that information.

[Stranger6667]

Hey!

Glad to hear you find this library useful :)

Re: defaults. While I recognize this could be a useful feature, I don't see it fit here.

On the Rust level it will be a breaking change - either due to accepting &mut Value and all the related aliasing restrictions, or due to another type with interior mutability. Alternatively there could be a separate API that does validation + injection, which is a huge amount of work & almost inevitable code duplication.

Besides a separate API with an explicit purpose I don't think it could work. The spec does not say much on this matter but I personally would be surprised if validation would do any modifications to my data (which does not reject the possible use cases).

I.e. I don't see the complexity inside the core library worth it over a post-processing pass separately.

As an idea: such second pass could possibly be a bit simplified by a custom default keyword that does not validate, but tracks instance locations for cases when a property is absent (or just path + value to set a-la JSON Patch). Then iterating over such patches & applying them could be cheaper than full traversal.

Re: Schema metadata access. What kind of API do you envision here? I am thinking if a custom is_path keyword would help - it contains some location metadata which may be useful

[wassupxP]

Defaults:

I honestly completely understand why this feature request would not be accepted, but I thought it was worth a try :).

Schema metadata access:

I think this goes hand in hand with the defaults discussion. If injection of defaults were supported directly, I could iterate over the evaluated schema and retrieve what I need without any manual evaluations (currently I am only able to iterate via annotations that are relevant to the current instance).

A few more notes:
I tried to “abuse” custom validators for the default and is_path keywords - similar to the approach suggested in the Python jsonschema library that we were using previously. However, I got stuck on things like dynamic keys, and it became unnecessarily complex.

Honestly, even with a post-processing pass in Python and manual schema evaluations, for my use case it is ~6 times faster than our previous implementation using jsonschema. :)