Subject: [Json] JSON Schema Language is nearly done

From: Ulysse Carion <[email-masked]>
Date: Sun, 21 Jul 2019 20:37:09 -0700

Hi all,

I've just submitted an I-D of JSON Schema Language:

https://tools.ietf.org/html/draft-json-schema-language-02

I believe this iteration is suited to be the penultimate draft; I see no
features in this spec worth adding, nor any features worth removing. I know
of a few minor problems with the language in the spec, and those issues are
tracked on GitHub here <https://github.com/json-schema-language/spec/issues>
.

In this draft, I introduced fine-grained numerical types -- "float32",
"float64", "int8", "uint64", etc. -- because they are immensely useful for
real-world code generation. The spec details these types here
<https://tools.ietf.org/html/draft-json-schema-language-02#section-3.3.3>
(Table 2). "float32" and "float64" have no effect on validation versus
"number", but they do signal intent, and act as a hint for code generators.

The question of JSON integers has been contentious in the past -- I
explicitly call out that 10.0 is considered a fine "int8". I did this out
of the robustness principle, and the fact that the alternative (considering
10.0 unacceptable) is one which fewer will be able to enforce. Some
implementations may in practice be more restrictive in what they accept
than the spec describes. I think that's acceptable; it seems clear that
either approach will lead to people deviating from the spec.

Let me know what y'all think about JSON Schema Language as a whole! If you
relish in the concrete, here are working implementations of validators
built on this iteration of JSON Schema Language:

https://github.com/json-schema-language/json-schema-language-go
https://github.com/json-schema-language/json-schema-language-typescript
https://github.com/json-schema-language/json-schema-language-rust

The GitHub org also contains tooling built on JSL, but they have not been
updated to support the fine-grained numerical types yet. I'll be working on
that soon.

I view JSL as being nearly complete, so any and all criticism is most
welcome.

Thanks,
Ulysse

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 22 Jul 2019 07:37:12 -0400

Thanks.  At the hackathon, as part of the WISHI work on model translation, I started a tool that can translate json-schema-org definitions into CDDL.  I probably won’t have time to complete it this week, but I’ll sure add a translation function into CDDL for JSL to the tool.  Doing the inverse is more interesting (pretty much pattern recognition), but I think it can (and should) be done as well.

The exercise is useful in itself, but it also can be used to assess the level of bizarreness of a data definition language.  The translations in

https://mailarchive.ietf.org/arch/msg/json/1WpdpfsXr3gEIdXb8OV0R_J-O4E

demonstrated that the version of JSL we had at the time has a quite low level of bizarreness, measured from the vantage point of CDDL.

Grüße, Carsten

> On Jul 21, 2019, at 23:37, Ulysse Carion <[email-masked]> wrote:
> 
> Hi all,
> 
> I believe this iteration is suited to be the penultimate draft; I see no features in this spec worth adding, nor any features worth removing. I know of a few minor problems with the language in the spec, and those issues are tracked on GitHub here.
> 
> In this draft, I introduced fine-grained numerical types -- "float32", "float64", "int8", "uint64", etc. -- because they are immensely useful for real-world code generation. The spec details these types here (Table 2). "float32" and "float64" have no effect on validation versus "number", but they do signal intent, and act as a hint for code generators.
> 
> The question of JSON integers has been contentious in the past -- I explicitly call out that 10.0 is considered a fine "int8". I did this out of the robustness principle, and the fact that the alternative (considering 10.0 unacceptable) is one which fewer will be able to enforce. Some implementations may in practice be more restrictive in what they accept than the spec describes. I think that's acceptable; it seems clear that either approach will lead to people deviating from the spec.
> 
> Let me know what y'all think about JSON Schema Language as a whole! If you relish in the concrete, here are working implementations of validators built on this iteration of JSON Schema Language:
> 
> The GitHub org also contains tooling built on JSL, but they have not been updated to support the fine-grained numerical types yet. I'll be working on that soon.
> 
> I view JSL as being nearly complete, so any and all criticism is most welcome.
> 
> Thanks,
> Ulysse
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json

---

From: "Manger, James" <[email-masked]>
Date: Wed, 24 Jul 2019 04:07:46 +0000

