[x3d-public] X3D Scripting for X3DOM w/o reading standard
John Carlson
yottzumm at gmail.com
Sat Dec 4 14:08:03 PST 2021
I appreciate your confidence in me, but I feel that I would make a mess
of it. Plus, if I can't read existing standards, I probably can't
figure out how to improve them either.
I have similar problems with videos, TV episodes, books, etc. I've been
working on doing better with videos, but it seems that YouTube makes me
angry now.
For some reason, my ability to email people remains. I don't know if I
comprehend things too well in emails.
I feel it's best to stick with my strong points in bug finding, problem
solving and creativity. I am not sure if there's a place for that in
Web3D/X3D.
I totally understand that X_ITE supports script <field>s, but I don't
know if script <field>'s are required to be supported by the standard.
I think the main sticking point is that HTML does not support script
<field>'s, so neither does X3D4? But somehow, X_ITE supports <field>s
in scripts, and does DOM as well, via Andreas' extension. It would
seem that X3DOM could support scripts given some effort. When I tried,
I ran up against <field>'s not being supported, so I bailed. But
perhaps someone with a bit more persistence could get past that, IDK.
Integrating Protos and Scripts still seems to be an unsolved problem in
X3DOM? Is my effort the only one that actually has some modicum of
success (with some of my own files)? If we start somewhere, should we
start with my effort, or X_ITE? Or another path?
I opened email to report a possible misunderstanding in x3d.py. I'll put
that in another email.
Thanks!
John
On 12/4/21 12:30, Brutzman, Donald (Don) (CIV) wrote:
>
> Hi John. You reasonably ask “Does the X3D4 standard eschew script
> <field>s? And instead offer "onclick()" events?”
>
> Ummm, why wonder ever again? Why not propose fixing X3D4 if unclear
> or incorrect? Together we are in charge of our own destiny.
>
> * X3D4 Architecture, Committee Draft CD1, Annex L HTML authoring
> guidelines
> * https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/htmlGuidelines.html
>
> The X3D4 guidelines are intended to complement HTML5. Building up
> behavior examples (like the rosetta-stone bouncing ball) that show
> HTML DOM being HTML DOM, and X3D being X3D, is a very good approach.
>
> Thanks for all scrutiny, demonstration, and possible improvements.
> Looking forward to steady continuing progress together as a community.
>
> p.s. Have fun with X3D4 and HTML5! 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 2:07 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
>
> For example, if we see this:
> https://www.kshell.com/pages/rosetta/rosetta_x3dom.html
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kshell.com%2Fpages%2Frosetta%2Frosetta_x3dom.html&data=04%7C01%7Cbrutzman%40nps.edu%7Cd58b5c7907f946261f5908d9b6a95d50%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637741660814396507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=m8v5lK7iHaM%2Bplb5%2BxUiBaJjyI4F%2BHuNox1t%2BCwd6ro%3D&reserved=0>
> 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
> <mailto:x3d-public at web3d.org>
> *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/6971ce65/attachment.html>
More information about the x3d-public
mailing list