[x3d-public] x3d-public Digest, Vol 153, Issue 11

Sat Dec 4 16:36:53 PST 2021

Thanks, John, for reviving the Script node discussion. I think Don's
summary is accurate. Let me add a few observations.

1) 'Script' vs 'x3dScript'

The issue is not that a x3d browser implementation would not be able
to distinguish a x3d script from a html script. That would be
straightforward. The issue is that in a tight html/x3d integration
framework the html browser also needs to distinguish a x3d from a html
script. The current web browsers do not know about x3d and therefore
try to execute a x3d script as a html script which of course will not
work.

However, this is a minor problem since adding a non-default type
attribute to a html script node will cause the html browser to ignore
it. The question is only if there should be something in the x3d spec.
about adding such a type attribute to script html/xml node (perhaps in
an html encoding).

x_ite does not have to deal with that because it never exposes the x3d
xml to the web browser's page dom. It just processes the xml
internally. x_ite_dom therefore has to deal with that and does it in
the way described.

2) safe script execution

An open issue for js based x3d browsers such as x_ite or x3dom is that
it is considered unsafe for a web page to allow execution of arbitrary
code not obviously controlled by the web page. This means it is
recommended to not use eval() of a javascript text which may be
manipulated. However, any script node implementation would need to use
eval(). x_ite does not worry and uses eval() anyways. It is probably
not hard to craft an innocent looking x3d which then does something
unwanted, like freezing the web browser, or abusing cpu for mining, or
tricking the user into switching on the webcam. On the other hand,
whenever a web browser opens some html page the page can contain any
arbitrary scripts also. Perhaps only the expectation of the user is
different. In a way x3d would provide another layer of indirection and
a way to hide unsafe code, such as in Inline nodes.

In theory, it may be possible for an x3d browser to sanitize somewhat
a x3d script, perhaps by removing any invocations of DOM methods. But
this seems hard to accomplish and would only provide a false sense of
security.if done incompletely. Another way may be to follow Castle
Engine, and implement CastleScript which is quite limited and
therefore safer. This would be probably slow since it means another
layer of interpretation.

3) strategy

Most functionality afforded by x3d script nodes can be replicated by
html script nodes in x3dom due to strong coupling between x3d and dom
albeit of course in a non-standard x3d fashion. So  implementing a x3d
script node leads to duplication and perhaps some confusion of users
which are not familiar with the x3d script node. Most users are
familiar with html script nodes but not x3d script nodes. It just
doesn't seem quite sound to have two competing script nodes. On the
other hand gaining standard compatibility is of course very valuable.
Another question is how tightly coupled x3d and html and the web
should become. Although an original and obvious goal, standalone, non
web centric x3d browsers have shown that x3d is very valuable
decoupled from the web. This suggests that any tight coupling (for
example of x3d and dom events) may need to be defined in another spec.
layer. Perhaps something like a web access interface which for example
clarifies event translation.

Sorry, this came out longer than anticipated. Thanks for reading, any
feedback welcome,

Andreas

On Sat, Dec 4, 2021 at 6:07 PM <x3d-public-request at web3d.org> wrote:
> Date: Sat, 4 Dec 2021 23:06:47 +0000
> From: "Brutzman, Donald (Don) (CIV)" <brutzman at nps.edu>
> To: John Carlson <yottzumm at gmail.com>, Joseph D Williams
>         <joedwil at earthlink.net>
> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>,
>         "Brutzman, Donald (Don) (CIV)" <brutzman at nps.edu>
> Subject: Re: [x3d-public] X3D Scripting for X3DOM *after* reading
>         standard; X_ITE supports, X3DOM still unimplemented
> Message-ID:
>         <BY3PR13MB4884FF1A7AC622462095D58AC46B9 at BY3PR13MB4884.namprd13.prod.outlook.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> 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<mailto: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.
>
>
>
>   1.  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/40b74605/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> ------------------------------
>
> End of x3d-public Digest, Vol 153, Issue 11
> *******************************************

-- 
Andreas Plesch
Waltham, MA 02453