<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Part 2 -- skipping all of the material
covered in the previous email...<br>
<br>
This part addresses Inlines calling Inlines calling ..., multiple
uses of content, perhaps from different locations, and how to
access all of them...<br>
<br>
Well I was going to write that, but I have been doing a lot of
thinking about the proper structure and role of X3D. I think once
that is defined a lot more will flow into place. <br>
<br>
Inline (and related - some not yet defined) nodes are really
important. They allow a developer to build a scene in pieces (or
multiple developers to work on a scene). I cannot foresee a
situation where something like that does not exist. <br>
<br>
The details of how to access the internals may change depending on
how the data is loaded (potentially the data format) and the kind
of protection that might be needed. For example a model may
represent a part that should not be modified (because of
licensing, etc.). The X3D library may need to enforce (to an
extent) that restriction by not exposing that model to the DOM and
user modification. Note that I am not arguing for absolute
protection or DRM mechanisms. <br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
</div>
<blockquote
cite="mid:CAKdk67utE9DyjvQ5ToC+nLxoA8bLV2Rri5Xoe=Hq8WZuagx2=Q@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">
<div class="gmail_quote">
<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>
<br>
</div>
<div>multiple instances of inlines:<br>
<br>
</div>
<div><Inline DEF='a1' namespacename='arrow1'
url='arrow.x3d' /><br>
<Inline DEF='a2' namespacename='arrow2' url='arrow.x3d'
/><br>
<br>
</div>
<div>This only would make sense if there is a plan to modify
each arrow individually (otherwise, the second arrow would
be a USE instance).<br>
document.getElementById('arrow1__headcolor').setAttribute('diffuseColor','1
0 0')<br>
document.getElementById('arrow2__headcolor').setAttribute('diffuseColor','0
1 0')<br>
<br>
</div>
<div>There is an equivalent EXPORT/IMPORT path for SAI
access.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
<br>
As was discussed in the previous email, the double prefix convention
is probably not used. Even if it was, names could easier get carried
away so not to be much use. Some of my statements below get more
into best development practices rather than strictly specification
or implementations.<br>
<br>
Traditional X3D development creates very deep node trees as the
developer tries to reuse as much as possible. This does reduce the
memory footprint at the expense of added complexity in the scene.<br>
<br>
<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><br>
</div>
<div>The cobweb dom bridge allows similarly:<br>
<br>
document.querySelector('Inline[DEF="a1"]
Material[DEF="headcolor"]').setAttribute('diffuseColor','1
0 0')<br>
</div>
<div>or shorter since the DEFs are unique within their
subtrees:<br>
document.querySelector('[DEF="a1"]
[DEF="headcolor"]').setAttribute('diffuseColor','1 0 0')<br>
document.querySelector('[DEF="a2"]
[DEF="headcolor"]').setAttribute('diffuseColor','0 1 0')<br>
<br>
</div>
<div>As you can see this looks quite similar to
namespacename prefixes but does not require the additional
field, and instead just can use the DEF field. This kind
of brings up the question why x3dom does not simply use
the DEF name as namescope prefix ? Is there a case where
you would want to use different DEF names but the same
namespacename ? <br>
</div>
<div><br>
</div>
<div><Inline DEF='a1' namespacename='arrow1'
url='arrow.x3d' /><br>
<Inline DEF='a2' namespacename='arrow1' url='arrow.x3d'
/><br>
</div>
<div><br>
</div>
<div>I cannot see immediately how this could be of use ?<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">
<div bgcolor="#FFFFFF">
<div class="gmail-m_8236270521763696797moz-cite-prefix">
A 3D environment in a web page should be able to
Inline the same file multiple times (e.g., a row of
trees) without causing a problem with the DOM. It
should also be possible to group and individually
animate those objects. For example, a number of trees
of the same kind would all sway in the wind. Trees of
the same height would behave similarly. One tree might
be special and need to sway differently. It should be
possible to apply an animation to the entire class of
trees and a special animation to the special tree. If
all of the trees had the same class, then (at least
theoretically) the animation could be applied to the
class. The special tree would have a unique ID so that
could be animated separately.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>There is class attribute for HTML elements for
convenient selection of all elements belonging to the same
class. I tend to think it is more of a convenience
feature. <br>
<br>
</div>
<div>Let's think through the scenarios:<br>
<br>
</div>
<div>1) multiple instances: DEF/USE for cloning, multiple
DEFs with the same url for individual instances<br>
</div>
<div>2) swaying trees: DEF='swayingTree' / USE ; animate
swayingTree internally<br>
</div>
<div>3) swaying trees, but each a bit differently: more of a
case for prototypes, could include script for sway
behaviour depending on height<br>
</div>
<div>4) special tree: DEF='special Tree', access and animate
specially<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">
<div bgcolor="#FFFFFF">
<div class="gmail-m_8236270521763696797moz-cite-prefix">
<br>
What Andreas has written below is an
element-attribute-value selector that goes down to the
final leaf to set a value. If the Inline's parent (the
file that contains the node <Inline
url='InlineParent.x3d'>) uses this node multiple
times, then Andreas' querySelector statement would
change all of the arrowheads that fit the criteria.
This is not necessarily bad, but just needs to be
considered.</div>
</div>
</blockquote>
<div><br>
</div>
<div>.querySelector always only selects a single element. If
they are multiple elements which fit the selector, the
'best' fit is chosen or all things being equal the first
one. .querySelectorAll gives you all the fitting elements.<br>
<br>
</div>
<div>I think it is true to say that it is always possible to
construct a path from an Inline node down to the targeted
node inside which is unique. DEFs inside the inline need
to be unique within their scene and DEFs in the parent
also need to be unique. So it is always possible to
construct [DEF='parentName'] [DEF='nodeName'] or in prefix
notation parentName__nodeName .<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">
<div bgcolor="#FFFFFF">
<div class="gmail-m_8236270521763696797moz-cite-prefix">
Anything not starting with an ID reference or a unique
tag in the scene (e.g., <body>) may not refer to
a unique node.<br>
</div>
</div>
</blockquote>
<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">
=== InlineParent.x3d ===<br>
:<br>
<Inline DEF='arrow'
url='arrow.x3d'></Inline><br>
:<br>
<br>
<br>
=== arrow.x3d ===<br>
:<br>
:<br>
<Appearance><br>
<Material DEF='arrowheadmat' diffuseColor='0 0
1'></Material><br>
:<br>
</Appearance><br>
<br>
<br>
</div>
</div>
</blockquote>
<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>
So I think rather than ask what would it take to adopt
the selector approach, a more fundamental question
needs to be answered - how should files be imported
into a scene and inserted into the (HTML) DOM? I think
once that question is answered the rest will be easy.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>This is certainly a good question to ask. I thought
about not exposing Inlined content at all for DOM access
for cobweb, and instead rely on html templating or the
newish HTML Imports functionality which deals with similar
issues. With HTML Imports an HTML file is imported as a
separate DOM first and then can be cloned and appended
into the main document. It feel like this could replace a
lot of the Inline functionality. I should put together an
example page using HTML Imports (which is rejected by
Mozilla).<br>
<br>
</div>
<div>The question how files should be imported also implies
if there should be a change in how EXPORT/IMPORT works now
for X3D/SAI ? Both x3dom and cobweb_dom implicitly export
all nodes in an inline. Should EXPORT/IMPORT be
streamlined similarly ?<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">
<div bgcolor="#FFFFFF">
<div class="gmail-m_8236270521763696797moz-cite-prefix">
I created a new public Wiki page on Web3D.org (<a
moz-do-not-send="true"
class="gmail-m_8236270521763696797moz-txt-link-freetext"
href="http://www.web3d.org/wiki/index.php/Importing_and_adding_nodes_in_HTML"
target="_blank">http://www.web3d.org/wiki/<wbr>index.php/Importing_and_<wbr>adding_nodes_in_HTML</a>)
where results of this discussion are recorded.<br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Leonard,
<div><br>
</div>
<div>I guess I am looking for guidance and a
discussion on how ideally content internal to
Inlines should be identified. I do like the CSS
selector approach because if does not involve
adding an additional namespacename field to
Inline. But there may be other approaches.</div>
<div><br>
</div>
<div>What would it take to adopt the selector
approach in x3dom ? So you can do this:</div>
<div><br>
</div>
<div>SceneElement.querySelector("<wbr>Inline[DEF='arrow']
Material[DEF='arrowheadmat']).<wbr>setAttribute("diffuseColor","1
0 0")</div>
<div><br>
</div>
<div>-Andreas</div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Oct 1, 2016 at
11:54 PM, Leonard Daly <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:web3d@realism.com"
target="_blank">web3d@realism.com</a>></span>
wrote:<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_8236270521763696797m_4485260413489110371moz-cite-prefix">Andreas,<br>
<br>
I am not sure if you are looking for
comments, advice, discussion, or just
posting a notice. I don't want to go off
on a tangent here. I am rather familiar
with how and almost why X3DOM does it.<br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
</div>
<blockquote type="cite">
<p dir="ltr">I am working on adding DOM
access to inline scenes for my Cobweb
DOM bridge:</p>
<p dir="ltr"><a moz-do-not-send="true"
href="https://andreasplesch.github.io/cobweb_dom/tests/inline_in_inline.xhtml"
target="_blank">https://andreasplesch.github.i<wbr>o/cobweb_dom/tests/inline_in_i<wbr>nline.xhtml</a></p>
<p dir="ltr">The idea is to add the
external inline scene DOMs to the main
scene DOM as children of the Inline
elements. Once added, the mutation
observer picks up modifications of
these children and does not need to do
anything other than it already does
for the main scene.</p>
<p dir="ltr">It works well although I do
not know how web browsers deal with
large combined DOMs. Also, a small
addition to Cobweb.js is currently
needed.</p>
<p dir="ltr">One effect is that one can
use CSS selectors with querySelector
to drill down to specific elements in
inline scenes, even through
hierarchies of inlined inlines. See
example. This way the DEF names can be
used even if they are identical across
scenes. X3D semantics and functioning
is not affected.</p>
<p dir="ltr">X3dom uses a different
approach of prefixes to id/DEF
attributes to enable access to
elements in inlines. Not sure if x3dom
could use instead or in addition
Selectors ? This would require adding
the Inline DOMs to the main DOM but
perhaps this is already almost done ?</p>
<p dir="ltr">So I am considering also
adding the same option of a
namespacename prefix to element IDs
but the effort would be really for
compatibility. Thinking about it,
while possible probably not a priority
unless there is a compelling use case.</p>
<p dir="ltr">X3D has EXPORT/IMPORT to
deal with accessing nodes in inlines.
I think the SAI equivalent is roughly
that all nodes are EXPORTed by default
and that in addition to a DEF name it
becomes possible to address a node by
its path in the scene hierarchy.
Perhaps something to consider for the
standard: X3D selectors.</p>
<p dir="ltr">Andreas</p>
<br>
<fieldset
class="gmail-m_8236270521763696797m_4485260413489110371mimeAttachmentHeader"></fieldset>
<br>
<pre>------------------------------<wbr>------------------------------<wbr>------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! <a moz-do-not-send="true" class="gmail-m_8236270521763696797m_4485260413489110371moz-txt-link-freetext" href="http://sdm.link/slashdot" target="_blank">http://sdm.link/slashdot</a></pre>
<fieldset class="gmail-m_8236270521763696797m_4485260413489110371mimeAttachmentHeader"></fieldset>
<pre>______________________________<wbr>_________________
X3dom-users mailing list
<a moz-do-not-send="true" class="gmail-m_8236270521763696797m_4485260413489110371moz-txt-link-abbreviated" href="mailto:X3dom-users@lists.sourceforge.net" target="_blank">X3dom-users@lists.sourceforge.<wbr>net</a>
<a moz-do-not-send="true" class="gmail-m_8236270521763696797m_4485260413489110371moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/x3dom-users" target="_blank">https://lists.sourceforge.net/<wbr>lists/listinfo/x3dom-users</a><span class="gmail-m_8236270521763696797HOEnZb"><font color="#888888">
</font></span></pre><span class="gmail-m_8236270521763696797HOEnZb"><font color="#888888">
</font></span></blockquote><span class="gmail-m_8236270521763696797HOEnZb"><font color="#888888">
<p>
</p>
<div class="gmail-m_8236270521763696797m_4485260413489110371moz-signature">--
<font class="gmail-m_8236270521763696797m_4485260413489110371tahoma,arial,helvetica gmail-m_8236270521763696797m_4485260413489110371san gmail-m_8236270521763696797m_4485260413489110371serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font>
3D Systems Architect & Cloud Consultant
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</font></span></div>
</blockquote></div>
<div>
</div>--
<div class="gmail-m_8236270521763696797gmail_signature">Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453</div>
</div></div></div>
</blockquote>
<p>
</p><div class="gmail-m_8236270521763696797moz-signature">--
<font class="gmail-m_8236270521763696797tahoma,arial,helvetica gmail-m_8236270521763696797san gmail-m_8236270521763696797serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font>
3D Systems Architect & Cloud Consultant
President, Daly Realism - <i>Creating the Future</i>
</font></div></div></blockquote></div>
--
<div class="gmail_signature">Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453</div>
</div></div>
</blockquote>
<p>
</p><div class="moz-signature">--
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font>
3D Systems Architect & Cloud Consultant
President, Daly Realism - <i>Creating the Future</i>
</font></div></body></html>