<div dir="ltr">Date: Sat, 15 Jul 2017 13:49:47 -0700<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
From: Don Brutzman <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>><br>
To: Leonard Daly <<a href="mailto:Leonard.Daly@realism.com">Leonard.Daly@realism.com</a>><br>
Cc: <<a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>><br>
Subject: Re: [x3d-public] IMPORT/EXPORT Use [was: Statement permitted<br>
        placements]<br>
Message-ID: <<a href="mailto:c4d14574-4751-f384-0fe2-988b2e754701@nps.edu">c4d14574-4751-f384-0fe2-<wbr>988b2e754701@nps.edu</a>><br>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"<br>
<br>
On 7/14/2017 12:08 PM, Leonard Daly wrote:<br>
> Roy did a very detailed analysis of statement location.<br>
<br>
Yes.<br>
<br>
Getting consistent expressions among all the encodings and language bindings will help us avoid problems.  Once again, Object Model for X3D (OM4X3D) shows relevance and can help describe statement location in an object-oriented manner for language bindings.<br>
<br>
> I think that any discussion of IMPORT / EXPORT statements may be premature until it is figured out how files and their nodes will be inlined in HTML. There is a single namespace and namescope in HTML causing the following issues when X3D is integrated with DOM:<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Leonard, not understanding why there seems to be a namespace conundrum, it does not have to the case.<br></blockquote><div><br></div><div>At first glance there is the major difference that X3D inline has a protected, separate namescope while dynamically added content (inlined) for DOM is just part of the main document. So IMPORT/EXPORT only makes sense for DOM if inlined content can somehow be kept separate. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
There are scene demos already showing event routing using DOM, event routing using ROUTES, and a mix (for example ROUTEs in Cobweb-supported scenes).<br>
<br>
Keeping HTML attributes for id associated with DOM events, and separately keeping X3D attributes DEF/USE for ROUTE events, avoids name-collision problems.<br>
<br>
This approach has even further appeal because it can work satisfactorily in a single global DOM tree (which I think you assume) or a primary + shadow DOM approach which decouples ordinary page-refresh HTML from high-frame-rate interactive 3D graphics.<br></blockquote><div><br></div><div> I think this line of thought means there is no real need for IMPORT/EXPORT in DOM ?<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Scoping of X3D DEF/USE visibility already occurs within a ProtoDeclare, and within one or more loaded Inline subgraphs (which already handles your case 4 below), so it is not a far step to similarly define such scoping/separation of namespace tables once in the DOM.  The DOM has no knowledge of DEF/USE, X3D ROUTEs have no knowledge of id attributes, and so coexistence can occur without collision. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In that sense, since the specifications are currently distinct: X3D ROUTE assing events to an HTML5/DOM id (or conversely, HTML5/DOM events to an X3D DEF node) is not defined, and only becomes a problem if new specification definitions create such a problem.  We do not have to create such a conundrum.<br>
<br></blockquote><div><br></div><div>Yes, I think that should be possible (although perhaps such separation is not very elegant). In addition, with X3D nodes being DOM nodes, X3D nodes can be also controlled, eg. receive events, from outside the X3D scenegraph, via SAI. So there is overlap of control by routes and x3d scripts, and control by DOM javascript. Perhaps even competition.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This has been brought up a number of times but still does not appear in your list of alternatives.  Please consider how it avoids the difficulties you describe.  Perhaps there is a better way to describe how this can work?<br>
<br>
Simple illustrative diagram attached with descriptive prose in following Web3D 2017 presentations.  We can further refine and improve this loosely coupled approach based on implementation experience using X3DOM/Cobweb in various HTML browsers.  The "rosetta stone" bouncing-ball example (showing HTML5+DOM+SVG+HTML events+X3D+X3D events+user interaction) is a good place to start.<br>
<br>
        X3D Version 4<br>
        <a href="http://www.web3d.org/x3d4" rel="noreferrer" target="_blank">http://www.web3d.org/x3d4</a><br>
<br>
        "Future of X3D" presentation and detailed notes from Web3D 2017 Conference, Brisbane Australia, 7 June 2017<br>
        <a href="http://www.web3d.org/sites/default/files/page/X3D%20Version%204/FutureOfX3D.pdf" rel="noreferrer" target="_blank">http://www.web3d.org/sites/<wbr>default/files/page/X3D%<wbr>20Version%204/FutureOfX3D.pdf</a><br>
        <a href="http://www.web3d.org/sites/default/files/page/X3D%20Version%204/FutureOfX3dWeb3d2017June7.pdf" rel="noreferrer" target="_blank">http://www.web3d.org/sites/<wbr>default/files/page/X3D%<wbr>20Version%204/<wbr>FutureOfX3dWeb3d2017June7.pdf</a><br>
        <a href="http://www.web3d.org/sites/default/files/image/wg/X3D%20Version%204/PresentationPanoramaFutureOfX3dPaulGrimm20170607_135611.1600x492.jpg" rel="noreferrer" target="_blank">http://www.web3d.org/sites/<wbr>default/files/image/wg/X3D%<wbr>20Version%204/<wbr>PresentationPanoramaFutureOfX3<wbr>dPaulGrimm20170607_135611.<wbr>1600x492.jpg</a><br>
