<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Andreas,<br>
<br>
There is a lot in this email. You have raised many good questions
and I'm still digesting all of it. I'll going to split it into
pieces so I can more easily address the parts and to make it
easier (I hope) for others to follow.<br>
<br>
<br>
</div>
<blockquote
cite="mid:CAKdk67utE9DyjvQ5ToC+nLxoA8bLV2Rri5Xoe=Hq8WZuagx2=Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Hi Leonard,<br>
<br>
</div>
thank you for this excellent summary of the inline situation in
X3D and x3dom, and the implications in terms of DOM integration
which provides an good basis for a discussion.
<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">
<div bgcolor="#FFFFFF">
<div class="gmail-m_8236270521763696797moz-cite-prefix">
<br>
Some background first. Not that you need this, but
others following the discussion might. The X3D
Standard
(<a moz-do-not-send="true"
class="gmail-m_8236270521763696797moz-txt-link-freetext"
href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#Inline"
target="_blank">http://www.web3d.org/<wbr>documents/specifications/<wbr>19775-1/V3.3/Part01/<wbr>components/networking.html#<wbr>Inline</a>)
indicates that all nodes loaded via an Inline occupy a
separate namescope (sort-of like a name-space, but
without a lot of the structure) from the parent scene.
This prevents direct communication between the parent
and the children of an Inline. The Import/Export
statements allow certain information to be passed
between the parent/child. The namescope applies only
to information passing. Rendering is all rolled-up.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I think it is useful to think about the motivation for
requiring a separate namescope and the default of no
direct communication between the scene and inline content.
One big reason must be that an author should not need to
worry about DEF naming collisions when using an inline.
But is there a fundamental reason to not EXPORT all
inlined nodes by default, eg. allow IMPORTing them ? The
IMPORT statement still enforces the definition of a unique
name for the imported node.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
To my knowledge, there is no technical reason; however, good coding
practice has been to "hide" internal structures, data, and
routines/methods from the caller. This is a little different from
code because the logic structure is not available. I think this may
be more of the case where auto-EXPORTING everything requires a good
reason, rather than assuming it should be done.<br>
<br>
<br>
<blockquote
cite="mid:CAKdk67utE9DyjvQ5ToC+nLxoA8bLV2Rri5Xoe=Hq8WZuagx2=Q@mail.gmail.com"
type="cite">
<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">
<div bgcolor="#FFFFFF">
<div class="gmail-m_8236270521763696797moz-cite-prefix">
X3DOM implements this requirement with the following.
If only the X3D-defined fields are used, then the
Inlined nodes are not loaded into the (HTML) DOM. They
are maintained in the list of rendered nodes so
content can be visible. Since they are not in the DOM,
those nodes cannot be accessed with DOM-oriented calls
(e.g., jQuery). At this time X3DOM does not support
Import/Export.<br>
<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes. There is a slight complication I believe. When
x3dom uses xmlhttprequest to load an inline file, I think
the xml file gets loaded into a separate dom tree which is
then parsed to produce x3dom nodes for the x3d scene graph
which are in turn rendered. So I believe the inline does
have its dom nodes, they are just not part of the main
dom.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Yes, XHR does load it into a dom (not the page DOM) for further
processing. After processing that dom is deleted (technically made
available for garbage collection).<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAKdk67utE9DyjvQ5ToC+nLxoA8bLV2Rri5Xoe=Hq8WZuagx2=Q@mail.gmail.com"
type="cite">
<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">
<div bgcolor="#FFFFFF">
<div class="gmail-m_8236270521763696797moz-cite-prefix">
If the X3DOM field 'namespacename' is present and a
value is provided, the value appended with a double
underscore is prepended to all DEFs. If the field
'mapdeftoid' is TRUE, then the prepending is also done
to IDs (it's actually a little more complicated than
that, but this will do for now). The Inlined nodes are
still maintained in a separate X3-DOM namescope. This
is necessary because Inline's 'url' field can change
and those nodes would need to be removed. The separate
namescope allows those nodes to be identified.<br>
</div>
</div>
</blockquote>
<div> <br>
</div>
Just to give an example:<br>
</div>
<div class="gmail_quote"><Inline url='arrow.x3d'
namespacename='arrow1' /><br>
</div>
<div class="gmail_quote">arrow.x3d:<br>
</div>
<div class="gmail_quote">.. <Material DEF='headcolor' ..
/> ..<br>
<br>
</div>
<div class="gmail_quote">external x3dom access:
document.getElementById('arrow1__headcolor').setAttribute('diffuseColor','1
0 0')<br>
<br>
</div>
<div class="gmail_quote">How would nodes in inlines within
inlines be identified ? Double prefixes ? Imagine an inline
of an bow with arrow: bow1__arrow1__headcolor ?<br>
</div>
</div>
</div>
</blockquote>
<br>
I have not tried this, so this is based on my understanding of the
code (which I know to not be complete). I don't think the parser for
Inline expands any namespacename values so names would not be double
prefixed.<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAKdk67utE9DyjvQ5ToC+nLxoA8bLV2Rri5Xoe=Hq8WZuagx2=Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div class="gmail-m_8236270521763696797moz-cite-prefix">
<br>
[Switching back to regular HTML] Elements added to an
HTML document through the DOM become full elements in
the page's DOM. There is no separate namescope. It is
the responsibility of the adding code to ensure that
there are no 'id' value conflicts (ids are unique
throughout the document). <br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, ids are the responsibility of the author or dom
manipulation code. However, using .querySelector and CSS
selector it is often possible to have a selector specific
enough to identify a unique element without using an id
attribute.<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div class="gmail-m_8236270521763696797moz-cite-prefix">
This is similar to X3D in that DEF names need to be
unique throughout the namescope. This slight variant
allows the author to use an Inline multiple times
because each instance is in its own namescope.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div> In fact, document.querySelector([DEF='uniqueName'])
allows uniquely identifying a x3d node in a DOM
environment without having to introduce id attributes at
all.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Yes. There are many ways to get to a unique element. For example,
the page may only have one <font size="-1"><h1> element or a
single instance of <x3d>. It is not always necessary to use
IDs. Which is used depends on the context of doing the search and
the information the developer has available.</font><br>
<br>
The remainder will be in another email.<br>
<br>
<br>
<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 Architect & Cloud Consultant<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>