<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:1539244343;
        mso-list-type:hybrid;
        mso-list-template-ids:-1382929472 -1 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level2
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level3
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l0:level4
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level5
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level6
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l0:level7
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level8
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level9
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style></head><body lang=EN-US link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal>Andreas, if you look at Don’s event loops picture, there’s a double loop, and (DOM, X3D) events exchange between the loops.  I don’t know how it’s determined what goes over to the “other side” but somehow that’s determined. Probably an event cannot be exchanged twice.  Simple as that. We have booted the ROUTE issues for now (until we are ready I presume) and are focusing merely on events, much to my chagrin.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Until we rename the script tag in X3D, fields cannot be added to scripts, per HTML5 schema (I think).  Until fields can be added to scripts, we cannot add ROUTEs to scripts.  Reimplementing the script tag might be implemented with new Function.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The challenge would be to replace script fields with  DOM or JS since they can’t be added to X3DOM (replacing current X3D techniques).  That was the essence of my attempt in X3DJSONLD (bring X3DOM back into the X3D fold was a big effort of X3DJSONLD).  I got really hung up when I had to deal with a node field type and punted. (Actually, it was the JS replacement of variables in calls to my nodeUtil, see below for want ad).  If we pursue my technique, I recommend that we have a designer take two ROUTEs involving a script (those ROUTEs not currently handled by X3DOM) and break it down to JavaScript (to and from a script).  It’s going to get really confusing when a toField or fromField on a ROUTE refers to type SFNode field, I know.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Maybe we can go both ways and meet in the middle. I suggest we define a good SAI interface that we can build a declarative XML structure on top of, instead of trying these various implementations.   Suggestions?  What are the requirements for the SAI interface:</p><p class=MsoNormal><o:p> </o:p></p><ol style='margin-top:0in' start=1 type=1><li class=MsoListParagraph style='margin-left:0in;mso-list:l0 level1 lfo1'>Route to XML with node.field</li><li class=MsoListParagraph style='margin-left:0in;mso-list:l0 level1 lfo1'>Route from XML  with node.field</li><li class=MsoListParagraph style='margin-left:0in;mso-list:l0 level1 lfo1'>Route to Scripts with script node, JavaScript variable or function</li><li class=MsoListParagraph style='margin-left:0in;mso-list:l0 level1 lfo1'>Route from Scripts with script node, JavaScript variable or function</li><li class=MsoListParagraph style='margin-left:0in;mso-list:l0 level1 lfo1'>Routes have a to and a from.</li><li class=MsoListParagraph style='margin-left:0in;mso-list:l0 level1 lfo1'>Routes are ran from events on the to side.</li></ol><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Is that it?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I have implemented an event loop that has a timestamp In X3DJSONLD.  See: <a href="https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/Script.js#L159">https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/Script.js#L159</a></p><p class=MsoNormal>I think it might be overwhelming to do an eval in a loop.  I imagine a denial of service attack could be mounted on code memory (is this why eval is evil?)  Better designs are  welcome.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>If you make any changes, please test with X3DJSONLD/src/main/html/prototypes.html and your own tests.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Lurking in the background is the Proto Expander.   It currently copies scripts to new namespaces, so it’s currently not affected.   That was my secret to implementing Protos before Scripts.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I do not know the future of ROUTEs. I know it’s going to be difficult to do declarative programming without them, if they go away.  I suggest we get together with other declarative programming people, and present a design which will capture the browser builder’s attention. If anything, I would encourage current X3D browser makers to support ROUTEs, if merely to drive implementers crazy!</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>If anyone is an expert on replacing script variable names with function calls on the DOM (return element, set attribute, get attribute and lower level X3DOM calls), please contact me.  I could really use your help.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>John</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> for Windows 10</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='border:none;padding:0in'><b>From: </b><a href="mailto:andreasplesch@gmail.com">Andreas Plesch</a><br><b>Sent: </b>Monday, March 4, 2019 10:20 PM<br><b>To: </b><a href="mailto:brutzman@nps.edu">Don Brutzman</a><br><b>Cc: </b><a href="mailto:x3d-public@web3d.org">X3D Graphics public mailing list</a><br><b>Subject: </b>Re: [x3d-public] X3D meeting minutes 1 MAR 2019: X3Dv4 architectureand event-exchange diagrams, progress review</p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>I am getting a better sense now that there is a discussion on how to enable the DOM event mechanism for X3D events.</p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Currently, as mentioned, x3dom dispatches the same event ('outputchanged') for any x3d output event. An event listener function has to look into the event payload to determine what event happened. </p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>X-ITE does not interact with the DOM. With x_ite_dom.js it does and dispatches dom events for every output event. The dom events are named after the fieldname with a 'x3d_' prefix, for example x3d_isOver.</p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Routes</p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I suppose the equivalent to routes for DOM nodes is an event listener which changes the attribute of an element or/and a property of a DOM node. For HTML, routes would not be very useful since the payload value of events is not necessarily designed to become directly the value of an attribute. I think the reason is that events are thought of as part of dynamic, scripted changes and markup and css more for static, declarative content in HTML.</p></div><div><p class=MsoNormal>It might be possible to represent (and implement) x3d events and routes with dom events and dom event listeners except for the idea that there is a cascade of many events with a single timestamp.</p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Not sure how useful this was, Andreas</p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>---on the phone---</p></div></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Fri, Mar 1, 2019, 7:18 PM Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a> wrote:</p></div></div><p class=MsoNormal style='margin-left:4.8pt'>Thanks for helpful information Andreas.  Partial responses:<br><br>On 3/1/2019 2:24 PM, Andreas Plesch wrote:<br>[...]<br>>  > c. Are ROUTE connections consistent?<br>> <br>> Not sure what the question is. Consistent. Perhaps about timestamps?<br><br>Sorry.  Intended context is authoring... what does HTML/X3D page/scene look like syntactically, any differences there?<br><br><br>>  > d. X3DOM is still missing some important/simple Event Utility nodes - is there a problem?<br>> <br>> Here are the currently implemented event utility nodes:<br>> <br>> <a href="https://github.com/x3dom/x3dom/tree/master/src/nodes/EventUtilities" target="_blank">https://github.com/x3dom/x3dom/tree/master/src/nodes/EventUtilities</a><br>> <br>> I can help if any are missing or misbehaving but I am not aware of any. Only the dev version has the nodes.<br>So perhaps we just need to deploy dev versions, and update status spreadsheet?<br><br>        X3D Node Inventory Comparison (updated 23 December 2017) shows<br>                implementation coverage of the X3D Abstract Specification<br>        <a href="http://www.web3d.org/specifications/X3dNodeInventoryComparison.xlsx" target="_blank">http://www.web3d.org/specifications/X3dNodeInventoryComparison.xlsx</a><br>        <a href="http://www.web3d.org/specifications/X3dNodeInventoryComparison.ddf" target="_blank">http://www.web3d.org/specifications/X3dNodeInventoryComparison.ddf</a><br><br>all the best, Don<br>-- <br>Don Brutzman  Naval Postgraduate School, Code USW/Br       <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149<br>X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" target="_blank">http://faculty.nps.edu/brutzman</a></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>