Re: [Json] A minimal examplotron-style JSON validation language.

[John Cowan <[e-mail]>]

On Wed, May 29, 2019 at 4:24 PM Nico Williams <[e-mail]> wrote:

 - if, where you expect an array you see a boolean, that's an error
>

Agreed,, because statically typed programming languages can't cope.


> - where you expect a numeric value you might have some constraints
>    (e.g., range constraints) that, again, should raise an error if not
>    met
>

>  - ditto strings ('must be bas64', 'must be one of these (enum)', 'must
>    match some regexp', etc.).


The question is, where do you stop?  Range constraints are all very well,
but suppose you want to constrain a number value to be a U.S shoe size,
which is either an integer (in a certain range) or an integer plus 0.5?
What is more, the valid values of one field often depend on the actual
value of one or more other fields, and so you end up designing a whole
(functional) programming language.

But in general we expect JSON to be consumed by a program written
in some such language anyway.  So we might as well decode all numbers
as double floats, since you can only count on that much precision and
range anyway, and leave subtypes of number to general-purpose validation.
By the same token, I don't see that it makes sense to put a whole
regular expression subsystem into the validator when it can often
be expressed much more clearly in code (especially in languages
that have a combinator rather than a string representation of
regular expressions).

Actually, I'll amend my proposal to inclde integers, given how
important they are.  This is easily accomplished by using, say,
0 (equivalently 0.0) to designate an integer and 0.5 to designate a float.)

Using JSON itself as the language for the schema is nice because
> you don't need to build a partser for the schema.  But it's not very
> nice for users, so I'd prefer to have some non-JSON syntax for the
> schema.
>

I don't care about the syntax, but examplotron-style (in which a
type designation is an instance of what it designates) is a strong
design constraint, which is why I adopted it.  I have no problem
with a BNF-style syntax for practical use, like RNG compact syntax.


John Cowan          http://vrici.lojban.org/~cowan        [e-mail]
Assent may be registered by a signature, a handshake, or a click of a
computer
mouse transmitted across the invisible ether of the Internet. Formality
is not a requisite; any sign, symbol or action, or even willful inaction,
as long as it is unequivocally referable to the promise, may create a
contract.
       --Specht v. Netscape