<div dir="ltr"><div>Hi everyone,</div><div><br></div><div><br></div><div>Ah I'm glad to see some life reinjected in the JSON encoding, it's been one of my pet peeves :)</div><div><br></div><div><br></div><div>Regarding "why JSON":</div>

<div><br></div><div> - For better or for worse, JS is the lingua franca of the interactive web for the forseeable future and JSON is its natural data format. That's why when you encounter web APIs, they always have a JSON output, but it's getting more rare to see XML output (the trend is even to often have both JSON input & output instead of "form-encoded input + XML/JSON output").</div>

<div><br></div><div> - JSON is also regarded as the "arbitrary data" format in databases (e.g. MongoDB, PostgreSQL or Parse).</div><div><br></div><div><br></div><div><br></div><div>As for the format itself, I came to pretty much the same format as Kristian in my experiments, with one key difference: the node type expressed as "_type" instead of "type", for three reasons:</div>

<div><br></div><div> - Classic and XML encoding don't need a type property, so the naming difference reinforces that it's a special JSON-only property.</div><div><br></div><div> - Nodes might already have a "type" property (I often have such a field in my protos).</div>

<div><br></div><div> - The property could be omitted when the type is obvious, but that's an edge case.</div><div><br></div><div><br></div><div><br></div><div>It doesn't have to be everything for everyone and XML is great for many things, although filesize is a non-issue because you'd use Binary if that's a concern, not classic, X3D or JSON encodings. Even though people also do compression based on JSON (e.g. msgpack or NYTime's Tamper), that is best left up to the user to decide which he wants to use.</div>

<div><br></div><div><br></div><div><br></div><div>See you,</div><div>Cecile</div></div>