> In this draft, I introduced fine-grained numerical types -- "float32", "float64", "int8", "uint64", etc. -- because they are immensely useful for real-world code generation.

Might be more useful to have int53. That encourages designers to use integers that interop nicely with I-JSON, ECMAScript etc.

> I explicitly call out that 10.0 is considered a fine "int8".

Should also call out that 1.00e1 is considered a fine “int8”.

int64/uint64 are defined in 3.3.3. “Type” and table 2, but not included in num_type (2 “Syntax”). I’d drop int64/uint64 totally due to the interop problems. Some JSON tools start sending integers as strings if they are above 2^53.

“ref” only referring to definitions at the _root_ level seems unhelpfully restrictive. It doesn’t seem to play nicely with the goal of being able to embed the schema in other JSON docs. It doesn’t work well with the recursive nature of schema (eg a schema for an object with, say, 2 properties needing 2 other schemas for the allowed values of those properties). Would a better rule be that a definition must appear along the path from the _root_ to the “ref”; that is, a definition must be “above” a “ref”.

> I see no features in this spec worth adding

A significant missing feature is a choice of types. For instance, a field can be an array of strings or just a string; a field can be an number or a number in quotes (ie a string).

--
James Manger

---

From: Ulysse Carion <[email-masked]>
Date: Wed, 24 Jul 2019 11:59:28 -0700

> Should also call out that 1.00e1 is considered a fine “int8”.

This is a great point. I'll fix this in the next draft.

On your points regarding numbers beyond 2^53/int53, do you feel that the
warning about I-JSON is insufficient? Many systems using JSON aren't
concerned about JavaScript, and for these systems being able to use
integers beyond 2^32 is useful. 64-bit integers is the idiomatic way to
represent these types, and so that's why I added those to the spec.

> “ref” only referring to definitions at the _root_ level seems unhelpfully
restrictive. It doesn’t seem to play nicely with the goal of being able to
embed the schema in other JSON docs. It doesn’t work well with the
recursive nature of schema (eg a schema for an object with, say, 2
properties needing 2 other schemas for the allowed values of those
properties). Would a better rule be that a definition must appear along the
path from the _root_ to the “ref”; that is, a definition must be “above” a
“ref”.

