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 [email protected] www.isiahmeadows.com On Tue, Sep 18, 2018 at 6:53 PM Felipe Nascimento de Moura <[email protected]> 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 <[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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
