[x3d-public] X3D Scripting for X3DOM after reading standard; X_ITE supports, X3DOM still unimplemented

Sat Dec 4 16:44:49 PST 2021

So I propose a 3 prong approach to getting X3D HTML/XML scripting 
approach (with <field>s) working in X3DOM:

1.  Create a new node, say X3DScript, if not otherwise taken by other 
nodes and statements.  Get <field>'s working inside it.  Any execution 
should be put off at this point, until we figure out how to integrate 
Protos and Scripts.

2.  Try to get existing script <field>s working inside HTML script 
nodes.  Figure out how to integrate Protos and Scripts

3.  Try to copy what X_ITE does in X3DOM.

Maybe we should vote on the order to pursue these in, if we have limited 
resources.

I am currently exploring loading JSON into x3d.py.  My primary focus has 
been JSON. If someone requires that JSON scripts work in X3DOM, I can 
work on that instead.

John

On 12/4/21 17:06, Brutzman, Donald (Don) (CIV) wrote:
>
> John, for everyone’s convenience, here is current paragraph in X3D4 
> Architecture Annex L HTML Guidelines.
>
> * 
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/htmlGuidelines.html#JavaScriptECMAScript
>
> *L.4.2 JavaScript/ECMAScript considerations*
>
> JavaScript is a programming language that conforms to the ECMAScript 
> specification. The names are often used interchangeably, with 
> ECMAScript indicating strictly specified formal definitions (see 
> ISO/IEC 16262 Information technology — ECMAScript language 
> specification 
> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/references.html#I16262>).
>
> Specified ECMAScript Application Programming Interface (API) 
> capabilities for X3D Script node are defined functionally and 
> syntactically in ISO/IEC 19775-2 X3D Scene Authoring Interface (SAI) 
> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/references.html#I19775_2> and 
> ISO/IEC 19776-1 — X3D ECMAScript encoding 
> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/references.html#I19776>, 
> respectively.
>
> Browser implementations and language versions for 
> JavaScript/ECMAScript engines can vary. Since X3D SAI functional 
> requirements are carefully scoped to match the essential capabilities 
> of this core Web programming language, a single JavaScript/ECMAScript 
> engine can typically be used for both HTML and X3D event handling.
>
> Within a Web browser, implementations for HTML and X3D may share a 
> single JavaScript/ECMAScript engine. Such integration is often 
> important for both performance and synchronization issues. This 
> consideration is especially important when considering the demanding 
> response-time requirements of immersive interfaces and spatial 
> body-tracking devices. To aid portability and avoid unintended 
> overloading of variable references, it is good practice for X3D Script 
> authors to avoid the use of variables with global scope.
>
> Yes an X3D Script node is still a node.
>
>   * X3D4 Architecture Clause 29 Scripting component
>   * https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/scripting.html
>
> Node that XML encoding of all X3D4 nodes and statements includes id, 
> class and style elements so that they can be manipulated via DOM if 
> desired without losing full support for strong XML validation.
>
>   * https://www.web3d.org/x3d/content/X3dTooltips.html#Anchor.class
>   * https://www.web3d.org/x3d/content/X3dTooltips.html#Anchor.id
>   * https://www.web3d.org/x3d/content/X3dTooltips.html#Anchor.style
>
> There has been some speculation in the past that an implementation 
> might need to internally rename embedded X3D Script nodes (to 
> X3dScript or whatnot) in order disambiguate connections via  X3D 
> Script ROUTEs (for X3D event passing) and HTML Script callbacks (for 
> DOM event passing). However no one has ever made the case that authors 
> must do something like that, so that possibility was not included in 
> draft prose by spec editors after working-group review. Further
>
>  1. X_ITE seems to load an X3D scene together with the whole DOM, and
>  2. both current open-source players seem to run the Rosetta Stone
>     Bouncing Ball pretty well, and
>  3. X3D DEF values for ROUTES are not the same as HTML id/class/style
>     values for an X3D Script present in the DOM, and
>  4. it seems like even the slightest Javascript inspection by a
>     program can easily disambiguate the difference between the two
>     kinds of Script.
>
> So, as ever, X3D Script and HTML Script can coexist nicely, and it 
> sure seems like a proven path for implementation.
>
> Confirming: still looks like X_ITE has gotten it right for several 
> years now (thank you Holger). Still looks like X3DOM has not figured 
> it out.
>
>   * X3D Example Archives: VRML 2 Sourcebook, Chapter 30 Scripts,
>     Figure 30 1 Script Sliding Ball
>   * https://www.web3d.org/x3d/content/examples/Vrml2.0Sourcebook/Chapter30Scripts/Figure30_1ScriptSlidingBallIndex.html
>   * https://www.web3d.org/x3d/content/examples/Vrml2.0Sourcebook/Chapter30Scripts/Figure30_1ScriptSlidingBallX_ITE.html
>   * https://www.web3d.org/x3d/content/examples/Vrml2.0Sourcebook/Chapter30Scripts/Figure30_1ScriptSlidingBallX3dom.xhtml
>
> Some worthy work is doubtless needed for X3DOM.  Addition of X3D 
> Prototype support with embedded X3D Script nodes adds perhaps more 
> implementation code with yet-another layer of indirection, but such is 
> Computer Science.  Saving grace: an implementation only has to “get it 
> right once” when aligning with stable standards.
>
> Summary: X3D is unchanged, coexistence with HTML is possible and 
> proven by X_ITE, further work needed by X3DOM.
>
> Have fun reading X3D4 Committee Draft (CD1) Standard!  8)
>
> all the best, Don
>
> -- 
>
> Don Brutzman  Naval Postgraduate School, Code USW/Br brutzman at nps.edu
>
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
>
> X3D graphics, virtual worlds, navy robotics https:// 
> faculty.nps.edu/brutzman
>
> *From:* x3d-public <x3d-public-bounces at web3d.org> *On Behalf Of *John 
> Carlson
> *Sent:* Friday, December 3, 2021 8:06 PM
> *To:* Joseph D Williams <joedwil at earthlink.net>
> *Cc:* X3D Graphics public mailing list <x3d-public at web3d.org>
> *Subject:* Re: [x3d-public] X3D Scripting for X3DOM w/o reading standard
>
> I don’t see how scripts are handled in the CD, or if scripts are 
> actually nodes.
>
> On Fri, Dec 3, 2021 at 4:54 PM Joseph D Williams 
> <joedwil at earthlink.net> wrote:
>
>     To me, that example does not show how a script node in the scene
>     fails.
>
>     Since this topic hardly sees this list (anymore), maybe need to
>     hear from developers and what changes need to be made in x3d4 text
>     up on the web.
>
>     https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/concepts.html#Eventmodel
>
>     Joe
>
>     the
>
>     *From: *John Carlson <mailto:yottzumm at gmail.com>
>     *Sent: *Friday, December 3, 2021 2:07 PM
>     *To: *Joseph D Williams <mailto:joedwil at earthlink.net>
>     *Cc: *X3D Graphics public mailing list <mailto:x3d-public at web3d.org>
>     *Subject: *Re: [x3d-public] X3D Scripting for X3DOM w/o reading
>     standard
>
>     For example, if we see this:
>     https://www.kshell.com/pages/rosetta/rosetta_x3dom.html copied
>     from another email, we see that there are *no* script <field>s in
>     the code.
>
>     Does the X3D4 standard eschew script <field>s?  And instead offer
>     "onclick()" events?
>
>     Thanks!
>
>     John
>
>     On 12/3/21 15:33, John Carlson wrote:
>
>             On Dec 3, 2021, at 1:53 PM, Joseph D Williams
>             <joedwil at earthlink.net> <mailto:joedwil at earthlink.net> wrote:
>
>             
>
>              1. 2.  What are the stumbling blocks to getting script
>                 fields into the event model?
>
>             Hi John,
>
>             Scripts are completely involved in the x3d sai event
>             model. A script must receive an event to begin execution
>             and then it is like an ’external’ in that when the script
>             begins it essentially acts like a beginUpdate and when it
>             completes it essentially gets an endUpdate and all outputs
>             are sent with the same time stamp as kicked off the
>             script. Think of it as script is like any other node that
>             can receive and send events. Only exception is, I think,
>             that a script directOut does not initiate a new cascade
>
>         Part of the thing to do is try script fields in X3DOM and see
>         if they work at all, and if they don’t, try to do a minimal
>         amount of debugging to see what might be done.
>
>         I do not recall if Roy’s work on this is available still or not.
>
>              2. 3.  If scripts are transformed, how?
>
>             If it is ECMAScript then what do you do? What can be done?
>             Break it down into json like any other node? For some
>             reason I hope not.
>
>         Well, one could potentially replace field access with a node
>         attribute util get or set method.   But this can get really
>         tricky, if not impossible to do in all cases.   It would be
>         better to implement script field routes, if possible. See
>         above.  If one could get script field routes into the HTML
>         standard, much, much better…
>
>             Joe
>
>             *From: *John Carlson <mailto:yottzumm at gmail.com>
>             *Sent: *Tuesday, November 30, 2021 11:40 AM
>             *To: *X3D Graphics public mailing list
>             *Subject: *[x3d-public] X3D Scripting for X3DOM w/o
>             reading standard
>
>             Information needed:
>
>             1.   Do scripts in proto bodies get copied?
>
>             2. What are the stumbling blocks to getting script fields
>             into the event model?
>
>             3. If scripts are transformed, how?
>
>             4. What is the new event model for X3D4?
>
>             John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20211204/bda4eb5b/attachment-0001.html>

[x3d-public] X3D Scripting for X3DOM *after* reading standard; X_ITE supports, X3DOM still unimplemented

[x3d-public] X3D Scripting for X3DOM after reading standard; X_ITE supports, X3DOM still unimplemented