This is a good point. I started with the design you propose, but moved away
from it because it complicates code generation, requiring code generators
to implement some sort of name mangling. The generated code is likely to be
less useful as a result. Furthermore, it introduces annoying subtleties,
such as clarifying whether a "definitions" appearing within "discriminator"
(i.e, appearing as a sibling of "tag" and "mapping", see
https://tools.ietf.org/html/draft-json-schema-language-02#section-3.3.8)
counts or not. But perhaps I'm overestimating the difficulty here?

Put another way: by saying "definitions only matter at the root", a large
class of ambiguity goes away. It immediately becomes clearer exactly how
JSL works in detail. That struck me as a good property.

As you point out, this does have the consequence that it becomes more
difficult to embed a JSL schema within a broader one, since all of its
definitions have to be moved to the top level. Tooling can help here, but I
agree this is a design decision with shortcomings.

> A significant missing feature is a choice of types. For instance, a field
can be an array of strings or just a string; a field can be an number or a
number in quotes (ie a string).

This is intentionally left out. It's difficult to portably code-generate
for this case. Instead, I was thinking users would either use an empty
schema for this case (essentially marking the data as "any"), or use a
discriminator. Does that strike you as good enough?

On Tue, Jul 23, 2019 at 9:08 PM Manger, James <
[email-masked]> wrote:

> real-world code generation.
>
>
>
> Might be more useful to have int53. That encourages designers to use
> integers that interop nicely with I-JSON, ECMAScript etc.
>
>
>
> int64/uint64 are defined in 3.3.3. “Type” and table 2, but not included in
> num_type (2 “Syntax”). I’d drop int64/uint64 totally due to the interop
> problems. Some JSON tools start sending integers as strings if they are
> above 2^53.
>
>
>
>
>
> “ref” only referring to definitions at the _root_ level seems unhelpfully
> restrictive. It doesn’t seem to play nicely with the goal of being able to
> embed the schema in other JSON docs. It doesn’t work well with the
> recursive nature of schema (eg a schema for an object with, say, 2
> properties needing 2 other schemas for the allowed values of those
> properties). Would a better rule be that a definition must appear along the
> path from the _root_ to the “ref”; that is, a definition must be “above” a
> “ref”.
>
>
>
>
>
> A significant missing feature is a choice of types. For instance, a field
> can be an array of strings or just a string; a field can be an number or a
> number in quotes (ie a string).
>
>
>
> --
>
> James Manger
>

---

From: "Manger, James" <[email-masked]>
Date: Thu, 25 Jul 2019 05:33:15 +0000

> On your points regarding numbers beyond 2^53/int53, do you feel that the warning about I-JSON is insufficient? Many systems using JSON aren't concerned about JavaScript, and for these systems being able to use integers beyond 2^32 is useful. 64-bit integers is the idiomatic way to represent these types, and so that's why I added those to the spec.

Warning about I-JSON is insufficient.
It’s not just JavaScript.
A code generator seeing “int53” can use a “long” in the code (and other generators can use a “double”).
Offering “int64” will lead people to interop problems when some of their values break. If you want to use integers over 2^53 in JSON don’t use JSON’s native number syntax: use a string instead (probably base64url-encoded for really large crypto numbers).
If you have a system that you are certain will never need to interop with one that at some point in its parsing treats JSON numbers as doubles … well you are in a closed system so you don’t really needs an IETF spec … and you are making dangerous assumptions about your future technical stack … (plus you can put “int53” in your schema, get a “long” in your generated code, but don’t put any 2^53 checks in the code).

> This is intentionally left out. It's difficult to portably code-generate for this case. Instead, I was thinking users would either use an empty schema for this case (essentially marking the data as "any"), or use a discriminator. Does that strike you as good enough?

This is a major limitation for something calling itself “JSON Schema Language”, as opposed to, say, “Schema Language for a Subset of JSON”. All code generators needs to be able to insert “any”. Its not the end of the world if some code generators use “any” whenever the schema allows multiple types if doing better is too difficult.

--
James Manger

--
James Manger

---

From: Andrew Newton <[email-masked]>
Date: Thu, 25 Jul 2019 18:12:24 -0400

What relationship does this have with JSON Schema
(https://json-schema.org/)? Is it a separate effort (which it appears
to be)? There maybe a name collision here. I'll note that
json-schema.org has and continues to submit I-Ds.

In the end, I believe no effort in the IETF to put a JSON ddl on the
standards track would be legitimate without the involvement of
json-schema.org (I said as much in London when I presented JCR). They
have a larger community than we have here and a specification baked
into many tools.

Giving this some more thought, the time for the IETF to be doing a
JSON ddl may have passed. Discussions on the topic have been on and
off for at least six years. In the meantime, JSON Schema
(json-schema.org) has made its way into many tools. Additionally,
other standards have materialized such as Swagger/OpenAPI to address
other aspects of JSON usage in REST, etc...

Due to the emergence of new formats such as TOML (to compete against
YAML) and RCON and JSONLines to compete against JSON, it maybe that
the undiscovered territory is that which PHB has been pointing towards
for years: an abstraction language. But such a thing is far from the
IETF's stomping grounds.

-andy

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Jul 2019 18:36:56 -0400

On Jul 25, 2019, at 18:12, Andrew Newton <[email-masked]> wrote:
> YAML) and RCON and JSONLines to compete against JSON,

A data definition language (what we call “schema language” here) describes data in a (generic) data model, not data serialized in a format.  The formats you mention have a high degree of commonality in their generic data models, so I don’t know why a simple data definition language cannot cover all of them [but then I don’t know RCON].

Grüße, Carsten

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 26 Jul 2019 08:15:45 +0200

I'm still waiting (most likely in vain) for a JSON schema language
that better reflects the actual use of JSON, and in particular numbers.

That is:
- monetary types are distinct from other numbers since they don't build on FP math.
- big integers are in IETF standards (AFAIK without exceptions) expressed as quoted strings which in turn may be coded as decimal, hex, base64url etc.

Anders

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 26 Jul 2019 09:57:58 +0200

On 2019-07-26 09:08, Henry Andrews wrote:
> Hi Anders,

Hi Henry,

