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

[Austin William Wright <[e-mail]>]

I also use them as specification aids, I think JSON Hyperschema is a great
tool to make JSON APIs become RESTful (because it's self-documenting).

I also use them for validation and sanity checking, like an assert() call:
It's not something that should ever trip, but it's there in case the
impossible happens (but that would never happen, right?).

I agree with your opinion it's troubling, though. Unfortunately it's hard
to strike a balance between making something that's easy to compose and
easy to read, versus something that's expressive and gives you exactly the
right error message.

I'd love to talk how to fix this problem, though!

It seems like this problem is closely tied with automatic UI generation.
How would I design a form to enter data of the kind that you're expecting?
Three separate forms? A master drop-down that automatically changes the
remaining fields and automatically populates the "Type" one? Move the
"Type" drop-down first, and change all the other fields if it changes? What
if I want to change the type of an entity from Vegetable to Plant? It seems
if we can answer these questions, we would also tackle your validation
errors problem for free.

Austin.

On Mon, May 23, 2016 at 8: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?
>
> If so, then what are schemas for?  I’ve seen them as having two uses:
>
> 1. Specification aids
> 2. Debugging aids
>
> For #1, I see schemas as a poor second-best to clear human-readable
> description.
> 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?”)
>
>
>
>