IMHO, I'd like to see four things: - Native JSON multi-object support - Binary data support that doesn't require delimiters - Native JSON property streaming support - Spec-level binary JSON support
Apart from that, I don't really see anything JSON lacks. ----- Isiah Meadows [email protected] www.isiahmeadows.com On Tue, Jul 24, 2018 at 12:43 PM, Carsten Bormann <[email protected]> wrote: > > On Jul 24, 2018, at 18:29, Anders Rundgren <[email protected]> > wrote: > > > > 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? > > For applications that make good use of BigInt, I would say so. > So you wouldn’t use JSON.parse, but a new interface that preserves integers > beyond 2**53 as BigInt (or possibly even all integers; I don’t want to design > this on a napkin) > > > 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 no need for the above interface to handle floating point numbers > (NR2/NR3). > > > - 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. > > Maybe the IETF was smart enough to stay in the confines of I-JSON… > > But really, JSON never had that particular limitation. A JSON-based > ecosystem that wants to enable the use of JavaScript JSON.parse does, as > Twitter found out when they were sending their perfectly valid JSON to > JavaScript applications. > > > - 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. > > Right, so maybe the motivation for touching JSON really isn’t that massive. > > > - Serializing BigInts as a string does not break anything. > > After JSON.parse, they are text strings then, not BigInts. > Generally, there is the expectation that, for an interesting set of x, > JSON.parse(JSON.stringify(x)) == x > Hence the exception when you pass BigInt to JSON.stringify today. > > >>> 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. > > It also doesn’t create the problem of damaging JSON by instability. > > >> 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. > > Right. As do bicycles. Until you need to transport a sofa or cross the > Atlantic. > JSON is the right tool for a large number of jobs. > > > Yes, CBOR is great https://tools.ietf.org/html/rfc7049 :-) > > Can’t disagree here :-) > > Grüße, Carsten > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
