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

[Nico Williams <[e-mail]>]

On Wed, May 29, 2019 at 03:14:43PM -0400, John Cowan wrote:
> The trouble is that "validation" is a very vague term.  I would be happy
> with a language that can only express simple type validation, minimally as
> follows:

Validation, to me, means making sure that the "shape" of a value adheres
to the "shape" given by the schema.

Examples:

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

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

That's it for validation.

Now, validation mostly should only happen at decode time.

In a language like JS (or jq) you might first parse the whole JSON text
and then validate its "shape".

> 0) JSON values are divided into types, namely null, numbers, strings,
> booleans, object types, and arrays of any of these.
> 
> 1) An object type specifies what attributes the corresponding object has
> and what the types of the corresponding values are, or else specifies that
> it may have arbitrary keys and values.   It may have a name in the schema
> language
> 
> 2) When an array is expected, the validator will check that all its
> contents have the same specified type.
> 
> 3) There is a way to specify for a given object type whether it must
> contain exactly the specified keys, may contain a superset of the specified
> keys where the additional keys are not checked, or may contain a subset of
> the specified keys.

So far it sounds a lot like ASN.1.

> Here is a very simple examplotron language:
> 
> Sample document from json.org:
> 
> {"menu": {
>   "id": "file",
>   "value": "File",
>   "popup": {
>     "menuitem": [
>       {"value": "New", "onclick": "CreateNewDoc()"},
>       {"value": "Open", "onclick": "OpenDoc()"},
>       {"value": "Close", "onclick": "CloseDoc()"}
>     ]
>   }
> }}
> 
> Corresponding schema (constructed by hand, may have errors):

I would prefer a schema language built around defining types, where
user-defined types have to be a) JSON types with b) optional
constraints.

Regarding (a), we're going to need a discriminated union, something JSON
doesn't have as such, but obviously is trivial to build by convention.

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

My counter:

  top_level : choice(file_menu, edit_menu);
  file_menu : object{"menu"->file_menu_contents};
  edit_menu : object{"edit_menu"->edit_menu_contents};
  file_menu_contents := object{
    "id":"file", /* this means this must be present with this value */
    "value":"File",
    "popup": object { ... }
  };

You can see the above has a hint of ASN.1 flavor, greatly simplified and
somewhat transformed to be sure.

I don't care one bit about the specifics of the syntax other than: it
should be easy to build parsers for it.

But I do very much like the idea of a schema language built around
defining types.

Nico
--