Re: [Json] JSON Schema Language

[Anders Rundgren <[e-mail]>]

On 2019-05-07 00:38, Tim Bray wrote:
> 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.
+1
>
> 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.
+1
>
> 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.
+1
>
> 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.

Here we have a little problem.  There are already quite popular parsers out there flagging 3.0 as an invalid integer when explicitly parsing for an integer[*].  Personally, I consider this as right thing to do in a schema as well.  Letting one or two rotten eggs (=JSON serializers that output Numbers that also represent exact integers with fractions) set the bar for the other 99.9% doesn't seem right to me.

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

I don't think anybody is actually proposing that; only mapping things that doesn't have a specific representation in JSON like integers.

Anders

*] When for example deserializing JSON into a class definition ("unmarshalling") containing an integer property.

>
>
>
>
>
> On Fri, May 3, 2019 at 4:59 PM Ulysse Carion <[e-mail] <mailto:[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 <http://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] <mailto:[e-mail]> behind any given specification. Perhaps some other path
>     to specification exists?
>
>     With kind regards,
>     Ulysse Carion
>
>     _______________________________________________
>     json mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/json
>
>
> _______________________________________________
> json mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/json