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

[Phillip Hallam-Baker <[e-mail]>]

On Tue, May 24, 2016 at 9:07 PM, Austin William Wright <[e-mail]> wrote:

> 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.
>


Funny you should say that. This past couple of weeks I have resurrected the
GUI generator I built for X-Windows before working on the Web. [The new
version targets GTK as primary and will probably do Windows Forms and HTML
in due course]

Yes, there are similarities between the problems. In both cases you have an
abstract model and a presentation of that model, a View for the UI and a
serialization for JSON. Yes, if one had the problem of producing both, you
could share a lot of code. But not so much as you might expect.

A GUI is a Model-View-Controller app and unlike the problem of
serializing/deserializing JSON, you have to do a lot of validation on the
inputs. In particular you need to be able to validate a dialog box when the
user hits 'Accept' and tell them where they went wrong. You also need to be
able to support 'cancel'.

In short, it ends up as a very much more involved problem if you are going
to do it right. XML is as complex as it is because it supports features
that allow text editors to validate input as people type. And JSON is
simpler because it does not support those features. And if you try to turn
JSON into XML you will probably end up with something almost as complex.