[x3d-public] [x3d] X3D meeting minutes 22 FEB 2019: X3D v4 Development statuscategories

[John Carlson]

Yeah, I was relaxing most of the day yesterday.  I may have posted incorrect information.    But I still believe x3dom fields are not handled at all for scripts, based on prior research, and up-to-date investigation in the chrome browser (fields and related attributes are black for scripts).   .  They are handled for ComposedShader, and we might use that as an example for handling Script fields.

Good luck, it’s up to someone else besides me.  It should be fairly simple to activate script fields I hope.  I am not sure you want them in HTML scripts anyway.

John

Sent from Mail for Windows 10

From: Brutzman, Donald (Don) (CIV)
Sent: Friday, March 1, 2019 6:11 PM
To: John Carlson
Cc: X3D Graphics Working Group; X3D Graphics public mailing list
Subject: Re: [x3d] X3D meeting minutes 22 FEB 2019: X3D v4 Development statuscategories

Thanks for these observations John.

I think this points us at the importance of syntax for sending events to destinations, either (X3D -> HTML) or (HTML -> X3D).

There are several links in today's minutes of relevance: event descriptions and diagrams for both X3D and HTML.

The X3Dv4 spec defines functionality - this will tell authors how to construct what they need, and tell implementers what syntax/semantics to support.  In other words, interoperable content.  It does not mandate how an implementation gets coded.

Building examples and comparing X3DOM and X_ITE together should get us on path to convergence.

It would be good to get Roy Walmsley's original HTML+SVG+X3D+Javascript demo of "bouncing ball" back on center stage and refreshed.  Anyone know where it is?  Valuable role here for someone...


On 3/1/2019 2:19 PM, John Carlson wrote:
> In other words, to prevent script source code from appearing on the rendered page, I had to remove the text or CDATA node. I am fairly sure I removed the field nodes as well for X3DOM in X3DJSONLD, favoring my own implementation.
> 
> I believe that text nodes are incompatible with execution, but it might be worth seeing how something like jsfiddle does it, if they keep a shadow script or what.
> 
> I believe you can keep the fields in DOM (I didn’t) if you have an X3DOM implementation of them.
> 
> On Fri, Mar 1, 2019 at 4:03 PM John Carlson <yottzumm at gmail.com <mailto:yottzumm at gmail.com>> wrote:
> 
>     In other words, scripts (really script fields) do not appear in DOM and do not receive or generate DOM events.
> 
>     John
> 
>     On Fri, Mar 1, 2019 at 3:46 PM John Carlson <yottzumm at gmail.com <mailto:yottzumm at gmail.com>> wrote:
> 
>         As far as I know there is no Script “class” or source file in X3DOM, thus no place to hang fields, thus nowhere to hook up routes.  I did write one at one time, it didn’t seem that difficult, but I’m not presently on board to rewrite it.   I suggest looking at other implementations of fields.
[...]


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 http://faculty.nps.edu/brutzman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190302/7752f080/attachment.html>