Re: [Json] JSON "Number" interoperability issues

[Anders Rundgren <[e-mail]>]

I'm just saying that the JSON community has interoperability issues:
https://github.com/javaee/jsonb-spec/issues/80#issuecomment-383465639

I wouldn't characterize interoperable solutions as JSON "subsets".
 From an application writer's point of view OpenAPI is more of a subset since it out-of-the-box doesn't support BigInteger which Java and .NET do.

Anders

On 2018-04-22 20:21, Henry Andrews wrote:
> JSON Schema provides tools to describe how people use JSON documents, including imposing structural constraints.  While you could write a schema describing the subset of JSON that you wish to use as your "standard", that would be a *use* of JSON Schema, not *part* of JSON Schema.
> 
> Anders, you seem to want JSON Schema to prevent people from using things that are technically allowed by the spec (as Carsten noted, "allowed" in the sense that no one will stop you, not in the sense that any reasonable person would expect a positive outcome).  That is not what JSON Schema, *as a project*, is for.  You are more than welcome to use JSON Schema in your own project to advocate for a more interoperable subset of JSON.
> 
> The section of JSON Schema's validation specification that you reference, about the values for "format", has gotten some discussion around how to manage larger extensibility question such as defining a registry.  The issue for that discussion is https://github.com/json-schema-org/json-schema-spec/issues/563
> 
> Furthermore, this email list is not the right forum for discussing changes to JSON Schema.  This group has previously made it pretty clear that they are at most interested in JSON Schema as one of many possible starting points for a new effort, rather than developing JSON Schema itself into a standards track RFC.  I have no objection to that- the IETF is welcome to use or not use our work in whatever way makes sense.  I've never gotten anything to RFC myself, and wouldn't presume to know all of the considerations involved.  I'll be happy to support anyone who wants to use any JSON Schema ideas in a new effort, but if we're talking about JSON Schema as it is, that's better done through our repo or slack channel.
> 
> thanks,
> -henry
> 
> [e-mail] <mailto:[e-mail]>
> [e-mail] <mailto:[e-mail]>
> 
> 
> On Sun, Apr 22, 2018 at 3:27 AM, Anders Rundgren <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     Since the JSON Number universe outside of IEEE-754 double precision has been left to application/platform developers to deal with [*], there are currently multiple incompatible (or incomplete) "standards" out there:
>     https://github.com/OAI/OpenAPI-Specification/issues/845#issuecomment-378139730 <https://github.com/OAI/OpenAPI-Specification/issues/845#issuecomment-378139730>
>     https://github.com/javaee/jsonb-spec/blob/master/spec/spec.pdf <https://github.com/javaee/jsonb-spec/blob/master/spec/spec.pdf>
> 
>     For .NET I haven't been able obtaining any public information on this topic, so I wrote some code in order to find out what it actually does.
> 
>     Maybe JSON Schema could serve a suitable place for defining a [potential] "real/de-facto" standard?
> 
>     To make such a process even smother, I could imagine moving http://json-schema.org/latest/json-schema-validation.html#rfc.section.7.3 <http://json-schema.org/latest/json-schema-validation.html#rfc.section.7.3> into a separate document but I haven't looked into the consequences of that.
> 
>     Anders
> 
>     *] https://www.ietf.org/mail-archive/web/json/current/msg04294.html <https://www.ietf.org/mail-archive/web/json/current/msg04294.html>
> 
> 
> 
> 
> -- 
> 
>   *
>     |
> 
>     *Henry Andrews*  |  Systems Engineer
>     [e-mail] <mailto:[e-mail]>
> 
>     <https://www.cloudflare.com/>
> 
>     1 888 99 FLARE  | www.cloudflare.com <https://www.cloudflare.com/>
> 
>     |
> *
>