<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">There seems to be some confusion in the
responses from Don and John. <br>
<br>
First I am only discussion Inline and IMPORT/EXPORT. While the
discussion and results may provide useful with PROTOs /
EXTERNPROTOs, these are not part of the discussion; neither are
Events.<br>
<br>
To help clarify things I have started a blog post series on topics
causing integration problems of X3D into DOM.<br>
List of issues: <a class="moz-txt-link-freetext" href="http://realism.com/blog/integrating-x3d-dom-issues">http://realism.com/blog/integrating-x3d-dom-issues</a><br>
Description of Inline issue and possible solution:
<a class="moz-txt-link-freetext" href="http://realism.com/blog/integrating-x3d-dom-inline">http://realism.com/blog/integrating-x3d-dom-inline</a><br>
Ramification of above possible solution:
<a class="moz-txt-link-freetext" href="http://realism.com/blog/integrating-x3d-dom-unique-values">http://realism.com/blog/integrating-x3d-dom-unique-values</a><br>
<br>
Since not everyone would jump to a URL, I'll summarize my findings
here.<br>
<br>
There are not that many issues, some small (case of names), some
quite large (scripts & events). At this time to my knowledge,
only six conflicts have been identified between HTML and X3D. The
other two posts are only looking at Inline and parts by extension,
other external X3D files.<br>
<br>
I believe that I have identified a solution to the namescope issue
for X3D functionality. This is presented and discussed in the
second link. <br>
<br>
The third link discusses a ramification of that solution
pertaining to ID values.<br>
<br>
The import take-away in the solution is that it provides a means
for X3D applications (the code that displays X3D content) to
maintain separate namescopes (at least for Inline) for X3D
functionality AND preserve DOM structure for HTML functionality.
At this early stage, this appears to work for everything except
the 'id' attribute. The 'id' attribute (or field) is not defined
in 19775-1, only the XML encoding (4.3.4 --
<a class="moz-txt-link-freetext" href="http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#DEFAndUSEAttributeSyntax">http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#DEFAndUSEAttributeSyntax</a>).
<br>
<br>
I will address the other issues at a future time.<br>
<br>
I am using Andrea's message to respond because I think it is the
most recent.<br>
<br>
<br>
</div>
<blockquote type="cite"
cite="mid:CAKdk67v6VVQc8m0CkUDuBtH2gugaDuM+c38vtLwVCTv7UYV3JQ@mail.gmail.com">
<div dir="ltr"><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">
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>
</div>
</blockquote>
<br>
<br>
To answer Don's questions about understanding... <br>
It is possible to Inline the same file multiple times. If each file
is loaded into the parent's namescope than any DEF names will not be
unique. DOM has a single namescope.<br>
<br>
<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAKdk67v6VVQc8m0CkUDuBtH2gugaDuM+c38vtLwVCTv7UYV3JQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</div>
</div>
</blockquote>
<br>
<br>
These topics are complex enough. You (Don) are adding so many other
topics to the conversation that there is almost no hope of
understanding and resolution. Even though X3D event routing is one
of the primary reasons for having DEF names, including events into
this part of the conversation brings up a large number of issues
with the difference between X3D events and DOM events. It is very
important to keep those separate right now.<br>
<br>
I don't think there is a clear understanding of shadow-DOM. The W3C
working draft (2017-02-03) is at <a class="moz-txt-link-freetext" href="https://www.w3.org/TR/shadow-dom/">https://www.w3.org/TR/shadow-dom/</a>.<br>
A shadow-DOM is a document object model (structure) that
participates in rendering, but is not part of the primary DOM. It
must be attached to an existing element with the .attachShadow
method. It allows elements to be rendered without their styling
"leaking" into the rest of the page. Putting things in the Shadow
DOM does not mean they are inaccessible from the regular DOM. <br>
<br>
Shadow-DOM is not some sort of magical hidden DOM that provides
complete separation of regular DOM from special stuff. I am sure
that new and imaginative ways of using it will come about, but that
is difficult to do right now when the spec is still being developed.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAKdk67v6VVQc8m0CkUDuBtH2gugaDuM+c38vtLwVCTv7UYV3JQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
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>
</div>
</blockquote>
<br>
This is the trailer to my solution in the posts listed at the top of
this message.<br>
<br>
<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAKdk67v6VVQc8m0CkUDuBtH2gugaDuM+c38vtLwVCTv7UYV3JQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
I did. It's in the posts. I've described this issue before, but I
think this is the first time I collected pieces on one fairly narrow
topic and included a potential solution for most of the problem.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAKdk67v6VVQc8m0CkUDuBtH2gugaDuM+c38vtLwVCTv7UYV3JQ@mail.gmail.com">
<div dir="ltr">
<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">
<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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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>
</div>
</div>
</div>
</div>
</blockquote>
<br>
X3DOM uses the namespacename attribute to determine what to do with
an Inline. If it is blank, then the X3D nodes are not put into the
DOM and only appear in the scene graph. If it is defined, the DEF
and ID (depending on other attributes) are modified and the nodes
are entered into the DOM with the modified values. Note that there
are still issues if an Inlined file Inlines a second file. If the
first file is Inlined more than once and supplies a value for
namespacename, then there will still be name conflicts.<br>
<br>
X3DOM does not use Shadow DOM.<br>
<br>
My issue with IMPORT/EXPORT is for the case where there is a single
namescope. What is the use/value of such statements when all they
can do is alias names, since everything is imported/exported anyway.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAKdk67v6VVQc8m0CkUDuBtH2gugaDuM+c38vtLwVCTv7UYV3JQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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">
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>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
I am very explicitly not mixing X3D events and DOM events. That is
another topic.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAKdk67v6VVQc8m0CkUDuBtH2gugaDuM+c38vtLwVCTv7UYV3JQ@mail.gmail.com">
<div dir="ltr">
<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">
<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"
moz-do-not-send="true">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"
moz-do-not-send="true">https://www.w3.org/TR/html5/scripting-1.html#the-template-element</a>)
comes to mind.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Web Components are (or will be) part of the browser, though there
are poly-fill libraries for these right now. Simple intro to Web
Components --
<a class="moz-txt-link-freetext" href="https://developer.mozilla.org/en-US/docs/Web/Web_Components">https://developer.mozilla.org/en-US/docs/Web/Web_Components</a><br>
<br>
<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAKdk67v6VVQc8m0CkUDuBtH2gugaDuM+c38vtLwVCTv7UYV3JQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><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>
</div>
</div>
</div>
</div>
</blockquote>
<br>
I presume that (1) is 'Use Inline..."<br>
<br>
The contents of external X3D files can be stored as elements, not in
the DOM (but in variables stored in the DOM). Since it is not in the
DOM, it would not need to be cloned. <br>
<br>
Are you talking about something like:<br>
<br>
var externalX3d = readExternal (externalUrl);<br>
var copyOfExternalX3d = deepClone (externalX3D);<br>
var ele = document.getElementById('AppropriateX3dNodeElementId');<br>
ele.addChildren (copyOfExternalX3d);<br>
<br>
// (4): package up the above to meet the requirements<br>
// Not sure what you mean by (5)<br>
<br>
<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAKdk67v6VVQc8m0CkUDuBtH2gugaDuM+c38vtLwVCTv7UYV3JQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
x3d-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>
<a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
</pre>
</blockquote>
<p><br>
</p>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>