Re: [Json] Another problematic JSON Schema use-case

[Andrew Newton <[e-mail]>]

On Mon, May 23, 2016 at 11:54 PM, Tim Bray <[e-mail]> wrote:
> Hmm, I have to excerpt one line here:
>
> On Mon, May 23, 2016 at 6:30 PM, Austin William Wright <[e-mail]> wrote:
>>
>>
>> In general, JSON Schema and many other schemas are designed to ensure
>> things are valid. They're not well engineered to help people fix things when
>> they're invalid.
>
>
> I find this troubling.  I expect modern compilers to give me highly
> actionable errors, with line numbers. Is the nature of JSON DSL’s and
> programming languages so deeply different that this is not a reasonable
> thing to ask a schema processor to do?

It's not too much to ask, but the problem may be with the JSON parser.
Many parsers ingest JSON and give back native data structures, which
is what makes JSON simple for most people. But a validator needs
context that a typical JSON parser does not provide.

>
> If so, then what are schemas for?  I’ve seen them as having two uses:
>
> 1. Specification aids
> 2. Debugging aids

While not typical, being malleable enough to aid the creation of
testing harnesses is a great third use.

>
> For #1, I see schemas as a poor second-best to clear human-readable
> description.

In my experience, many non-English readers greatly benefit from a
formal syntax. And depending on the complexity of the problem, prose
cannot strike the right balance between precision and TLDR.

> For #2, Schemas are appealingly declarative and presumably much more compact
> than the equivalent declarative code.  But if they can’t tell me what the
> problem is, why bother?  And furthermore, I’ve never thought validators
> could rely on schemas alone, because schemas can’t check semantic
> constraints (“is that a valid part number?”)

Certainly they are no replacement for application logic, but I don't
think anybody ever made that claim.


-andy