We all know about SAI bindings and X3D encodings.<div dir="auto"><br></div><div dir="auto">Can I suggest an alternative?  Has anyone considered limited parsers for X3D Java/Python/JavaScript SAI examples?   That is, don’t use a full parser/compiler to read examples, use a limited one to reduce the attack surface of SAI examples.</div><div dir="auto"><br></div><div dir="auto">I believe there is precedent for this.   In the early 1990’s Tim Sullivan of Independence technologies devised a way to either compile or interpret specialized apps, like CRUD forms.   It was called iScreen, and one could use a variety of toolkits, SunView, XView and Motif to write cross-platform apps.   I took the idea and we developed a programming language that could be written and read from flat files and C++ variables.   We had a primitive parser, or you could compile the program with a full blown C++ parser and link it to a virtual machine.   Today, Cameron Browne is using a “class grammar” in his Ludii project.</div><div dir="auto"><br></div><div dir="auto">The point is to treat X3D examples half like programs and half like program encodings.   One should be able to “compile” an encoding example to native  code.   This is probably a lot like JIT compiling.</div><div dir="auto"><br></div><div dir="auto">Does X3D have a native JIT compiler?  Java?   Can we improve on code we produce from X3dToJava.xslt to do something even faster?   Can we strip away the object model, or compile the object model to native code?</div>