Submitted for your approval, JSOX

Felipe Nascimento de Moura felipenmoura at gmail.com
Tue Sep 18 22:52:44 UTC 2018


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
<https://developers.google.com/experts/people/felipe-moura>, Founder of
BrazilJS <https://braziljs.org/> and Nasc <http://nasc.io/>.

Website:  http://felipenmoura.com / http://nasc.io/
Twitter:    @felipenmoura <http://twitter.com/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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180918/4f114023/attachment-0001.html>


More information about the es-discuss mailing list