>    As long as you are not relying on the text representation of JSON (e.g. using JSON numbers and needing to distinguish between 1, 1.0, and 1.00) then you should be able to easily make a re-usable JSON Schema extension vocabulary for this.  Since it sounds like you are using strings to get around that problem, then it should be fine.  There is also already a keyword to indicate encoded strings, including RFC 4648 base64url.

I'm not particularly concerned about my own use of JSON, but about the ability to for example expressing an RSA JWK [1] or an amount in PaymentRequest [2] using some kind of JSON schema.

>    Some of these number-in-string issues have been proposed to be solved with the "format" keyword, but "format" is kind of a disaster due to its optional best-effort validation behavior.  We are making some changes in this draft to try to make it more reliably predictable and give schema authors some control over how it is processed, but we will be strongly encouraging people to write their own keyword vocabulary rather than custom formats.

I don't understand exactly what the problem is here.  IMO all integer types could schema wise be treated identical (albeit some with warnings) and be supplied as:
- JSON Number
- "JSON Number"
- "hex"
- "base64"
- "base64url"
- "base58"

Real numbers would probably only gain by the two first notations.

The monetary type is separate from the rest. It has a very specific syntax like a date type.

This should cover 99% of existing and future JSON use cases.  Yes, this is a slightly risky statement...

Pardon for being somewhat low-level but if the low level isn't right, the upper parts tend to fall as well :-)

thanx,
Anders

1] https://tools.ietf.org/html/rfc7520#section-3.3
2] https://www.w3.org/TR/payment-request/#dfn-valid-decimal-monetary-value

> 
>    It's a lot easier to manage different keyword sets than to have this one keyword into which everything higher-level data type somehow must be shoved.
> 
>    Once we have the new draft out, it would be an interesting test of the feature to see how easy it would be to design such a keyword vocabulary.
> 
> thanks,
> -henry
> 
> 
> On Thursday, July 25, 2019, 11:16:03 PM PDT, Anders Rundgren <[email-masked]> wrote:
> 
> 
>  > On Sun, Jul 21, 2019 at 11:37 PM Ulysse Carion <[email-masked] <mailto:[email-masked]>> wrote:
>  >>
>  >> Hi all,
>  >>
>  >> [email-masked] <mailto:[email-masked]>
>  > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Andrew Newton <[email-masked]>
Date: Fri, 26 Jul 2019 05:26:29 -0400

> A data definition language (what we call “schema language” here) describes data in a (generic) data model, not data serialized in a format.  The formats you mention have a high degree of commonalit…

I agree with the concept. The IETF already has YANG. And things like
GraphQL are fairly popular in the industry. So what work is left to
do?

-andy

---

From: Henry Andrews <[email-masked]>
Date: Fri, 26 Jul 2019 21:19:39 +0000 (UTC)

Hi Anders,  Could you show what those "JSON Number", "hex", etc. things would look like in a schema?  Are those keywords?  Values for the "type" keyword?  Values for the "format" keyword?  Something else?
thanks,-henry
PS- while I am receiving emails from the JSON list, my replies and new emails seem to be disappearing (perhaps held for moderation?)  I had sent a more extensive email about JSON Schema and JSL which would make more of what I'm talking about with regards to "vocabularies" in this thread make sense.  Hopefully that will appear at some point.

    On Friday, July 26, 2019, 12:58:15 AM PDT, Anders Rundgren <[email-masked]> wrote:  

Hi Henry,

thanx,
Anders

