Current status and future plans

[LecrisUT]

Is there an overview of the current status, e.g. what schema versions are supported, and if there are any future plans. Is the issue that nlohmann::json is a header-only library why this one was not incorporated directly there? Maybe it is worth testing the waters upstream since cmake has come a long way and header-only formats are starting to become unfashionable.

[pboettch]

Draft7 is supported. Due to a lack of time and motivation, there currently no plan that I'd work on other versions.

[LecrisUT]

Would you be able to make a break-down of the issues needed for the other drafts, mostly the big redesign roadblocks needed, e.g. the relative path parser.

[pboettch]

No, I don't know about the new versions of the standard and their specifics.

Relative path parsers is already an issue with this library.

[LecrisUT]

If we use the latest version of the test-suite, would it reflect all of the new specifications, relative path, etc.?

[pboettch]

No, because the standard (draft) version differ, so you cannot use a test-suite which is for Draft 2020-12 with a draft7 validator.

In my developments for draft4 and draft7 validator I always used the test-suite to then iteratively implement all needed features.

[LecrisUT]

Ok, maybe not the drafts version, but the test-suite repo version. I.e. within the draft, is it complete to cover all use-cases or are there some things that need to be implementation dependent

[pboettch]

In the test-suites there are test-suite for all standard-versions at the same time. You only select the right subdir to use.

[LecrisUT]

Indeed I understand that, I was asking of e.g. draft7 tests if itself is complete. I see that they are complete with respect to previous ones, e.g. both draft4 and draft7 have tests for AnyOf. But is each one complete in that they cover any logic, constraints, navigation, anything that you would encounter when designing and using a json schema? E.g. for the #ref syntax does it cover different types of path sources and all of the various places where #ref is legal to be used?

That is because there are individual issue test checks, but shouldn't those be accounted in the main branch of the test-suite?

[pboettch]

Indeed I understand that, I was asking of e.g. draft7 tests if itself is complete. I see that they are complete with respect to previous ones, e.g. both draft4 and draft7 have tests for AnyOf. But is each one complete in that they cover any logic, constraints, navigation, anything that you would encounter when designing and using a json schema? E.g. for the #ref syntax does it cover different types of path sources and all of the various places where #ref is legal to be used?

No, not everything is/was covered. Hence the issues I had over the years and fixes I had to do. A lot of $ref-stuff was not working correctly in early version of this library because of the test-suite being too nice. Now it's better, but I'm not sure it covers everything.

That is because there are individual issue test checks, but shouldn't those be accounted in the main branch of the test-suite?

Maybe. But some are specific to the C++ basic type limitations/ranges (uint64_t, double).

[pboettch]

Before doing any new work on the validator concerning newer drafts, maybe we should wait: https://json-schema.org/blog/posts/future-of-json-schema

[LecrisUT]

Wouldn't those still be built on top of the current drafts?

[pboettch]

Surely, but there will changes. No need to code stuff that'll be removed.