<div dir="ltr">Design notes for X3DJSONLD and x3dschema (repositories on GitHub).  No questions need to be answered in this email.<div><br></div><div>X3DJSONLD (the whole package) requires containerField when constructing stuff in serialized apps (like Java pseudocode below):<div><br></div><div>HAnimHumanoid.addSkeleton(..joints...)</div><div><br></div><div>and</div><div><br></div><div>HAnimHumanoid.addJoints(...joint...)</div><div><br></div><div>Why? Because I have to construct the "addJoints" or "addSkeleton" from something.  I've chosen to use "-joints" and "-skeleton" from JSON (I know, bad word).</div><div><br></div><div>So what I do with those "parent node field names (plus a dash)" is take the field name, remove the dash, capitalize, and prepend with ".add" (shortened version.  I also look up methods in a parent/child data structure derived from X3DUOM).</div><div><br></div><div>But before that, I convert JSON to DOM, so I just set containerField="joints" or containerField="skeleton" in DOM. I can do these things, because X3dToJson.xslt provides the parent node field names (plus dash) in the form of JSON. I should probably do something else in DOM besides containerField (why didn't I think of that before)?  I was trying most unsuccessfully to duplicate XML in round-trip.</div><div><br></div><div>I didn't really understand the use of these parent node field names when designing the JSON encoding (why not just use an off the shelf XML to JSON tool like JAX-B or similar and be done with it, with no customization except annotations in X3DJSAIL?)</div><div><br></div><div>But I admit, as I've grown to deal with XML, I can see a bit of the beauty of JSON and VRML using these node fields.</div><div><br></div><div>Indeed I could skip this whole "DOM" step. I'm not sure of the design choice, but it made integration with X3DOM and X_ITE extremely easy, and VRML could follow this pathway into X3DOM.  Similar designs are being used in CGE with glTF/glb, AFAIK.</div><div><br></div><div>Perhaps the right approach is to start fresh with ECMAScript SAI binding and the existing JSON WIP encoding, and leave any mention of DOM in the dust. I'm not the one to design the ECMAScript SAI binding.  People in the X3DOM and X_ITE communities are much more experienced than I, especially with 3D, and they know trade-offs.  My primary goal was to round-trip back to XML for JSON proof-of-concept.  Frankly, I know the minimum amount of JavaScript necessary for my tasks.  I did sort of read an ES6 book that a friend gave me, or at least look at code snippets, out of that grew route.js which could serve as the basis for a new form of routing for a JSON scenegraph.  Thus came the ProtoExpander, the ScriptExpander, X3D JSON schema and X3DJSONLD web page. The X3DJSONLD web page is barely standing these days. ProtoExpander is nearly deprecated, and no one wants the ScriptExpander.  X3D JSON schema is like a memory.  Learning ProtoExpander and Serializers, I grew to dislike the way JSON did things, and "saw the light" of DOM design.  My first JavaSerializer.js (DOM to Java) for X3DJSAIL was so successful, the design was copied and extended (Thanks to Don for the chaining idea), and then copied to other languages.</div><div><br></div><div>DOM is still used in the XSD validator for JSON.  We could do something similar for VRML.  But tools like view3dscene already surpass this effort.</div></div><div><br></div><div><br></div><div>MUSINGS</div><div>=============================================================</div><div>I really still don't know if JSON is the right encoding for the web in general. It appears to require full state dumps between the server and the client. A combination of DOM and JSON would be terrific if not accomplished.</div><div><br></div><div>VRML really seems to fit a vim/vi mindset. I don't think XML/HTML was designed with vi in mind, so those encodings don't work for me.  I don't do any heavy editing of JSON in vi.  I've done much more editing in XML and VRML.</div><div><br></div><div>I've done a lot of editing of VRML in vim, and it seems like a great fit, for smaller files.  There could be a few features in vim I could use for XML and JSON that are unexplored. vim keybindings don't stick in my mind as well any more, so I try to use vi bindings.</div><div><br></div><div>John</div></div>