r.mark.volkmann at gmail.com
Wed Jul 25 10:31:55 UTC 2018
For me the biggest thing JSON lacks is the ability to add comments.
R. Mark Volkmann
Object Computing, Inc.
> On Jul 25, 2018, at 4:26 AM, Isiah Meadows <isiahmeadows at gmail.com> wrote:
> 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
> me at isiahmeadows.com
>> On Tue, Jul 24, 2018 at 12:43 PM, Carsten Bormann <cabo at tzi.org> wrote:
>>> On Jul 24, 2018, at 18:29, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
>>>> 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.
>>> 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…
>>> - 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.
>>> That might be the case but it doesn’t solve the problem.
>> It also doesn’t create the problem of damaging JSON by instability.
>>> 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
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss