<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>
      Some background first. Not that you need this, but others
      following the discussion might. The X3D Standard
(<a class="moz-txt-link-freetext" href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#Inline">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#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>
      <br>
      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>
      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>
      <br>
      <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>
      <br>
      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>
      <br>
      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>
      <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. 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>
      <br>
      === 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>
      <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>
      <br>
      I created a new public Wiki page on Web3D.org
      (<a class="moz-txt-link-freetext" href="http://www.web3d.org/wiki/index.php/Importing_and_adding_nodes_in_HTML">http://www.web3d.org/wiki/index.php/Importing_and_adding_nodes_in_HTML</a>)
      where results of this discussion are recorded.<br>
      <br>
      <br>
      Leonard Daly<br>
      <br>
      <br>
      <br>
    </div>
    <blockquote
cite="mid:CAKdk67t2Kh-QAHY_qtVjDe1TfZ2OyuoEj67metDQ7Z3Y7YOAYA@mail.gmail.com"
      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("Inline[DEF='arrow']
          Material[DEF='arrowheadmat']).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:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <div bgcolor="#FFFFFF" text="#000000">
                  <div class="m_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.<wbr>io/cobweb_dom/tests/inline_in_<wbr>inline.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="m_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="m_4485260413489110371moz-txt-link-freetext" href="http://sdm.link/slashdot" target="_blank">http://sdm.link/slashdot</a></pre>
      

      <fieldset class="m_4485260413489110371mimeAttachmentHeader"></fieldset>
      

      <pre>______________________________<wbr>_________________
X3dom-users mailing list
<a moz-do-not-send="true" class="m_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="m_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="HOEnZb"><font color="#888888">
</font></span></pre><span class="HOEnZb"><font color="#888888">
    </font></span></blockquote><span class="HOEnZb"><font color="#888888">
    

    <p>

    </p>
    

    <div class="m_4485260413489110371moz-signature">-- 

      <font class="m_4485260413489110371tahoma,arial,helvetica m_4485260413489110371san m_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_signature" data-smartmail="gmail_signature">Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453</div>
</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>