On 2018-07-24 17:09, Carsten Bormann wrote:
On Jul 24, 2018, at 16:31, Anders Rundgren <[email protected]>
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.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
