Re: [Json] JSON Schema Language

[Tim Bray <[e-mail]>]

Hi all.  I haven't got around to reading the draft (but will soon).  Prior
to that, a few notes:

1. I'm pretty sure that we need something better than what we have in the
area of JSON schemas.  At least, I'm 100% sure that my job at Amazon Web
Services would be easier, and our customer experiences would be more
pleasant, if we had something.

2. One thing schemas are useful for is to syntax-check JSON texts that
claim to conform to some language specification or another. Obviously no
schema can ever completely satisfy this requirement - there are always
things in specifications which are semantic and not addressable by schemas
- but they can still be super useful.

3. Another thing they are useful for is for providing help to developers
working in strongly typed programming languages. With a well-built schema
it is reasonably straightforward to auto-generate nice idiomatic class
declarations in modern programming languages, and also to build
serializers/deserializers that will move data back and forth between JSON
blobs and programming-language constructs, or fail in a clean deterministic
way if the JSON fails to match the schema.

I mostly fail to understand the debate about jq and integers and so on.
Clearly, the following is a valid JSON text and will be parsed successfully
by any JSON parser.

{
  "foo": 3.0
}

I imagine that most schema-driven software would first deserialize it into
a tree, probably something like Jackson ObjectMapper's JsonNode, and then
apply schema constructs to the tree.   I would hope that a sane schema
would accept this whether a top-level "foo" was required to be an integer
or double or most other flavors of number, and reject it if "foo" was
required to be a string or boolean.

Put another way, no JSON schema spec can change the definition of what JSON
is, or make the built-in type system anything but what it is.





On Fri, May 3, 2019 at 4:59 PM Ulysse Carion <[e-mail]> wrote:

> Hello all,
>
> I have recently published an I-D for what I'm calling JSON Schema
> Language, a way to validate JSON data's shape, and generate code
> (i.e., types, classes, docs, etc.) from that shape:
>
> https://tools.ietf.org/html/draft-json-schema-language-00
>
> In previous correspondence with this list, Carsten Bormann has noted
> that this WG has hesitated to prematurely adopt any given proposal,
> preferring to let them develop until their distinct applications
> become clear.
>
> It is my belief that JSON Schema Language does have a clear use-case,
> one which Tim Bray has articulated clearly here:
>
> https://www.tbray.org/ongoing/When/201x/2018/09/22/JSON-scheming
>
> I believe JSON Schema Language solves precisely what Tim describes,
> while eschewing his concerns with the json-schema.org project.
>
> For those inclined toward the concrete, the bottom of this page
> contains a live demo of JSON Schema Language using the TypeScript
> implementation:
>
> https://json-schema-language.github.io/
>
> The project's GitHub organization also contains the source for a Rust
> and TypeScript implementation, as well as a full test suite:
>
> https://github.com/json-schema-language
>
> With Carsten's note in mind, does there nevertheless exist a path for
> JSON Schema Language, or something like it, to become an RFC? I
> appreciate the desire to avoid premature adoption by this WG. I assume
> this partially stems from caution around throwing the weight of
> [e-mail] behind any given specification. Perhaps some other path
> to specification exists?
>
> With kind regards,
> Ulysse Carion
>
> _______________________________________________
> json mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/json
>