>  > What relationship does this have with JSON Schema
>  > (https://json-schema.org/)? Is it a separate effort (which it appears
>  > to be)? There maybe a name collision here. I'll note that
>  > json-schema.org has and continues to submit I-Ds.
>  >
>  > In the end, I believe no effort in the IETF to put a JSON ddl on the
>  > standards track would be legitimate without the involvement of
>  > json-schema.org (I said as much in London when I presented JCR). They
>  > have a larger community than we have here and a specification baked
>  > into many tools.
>  >
>  > Giving this some more thought, the time for the IETF to be doing a
>  > JSON ddl may have passed. Discussions on the topic have been on and
>  > off for at least six years. In the meantime, JSON Schema
>  > (json-schema.org) has made its way into many tools. Additionally,
>  > other standards have materialized such as Swagger/OpenAPI to address
>  > other aspects of JSON usage in REST, etc...
>  >
>  > Due to the emergence of new formats such as TOML (to compete against
>  > YAML) and RCON and JSONLines to compete against JSON, it maybe that
>  > the undiscovered territory is that which PHB has been pointing towards
>  > for years: an abstraction language. But such a thing is far from the
>  > IETF's stomping grounds.
>  >
>  > -andy
>  >
>  > On Sun, Jul 21, 2019 at 11:37 PM Ulysse Carion <[email-masked] <mailto:[email-masked]>> wrote:
>  >>
>  >> Hi all,
>  >>
>  >> I've just submitted an I-D of JSON Schema Language:
>  >>
>  >> https://tools.ietf.org/html/draft-json-schema-language-02
>  >>
>  >> I believe this iteration is suited to be the penultimate draft; I see no features in this spec worth adding, nor any features worth removing. I know of a few minor problems with the language in the spec, and those issues are tracked on GitHub here.
>  >>
>  >> In this draft, I introduced fine-grained numerical types -- "float32", "float64", "int8", "uint64", etc. -- because they are immensely useful for real-world code generation. The spec details these types here (Table 2). "float32" and "float64" have no effect on validation versus "number", but they do signal intent, and act as a hint for code generators.
>  >>
>  >> The question of JSON integers has been contentious in the past -- I explicitly call out that 10.0 is considered a fine "int8". I did this out of the robustness principle, and the fact that the alternative (considering 10.0 unacceptable) is one which fewer will be able to enforce. Some implementations may in practice be more restrictive in what they accept than the spec describes. I think that's acceptable; it seems clear that either approach will lead to people deviating from the spec.
>  >>
>  >> Let me know what y'all think about JSON Schema Language as a whole! If you relish in the concrete, here are working implementations of validators built on this iteration of JSON Schema Language:
>  >>
>  >> https://github.com/json-schema-language/json-schema-language-go
>  >> https://github.com/json-schema-language/json-schema-language-typescript
>  >> https://github.com/json-schema-language/json-schema-language-rust
>  >>
>  >> The GitHub org also contains tooling built on JSL, but they have not been updated to support the fine-grained numerical types yet. I'll be working on that soon.
>  >>
>  >> I view JSL as being nearly complete, so any and all criticism is most welcome.
>  >>
>  >> Thanks,
>  >> Ulysse
>  >> _______________________________________________
>  >> json mailing list
>  >> [email-masked] <mailto:[email-masked]>
>  >> https://www.ietf.org/mailman/listinfo/json
>  >
>  > _______________________________________________
>  > json mailing list
>  > [email-masked] <mailto:[email-masked]>
>  > https://www.ietf.org/mailman/listinfo/json
>  >
>

---

From: Henry Andrews <[email-masked]>
Date: Fri, 26 Jul 2019 21:20:37 +0000 (UTC)

Oh hey this reply worked... I guess I'll re-send that other one?
    On Friday, July 26, 2019, 02:19:55 PM PDT, Henry Andrews <andrews_henry=[email-masked]> wrote:  

 

Hi Henry,

thanx,
Anders

>  >> https://tools..ietf.org/html/draft-json-schema-language-02
>  >>

---

From: Henry Andrews <[email-masked]>
Date: Fri, 26 Jul 2019 21:28:29 +0000 (UTC)

