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

Another advantage of using <field> over HTML5 data-* attributes is <field>
can contain other elements.

I had just thought of data-* attributes in my previous email, so I had not
thought of all the implications.

John

On Mon, Jan 13, 2025 at 11:38 PM John Carlson <yottzumm@gmail.com> wrote:

> 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
>
>
>
>
>
>