Specification For Error Generation

[sinclairzx81]

Hi,

I'm just writing to ask if there is a specification (or guideline) for how JSON Schema validators should correctly handle validation error generation?

I am imagining a specification of this kind might specify a JSON Error structure (as JSON schema), and define a standard assertion order (for example, a validator should yield property required errors before additionalProperties: false errors) with assertion order tied to error generation order. A specification might also define a recommendation for handling anyOf type errors (which can generate large sequences of errors); it might also define a set of information encoded in the JSON Error structure to allow consumers to filter excessive error noise (common with anyOf errors with many sub variant schemas)

Are there any considerations for this? I note different validators implement error generation and reporting in a number of different ways, so just curious if there is a recommended assertion/generation order recommended by spec contributors.

Thanks!
S

[gregsdennis]

Thanks for the idea.

We currently specify the output in the core specification (section 12, I think). It has a lot of what structure and data is supposed to be there. There are also quite a few changes coming, so you may want to check the current document and issues/PRs with the output label.

The nested results are supposed to be in unordered arrays, so there's no priority between errors of different keywords.

Keywords are supposed to be evaluated independently, so it should be interpreted that errors/annotations are independent by keyword as well, although that's not explicitly stated.

[sinclairzx81]

@gregsdennis Hey, thanks for the follow up :) Ill keep an eye on the core spec as per suggestion.

Btw, Is there place where error generation / error standardization is being discussed? If there are considerations for standard errors, would be interested to read up on previous discussions to get a bit of historical insight on this aspect of the specification (or perhaps auxiliary specification?)

[gregsdennis]

Sure. Any issue or PR with the output label would be good to read. Also, there are a few things in the discussions (Community repo) discussing the more recent changes.

Regarding error messages, we intentionally don't specify error text. That's left to implementations to figure out. (For example, one major reason we don't is localization.) Implementations are encouraged to support customizing error messages, including localization, but it's not a requirement.