<div dir="ltr"><div>Good morning list,</div><div><br></div><div><br></div><div>> I think the significance of the “$” is a tag, type, class, etc.  In my encoding, this was “jsontag” </div><div>> It essentially encodes the type of the JSON object in the JSON object.  Cecile, please correct me if I am wrong.</div><div><br></div><div>Yes it's exactly that, it's just a property for the node type :)</div><div>Here's some more infos from last year about why I picked this specific structure:</div><div><a href="https://github.com/wildpeaks/json-scenegraph/issues/1" target="_blank">https://github.com/wildpeaks/json-scenegraph/issues/1</a></div><div><br></div><div><br></div><div>> 4) Do we want a parser/loader to convert everything as is, or to perform some optimizations</div><div>> along the way to eliminate comments and structures such as content/children,</div><div>> so that the internal representation is much closer to the 3D structures required?</div><div><br></div><div>Personally I never use JSON5 because I prefer sticking to native JSON parsers.</div><div>But on the other hand, I also wouldn't use comments or scripts in a 3D JSON file</div><div>(for example I'd use ES6 modules that generate JSON or engine-specific typed objects),</div><div>but that's only an option because my main target nowadays is Javascript,</div><div>whereas X3D JSON isn't targeting a specific language.</div><div><br></div><div>That's why I suggested JSON5 as an alternative that doesn't require Javascript </div><div>yet common-enough that it's still easy to parse.</div><div><br></div><div>But using #comment nodes would be fine too, the 3d engine can just filter them out.</div><div><br></div><div><br></div><div>> Purpose:  Avoid XML and the DOM api (probably not the best reason).  The loader uses the DOM api, so…</div><div>> Purpose:  Near native access times.  JavaScript only.  Does not apply to parsing.</div><div><br></div><div>Another reason why JSON is more convenient to me than XML is that I like to keep the application data mutations<br></div><div>in a web worker (to keep the heaviest calculations neatly tucked away from the main page render thread),</div><div>and web workers don't have access to the DOM, and can't use the XML parser.</div><div><br></div><div><br></div><div>> When you load a JSON file into the DOM don't you get the DOM interface anyway?</div><div><br></div><div>No, JSON.parse returns a javascript data type, it's not in the DOM</div><div>(but it can be used to make an equivalent structure in the DOM).</div><div><br></div><div><br></div><div>> I've added a few other details on the X3D to JSON Stylesheet page - please review and advise on what else to add.</div><div>> <a href="http://www.web3d.org/x3d/stylesheets/X3dToJson.html#Muller" target="_blank">http://www.web3d.org/x3d/stylesheets/X3dToJson.html#Muller</a></div><div><br></div><div>Thanks Don, although could you slightly modify the description because I use a vanilla JSON structure.</div><div>JSON5 was just one single example of how one could extend the structure to support</div><div>an optional feature like comments, but I do not require JSON5 at all,</div><div>I even advise scene authors to use Metadata nodes instead when possible,</div><div>in order to keep it as a clean vanilla JSON.</div><div><br></div><div><br></div><div>Happy holidays,</div><div>Cecile</div></div>