Submitted for your approval, JSOX

Isiah Meadows isiahmeadows at gmail.com
Wed Sep 19 05:13:38 UTC 2018


What precisely is there to do within the spec itself?

The only reason JSON was included was because it became so ubiquitous
across numerous platforms, including both server side, client side,
and scripting.

(Not a TC39 rep, but I strongly doubt they'd seriously consider
including support for *another* protocol unless it becomes similarly
ubiquitous.)

-----

Isiah Meadows
contact at isiahmeadows.com
www.isiahmeadows.com

On Tue, Sep 18, 2018 at 6:53 PM Felipe Nascimento de Moura
<felipenmoura at gmail.com> wrote:
>
> I agree with that.
> I too feel JSON could have an upgrade!
> For instance, I almost always use JSON5 (https://json5.org/) transpilation in any project I have to deal with JSON files.
>
> [ ]s
>
> --
>
> Felipe N. Moura
> Web Developer, Google Developer Expert, Founder of BrazilJS and Nasc.
>
> Website:  http://felipenmoura.com / http://nasc.io/
> Twitter:    @felipenmoura
> Facebook: http://fb.com/felipenmoura
> LinkedIn: http://goo.gl/qGmq
> ---------------------------------
> Changing  the  world  is the least I expect from  myself!
>
>
> On Tue, Sep 18, 2018 at 6:22 PM J Decker <d3ck0r at gmail.com> wrote:
>>
>> (Thank you Rod Sterling)
>>
>> But seriously, I'd like to submit, for serious consideration, JSOX - JavaScript Object eXchange format.  It inherits all JSON syntax such that it is able to process any existing JSON.
>>
>> I'm, at this point, open to changing anything (or even omitting things), including the name.
>>
>> JSON is great.  JSON has some limits, and criticisms... JS/ES Grew , but JSON has to stay the same, similarly with whatever comes next I'd imagine.
>>
>> So a primary goal is to encode and decode ES6 objects for transport with a simple API such as JSOX.parse( object ), and JSOX.stringify( jsoxString ).  But also keep with the simplicity of JSON,
>> so it can be used in human readable circumstances.
>>
>> Types that are now (or soon) native to ES such as TypedArrays (binary data), BigInt types, and even the existing Date type, do not transport with JSON very well.  They become a non-identifable string, that requires extra code involving knowledge of the structure of the data being transferred to be able to restore the values to Date(), BigInt(), et al.
>>
>> So a few weeks ago I started considering what else, beyond these simple modifications might also be useful, or address criticisms of JSON.  Handling the above types is really a trivial modification to most JSON parsers.  Each of the following modifications is really only a very slight change to behavior; although implementing typed-objects does initially involve changing error handling into identifer-fallback handling.
>>
>> I initially argued, that defining a object prototype 'card(name,address,zipcode,created)' which removes the redundant data for every following reference, (and is good, just for data reduction, which was argued 'gzip').  A JSON representation might be `{"name":"bob","address":"123 street","zipcode":"55555","created":1537304820} where if have a large number of the same record the same 'name':,'address':, etc is repeated in every record.  Where a typed-object's value in JSOX could be `card{:"bob","123 street","55555",2018-09-18T21:07:00Z}`.  All objects that are revived as typed-objects share the same prototype, and before parsing, the prototypes to be used may be specified.  The amount of data to process is reduced, perhaps to a significant degree.
>>
>> So <Identifer> '{' is about typed-objects.  This construct is not allowed in JSON.  But that then leads to <Identifier> '['  - typed arrays, arrays don't really have redundant data potential like objects, but there are TypedArrays in ES.  There is no way to define a type of an array, but hardcoded types like 'ab', 'u8', 'ref' are used to revive binary data.  The bytes of the backing ArrayBuffer are encoded to base64, and included within '[' and ']' without quotes; using the brackets as quotes.
>>
>> A JSOX typed array is the 'ref' type.  A reference to another location in the current object can be specified, which allows encoding cyclic structures.
>>
>>
>>
>> https://github.com/d3x0r/jsox
>> https://npmjs.com/package/jsox
>>
>> (Initial public reaction was not very helpful, but probably that's the fault of how it was introduced?)
>> https://www.reddit.com/r/javascript/comments/9f8wml/jsox_javascript_object_exchange_format_preview/
>>
>> There was plenty of 'why not [YAML/BSON/protobufs/(I don't think anyone said XML)/...]'  and the answer is simply, because none of those read JSON, or have as simple of an API. (amongst other reasons that JSON is already a solution for compared to those mentioned)
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list