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

[Nico Williams <[e-mail]>]

On Thu, May 30, 2019 at 08:53:50AM -0400, John Cowan wrote:
> 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.

And dynamic typing sucks.

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

You start with what you need and add new constraints as you discover
they would be useful.

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

ASN.1 has SDL, but no one uses it.  It turns out that SEQUENCE OF/
SEQUENCE/CHOICE is enough to avoid having to add an actual programming
language to do much more validation, with "business logic" getting
written as natural language text in a spec.

Mind you, I wouldn't mind a language for this, but it's a lot of work to
expect the IETF to do, so I wouldn't bother.  If there were enough
interest (there won't be), I suppose we could take inspiration from jq
(which is a functional programming language built around JSON) and write
an RFC for it or a language inspired by it.

> 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

Exactly.

> as double floats, since you can only count on that much precision and
> range anyway, and leave subtypes of number to general-purpose validation.

I wasn't proposing that numerics get decoded as whatever the schema
says.  Rather, that if you have a stack that uses a generic JSON decoder
then a validation pass might validate and coerce numeric values to
integers/whatever as needed.

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

It's perfectly fine for us to decide we don't need that feature.

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

Again, if we have consensus for such a contraint, we should include it,
and if not, not.  I was not making a detailed proposal, just proposing
that a schema language should be built around types and user-defined
types -- just like ASN.1.

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

The point about defining types is that you can express recursive
nesting, which is harder to do with by-example schemas.

Nico
--