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 <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
