My agenda: allow X3D <field> for <script> nodes

The story:

Web3D members use two main web-based 3D engines, X3DOM and X_ITE.  These
take two approaches to scripting.  X3DOM uses HTML script, and X_ITE uses
something called X3D Script, which is essentially the browser’s ECMAScript
by using “new Function()” and eval(), which we would like to avoid!

There seems to be two approaches to avoid “eval”, adding X3D <field>s to
<script> which might seem a lot like HTML5’s data-* attributes, but also
include type, access type (in, out, initialize) and a default value.  If we
have fields, we can parse already existing <ROUTE> nodes already in both
X_ITE and X3DOM and process events to and from scripts.  It might be
possible to use data-* attributes with ROUTEs,  but we have pretty strict
validation on attributes, so I’m guessing X3D <Script>  nodes would no
longer validate.  We can work on relaxing that, but we are pretty happy
that we have a typesafe XML system.

The other approach seems to be converting <field>s to JavaScript
server-side.  One could still have a static website, but the HTML Script
would likely be vastly different.

Ideally, we could continue our HTML-independent scripting while also using
an HTML-dependent scripting without massive rewrites.  We do have a HTML
Scripting solution for X_ITE, it’s just X3DOM that lags behind—we’d like to
enable X3D scripting in X3DOM, without resorting to eval or “new Function()”

So it seems like not rejecting <field> in <script> would be a great start.
I realize that data-* attributes are another approach.


https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/scripting.html