Documenting ValidationMessage.path format

[chuwy]

Hello there!

This is both a question and a proposal (although duplicate of https://github.com/networknt/json-schema-validator/issues/58).

I'm assuming json-schema-validator would not produce ValidationMessages with path properties following the most exotic JSONPath features such as $..book[-1:], $..book[?(@.price<10)] etc. In my experience the library provides the most basic pointers like:

• $.book.title
• $.books[2].title

Which kind of make sense since things like $..book[-1:] exist for querying data (so we don't know what's in the target JSON). And the Validator only points to data (we do know what and where we want to point to).

The question: is there anything that would confirm my hypothesis about only most basic types of JSONPath supported by the Validator? I couldn't find anything in the test suite because it's mostly about validation and has nothing about paths. I'm asking because I'm writing a small parser for ValidationMessage.path and would like to know how far should I go with JSONPath implementation. Are there any additional constructs I need to be aware of?

The proposal (more as food for thoughts obviously): I agree with @ehrmann on https://github.com/networknt/json-schema-validator/issues/58#issuecomment-358119324. JSONPath is very powerfull, but with great power comes great responsibility and I don't think that the Validator needs it. Writing a parser for super simple JSON Pointer is a piece of cake even when I want 100% features coverage, writing a parser for JSONPath is almost like writing a parser for a programming language with tons of undodocumented features and corner cases.

[stevehu]

@chuwy The JSON schema spec team seems to be moving to the JSONPointer these days and it gave a lot of headache for the implementation teams. Personally, I would prefer the JsonPath syntax but wondering if we should follow the direction from the spec team.

https://json-schema.org/draft/2019-09/relative-json-pointer.html

[chuwy]

Yup, that's one more point. Basically, I see pros as:

• Being more standard-compliant
• Using more wide-spread format (subjectively)
• Being able to reason about format as it's much simpler

The only con I see is that it's less powerful, but again I don't think anyone ever needs the query power of JSONPath in validator.

Also, do you mind confirm my hypothesis that json-schema-validator only produces those simple kinds of path I listed?

[stevehu]

Yes. I can confirm that we only use simple paths. There are several issues opened trying to address the issue that context is not very clear in the path when nested schemas are used.