javascript vision thing

[Anders Rundgren]

On 2018-07-24 17:09, Carsten Bormann wrote:
> On Jul 24, 2018, at 16:31, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
>>
>> JSON isn’t really a topic for tc39 only but since the IETF consider JSON "done", an open question is where possible future developments should take place,
> 
> No, that is not the question.
> 
>> including dealing with new data types like BigInt.
> 
> That, indeed, is a question for JavaScript.  It has nothing to do with “developing” JSON; JSON can already represent BigInt just fine.

Serializing BigInt as JSON Number is the solution then?

There are a few argument against that:

- This would typically require low-level parsers to always rely on a BigNumber type.  Oracle's JSON-B does exactly that.  Currently there is no BigNumber type in JS or .NET.

- There is quite a bunch of IETF standards defining JSON structures. As far as I know none of them exploit JSON outside of its original, JS-induced limitations.

- Although BigInt is a very welcome addition to JS, usages are few and typically confined to specific things like crypto or money.  Creating backward incompatibility for that is IMO counterproductive.

- Serializing BigInts as a string does not break anything.


>> Personally I think the JSON WG should be rebooted but apparently I’m rather alone with that idea.
> 
> Indeed.

That might be the case but it doesn't solve the problem.


> 
> Frankly, JSON, together with the JavaScript-induced limitations in its ecosystem as documented in RFC 7493, is not a very brilliant data interchange format.

It seems to work well in spite of not being brilliant.

Even "the impossible", JSON Canonicalization actually works as described if you stick to the same limitations existing IETF-defined JSON objects do: https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01

I'm not going into the the rest of the mail because supporting another interchange format is another question.

Yes, CBOR is great https://tools.ietf.org/html/rfc7049 :-)

cheers,
Anders

>  It is popular because it is extremely simple (at least on the surface), it is already 
> familiar to users of most dynamic programming languages, and it hasn’t changed since 2002.  “Changing” JSON simply means no longer having JSON.
> 
> (And there are quite a few much better data interchange formats; maybe JavaScript can start to support some of them out of the box.)
> 
>> Obvious extensions include comments and dropping the "" requirement on keys that are JS compliant.
> 
> *Shudder*.   These are *not* needed for data interchange.  For configuration files and other data input by humans, DO NOT USE JSON.  If you need YAML(*) (which also has been fully stable for more than a decade, by the way), you know where to find it.  YAML also *is* the extended JSON that so many people are wishing for.
> 
> Grüße, Carsten
> 
> (*) and of course YAML supports graphs, binary (byte string) data, human-friendly input, etc.  It is approximately what any other effort to “humanize” JSON and fill in its shortcomings will arrive at eventually, just with some microdecisions you and I may not like but that are not relevant in the big picture.
>