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

[Pete Cordell <[e-mail]>]

On 30/05/2019 13:53, John Cowan wrote:
> On Wed, May 29, 2019 at 4:24 PM Nico Williams <[e-mail] 
> 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?

The JCR solution to this type of problem is to be able to have an 
annotation that associates a URI with a primitive type to indicate it's 
internal format. e.g.

    "size" : @{format org.iso.shoe-size} string,

(http://json-content-rules.org/drafts/json-content-rules-10.html#rfc.section.6.11.6)

As far as JCR is concerned, this merely captures the format of the data. 
Whether it's the low-level validators job to validate the type or 
higher-layer functionality is a decision for the individual 
implementation's developer(s).

Same with strings specified with regular expressions. The validator can 
just treat it as a string and leave it to a higher layer, or it can be a 
deluxe validator and check the pattern matches.  (The latter might be 
more useful for a generic on-the-wire monitoring type scenario.)

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

We had a play with that sort of thing. Mainly as a proof-of-concept that 
the extensibility enabled by JCR's feature had sufficient mileage in it.

http://json-content-rules.org/drafts/draft-cordell-jcr-co-constraints-00.txt

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

In addition to code, I think a key 'parser' of schemas is human 
developers. That's why we wanted JCR compact and concise. If the human 
developer is able to immediately see the constraints in the schema, and 
not have to wade through pages of prose, I think things are likely to 
work much better.

Pete.
-- 
---------------------------------------------------------------------
Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers, http://codalogic.com
Read & write XML in C++, http://www.xml2cpp.com
---------------------------------------------------------------------