<br>
This loose coupling may be a variation on your approach (C) below? - not sure.  Reconciling Inline/IMPORT/EXPORT names is the same for for event passing to/from any node.  If IMPORT/EXPORT only refer to a DEF name within scoped X3D scene graphs, no collisions occur (as already shown in other X3D encodings).<br>
<br></blockquote><div><br></div><div>ShadowDOM may be the only way to implement strict X3D Inline in a HTML browser as a subtree. However, I am not sure if X3D Inline would be an intended use of ShadowDOM. Since ShadowDOM was not available when x3dom was developed, x3dom just appends the Inline's nodes to the main X3D scene. Also, I am not sure if ShadowDOM is intended to completely prevent access to the added subtree. <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In any case we can't conflate HTML5/DOM event passing with X3D event passing.  They are different.  W3C controls those specifications, while we are aligning X3D specifications to coexist well.  W3C describes functional semantics for the HTML5/DOM/SVG/MathML part of the DOM tree, we will describe functional semantics for the X3D part of the DOM tree.<br>
<br></blockquote><div><br></div><div>Keep in mind there is also the need to define the interfaces between these parts of the DOM tree.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks for considering these valuable possibilities.<br>
<br>
<br>
> 1) All nodes are available to all other nodes at all times<br>
> 2) IMPORT does not have any meaning<br>
> 3) EXPORT does not have any meaning<br>
> 4) Uncertain how to handle a file that gets Inlined more than once since all DEF and ID from the Inline will be duplicated<br>
><br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Possible solutions are:<br>
> A) Do not put the contents of any Inline into the DOM<br></blockquote><div><br></div><div>I think this is what Don suggests.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> B) Do not put the contents of any X3D file into the DOM<br>
> C) Modify the DEF & ID values on each Inline so they are unique<br>
><br>
> (A) has the potential problem of completely hiding all of the interior nodes and making it unavailable. In this case IMPORT and EXPORT can be defined to make sense by providing access to those fields. Unfortunately this breaks a different goal of full DOM integration.<br></blockquote><div><br></div><div>Agreed, that the developer expectation probably would be that Inlined content would be accessible (and I tried to do that for cobweb-dom). On the other hand, a web compatible inline would be probably defined or implemented outside of X3D anyways, in addition to the x3d inline. For example, the webcomponents import functionality (<a href="https://www.webcomponents.org/introduction#html-imports">https://www.webcomponents.org/introduction#html-imports</a>) or html5 template (<a href="https://www.w3.org/TR/html5/scripting-1.html#the-template-element">https://www.w3.org/TR/html5/scripting-1.html#the-template-element</a>) comes to mind.<br><br></div><div>Here is a (thought) experiment with x3dom and import:<br><br></div><div>1) Use import to import a x3dom inline document.<br></div><div>2) write a short script to get the imported scene, clone it, and insert it somewhere into a x3dom main scene, perhaps as a group.<br></div><div>3) see if it works.<br></div><div>4) bonus: write a short custom element 'x3dimport' which does 2)<br></div><div>5) bonus: add an attribute which identifies which import to clone and insert.<br><br></div><div>A web developer would probably try something like this to get inline capability.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
><br>
> (B) This is like (1), but more extreme. It essentially makes X3D plugin-like in that there is complete separation between DOM and X3D.<br>
><br>
> There is a variant on (A)/(B) where only certain (developer controllable) Inline contents are loaded into the DOM. This partially breaks the goal of DOM integration and still leaves the problem of keeping DEF/ID values unique (C)<br>
><br>
> (C) This solution creates a virtual namescope in that the DEF/ID values are modified so that they are unique within the parent DOM. This is potentially tricky since these values can be programmatically assembled. It might be possible to make all of the necessary modifications to the nodes in the Inline file, but unsolvable (or close to it) to change other code in either the parent or other Inline nodes that may cross-refer to those values.<br>
</blockquote><div><br></div><div>With the DOM .querySelector method it is possible to uniquely refer to any node in a DOM since paths and parent child relationships can be used. This makes separate namescopes less of an issue for DOM purposes.<br></div><div> <br></div></div>-- <br><div class="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div></div>