Hi folks,  I'm one of the current authors/editors of the JSON Schema specification, along with Austin Wright, Ben Hutton, and Greg Dennis.  
  Andy Newman brought yesterday's thread about JSON Schema Language to our attention, and I see that he asked about the relationship between JSL and JSON Schema earlier in the thread here.
  There is no relationship between the projects, aside from obviously drawing on some common ideas.  JSL also draws on some ideas that we decided to exclude from JSON Schema.  Ulysse discussed some ideas with us a while back but it became clear that our current direction was not what he was looking for.  I encouraged him to build his own system, as JSON Schema has a large user base, and some things that he wanted changed would be too disruptive to that user base.  IIRC (and feel free to correct if I'm misremembering this, Ulysse), he also disagreed with some key features in the next draft.  Since those features were developed in coordination with large user communities such as OpenAPI, we were not willing to drop them based on anyone's individual objections.
  My only concern with the JSON Schema Language project is the name: while JSON Schema is purely a series of individual drafts and therefore has no official IETF status or approval, the name "JSON Schema" has a long history and a large user base.  Putting out a similar project with a nearly-identical name will be very confusing and, in my opinion, bad form.  Contrast with JSON Schema and JSON Content Rules which can easily co-exist without confusion.
  Might I suggest "JSON Definition Language", as the system is primarily oriented towards definitions for code generation and the like?
  Anyway, if Ulysse calls it something else then, speaking for myself and not for the whole JSON Schema project, I don't have any problems with JSL at all.
  Andy wrote in his email here about wanting us involved in any standards-track JSON DDL, which I appreciate, but there are a couple of concerns that make that unlikely.  At least right now.
1.  JSON Schema is not really a data definition language, at least not in its current form.  It was originally constructed as a constraint system, with a vaguely-defined concept of annotating instances with other (possibly dynamic, e.g. Hyper-Schema) data.  Next month's draft finishes formalizing the annotation concept so that it can be interoperable, and formalizes an extensibility mechanism.
  This extensibility mechanism will allow defining a data definition vocabulary through annotations within the JSON Schema system, but that will be further work and presumably be an additional spec on top of the Validation spec (again, similar to how Hyper-Schema builds on Validation).  This work on extensibility is primarily motivated by systems such as OpenAPI code generators and various web form generator libraries, which are otherwise an awkward fit.
  In another thread, Tim Bray asked if JSL was a compatible subset of JSON Schema- it is not.  The extensibility mechanism in the forthcoming draft does allow constraining JSON Schema in certain ways to define subsets (for example if the anyOf/allOf/oneOf/not/if/then/else keywords are not suitable for some use cases, they could be forbidden without otherwise changing the keyword syntax or semantics).  If the desire is simply to subset JSON Schema, there is no need for a separate project.
2.  The last time we checked in with this mailing list, we were told that the JSON working group (or some successor group- I'm a little unclear on that) would not be interested in adopting JSON Schema in anything resembling its current form for a Standards Track RFC.  I think Ben (one of the other editors) is planning to check back in here on that topic after we get the next draft out the door, but given our large and well-established user community, discarding what we have is not an option.  Perhaps an Informational RFC would be more appropriate, as my understanding is that they "may be appropriate when republishing standards produced by a standards body other than the IETF, industry consortia or companies."  (I suppose the JSON Schema org may be considered an "industry consortia" under a sufficiently permissive definition :-)
  So (again, speaking for myself), I have been assuming that the working group would at some point start a new project or adopt another project than ours (JCR, JSL, whatever).  If relatively simple data definition is the only thing that you want, then it would of course be possible to write a more focused system than JSON Schema.
  As for the status of JSON Schema, we are indeed still an active project, and expect to publish a new draft during August.  The regrettable delay that has left us in an expired draft state for the past half-year was the result of a series of personal difficulties on my side, but fortunately other community members have stepped up to help.  Most of the current core contributors have been involved since October 2016's draft-wright-json-schema-00, and I'm not disappearing entirely, so there is considerable continuity.

  The primary goal of the August draft is to get feedback on the extensibility mechanism, the recommended output/error format, and a few other major new features.  I expect there will be one further significant draft (or cluster of small updates so we don't have another big gap) to finish the extensibility work based on that feedback, at which point hopefully we can declare the Core and Validation specifications "done", whether that means publishing some sort of final document or entering a more formal standards process.  Hyper-Schema is on a different timeline, and will not block Core or Validation.
  Please let me know if you have any questions.
thanks,-henry

---

From: Henry Andrews <[email-masked]>
Date: Fri, 26 Jul 2019 21:32:16 +0000 (UTC)

One question I am curious about is how JSL got adopted by the working group (being draft-json-schema-language-NN instead of draft-ucarion-json-schema-language-NN or draft-ucarion-schema-language-NN)?  I could not find a discussion on this in the archives, although admittedly I did not read all of the messages that seemed to be about details of numeric types or whatever yet.
thanks,-henry
    On Friday, July 26, 2019, 02:26:52 AM PDT, Andrew Newton <[email-masked]> wrote:  

-andy

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 26 Jul 2019 17:38:54 -0400

On Jul 26, 2019, at 17:32, Henry Andrews <andrews_henry=[email-masked]> wrote:
> 
> draft-json-schema-language-NN

This is an individual contribution by mx. Json to the Schema working group about Language.
All three don’t exist, but datatracker doesn’t check that.

Working group documents of the JSON working group would look like

draft-ietf-json-*-NN

See?  Other people can play with names and confuse the heck out of the community, too :-)

Grüße, Carsten

---

From: Henry Andrews <[email-masked]>
Date: Fri, 26 Jul 2019 21:41:01 +0000 (UTC)

LOLOL awesome, that actually does make more sense.  Garbage in, garbage out... ;-D
-henry
    On Friday, July 26, 2019, 02:39:12 PM PDT, Carsten Bormann <[email-masked]> wrote:  

draft-ietf-json-*-NN

Grüße, Carsten

---

From: Ulysse Carion <[email-masked]>
Date: Fri, 26 Jul 2019 20:43:58 -0700

Hi James,

> If you have a system that you are certain will never need to interop with
one that at some point in its parsing treats JSON numbers as doubles … well
you are in a closed system so you don’t really needs an IETF spec … and you
are making dangerous assumptions about your future technical stack … (plus
you can put “int53” in your schema, get a “long” in your generated code,
but don’t put any 2^53 checks in the code).

This is a very strong point, and one which I had given insufficient
consideration. Looking at gRPC, they opted to represent int64 as a base-10
strings. In GitHub, I noticed one of the gRPC developers puts the point
nicely:

> So, rather than pretending that Javascript can handle it (and lose data)
proto3 prefers to have the client interact with strings. Fewer footguns ==
better libraries.

(
https://github.com/grpc-ecosystem/grpc-gateway/issues/219#issuecomment-251250029
)

Given that introducing int64 as a JSON number type would be a footgun for
many sorts of applications, I agree it should be changed.

How would you feel about simply removing int64/uint64, but otherwise
keeping everything else as-is? I don't know if adding "native" support for
string-represented bigints is a great idea, as there are so many different
options. Smaller specs are the ones most frequently implemented correctly
and securely.

> This is a major limitation for something calling itself “JSON Schema
Language”, as opposed to, say, “Schema Language for a Subset of JSON”. All
code generators needs to be able to insert “any”. Its not the end of the
world if some code generators use “any” whenever the schema allows multiple
types if doing better is too difficult.

I'm not sure I agree that this is a major limitation. There are many
options for data definition languages for JSON. JSL is just one of them,
falling on the less-expressive, easier-to-implement end of the spectrum. Or
is your concern purely one regarding naming?

---

From: Ulysse Carion <[email-masked]>
Date: Fri, 26 Jul 2019 20:56:15 -0700

Hi Andrew,

> json-schema.org <http://json-schema.org> (I said as much in London when I
presented JCR). They
> have a larger community than we have here and a specification baked

Just for my own context, do you happen to have any links to minutes /
recording of this presentation? I want to better understand your point.

Best,
Ulysse

On Fri, Jul 26, 2019 at 8:43 PM Ulysse Carion <[email-masked]> wrote:

> Hi James,
>
> > If you have a system that you are certain will never need to interop
> with one that at some point in its parsing treats JSON numbers as doubles …
> well you are in a closed system so you don’t really needs an IETF spec …
> and you are making dangerous assumptions about your future technical stack
> … (plus you can put “int53” in your schema, get a “long” in your generated
> code, but don’t put any 2^53 checks in the code).
>

---

From: Henry Andrews <[email-masked]>
Date: Sat, 27 Jul 2019 04:00:07 +0000 (UTC)

Hmm.. in the archives it looks like most of my blank lines between paragraphs got deleted somewhere (although it looks fine in the actual email back to me).  Here's an attempt to make it more readable.  

On Friday, July 26, 2019, 02:29:19 PM PDT, Henry Andrews <andrews_henry=[email-masked]> wrote: 

Hi folks,
  I'm one of the current authors/editors of the JSON Schema specification, along with Austin Wright, Ben Hutton, and Greg Dennis.  

thanks,
-henry

---

From: Andrew Newton <[email-masked]>
Date: Sat, 27 Jul 2019 09:12:41 -0400

The convention is typically draft-LASTNAME-blabblah... to denote a
draft with only individual standing.

-andy