Re: [Json] JSON Schema Language

[Nico Williams <[e-mail]>]

On Mon, May 06, 2019 at 09:32:13AM +0200, Carsten Bormann wrote:
> On May 6, 2019, at 09:22, Austin Wright <[e-mail]> wrote:
> > But also, why not build a parser that uses a schema to influence how
> > values are parsed?

Because some of us have generic parsers with associated DSLs and we
don't want to be left out.

Specifically, in my case, jq https://stedolan.github.io/jq -- something
of an XSLT/XPath for JSON.

It's perfectly reasonable to build a jq application that adheres to a
JSON schema, but it's not reasonable to expect the jq encoder to know to
do encoding in context-specific ways -- the jq encoder is too generic
and divorced from the rest of the jq machinery to possibly be able to do
that.

By pursuing a schema design that requires context-specific parsing or
encoding behaviors, though you could say that the result looks like
JSON, it precludes use of existing JSON tooling such as jq.

Substitute ECMAScript for jq if you like -- the result is the same.

I strenuously object to this sort of schema.

As a maintainer of jq, I wouldn't know what to say to users who then
complain about non-interop with such a schema other than to point to
this thread and blame the people who allowed it to happen.  But the
damage to jq would be real and unavoidable.  To avoid that damage, if I
cannot convince you, then I assure you that I would appeal any finding
of consensus for such a schema design.

I'm sorry, but 10.0 is perfectly acceptable as an integer, and MUST be
accepted as an integer when you expect an integer even if the JSON RFC
says encoders SHOULD NOT include zero fractional parts.

I would suggest that if you have a schema that says "and this is an
integer", the schema MUST accept zero fractional parts, and SHOULD let
you specify what to do if a non-integer real number is parsed for that
field (e.g., truncate the fractional part, floor, round).

> That is exactly what most of the members of this WG are afraid of when
> the talk comes to “schemas”.

+1

> XML (and later JSON) learned one thing from the problems of SGML:
> schema-oblivious decoders are more robust than schema-depending ones.
> (They are, in the first place, and protocol evolution only amplifies
> this.)

Not only that!

Can you imagine using XSLT/XPath if some XML schema requires different
parsing behavior for different elements?!  It wouldn't be possible to do
that *and* still be able to use XSLT/XPath because XSLT/XPath processors
generally have a built-in generic XML parser.  It would destroy the
utility of XSLT/XPath!

And that proves that an XML schema of that sort... would yield something
that is NOT XML, but merely looks like XML.

The same exact reasoning applies in the case of JSON.  The only
difference being that JSON doesn't [yet] have a standard equivalent to
XSLT/XPath, but since generic parsers and encoders exist, and since
node.jq, JavaScript, ECMAScript, jq, and such exist, the point stands.

> > Suppose you have a dynamically typed language, and want to parse
> > some value, e.g. sometimes as an int, sometimes as a bignum,
> > depending on the property. You might provide a JSON Schema to
> > specify this behavior.
> 
> There goes the generic decoder.
> 
> (There is nothing wrong with using a “schema” to specify upconversion
> from the JSON data model to your application data model.  What I’m
> objecting to is getting rid of JSON and replacing it with a gazillion
> dialects that happen to be syntactically compatible with JSON but the
> semantics of which are controlled by a “schema” mechanism.)

+1.

Nico
--