<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 10/24/2016 8:23 AM, Don Brutzman
      wrote:<br>
    </div>
    <blockquote cite="mid:99da75df-a5fc-6506-3037-d7a1afca3862@nps.edu"
      type="cite">On 10/23/2016 8:18 PM, Leonard Daly wrote:
      <br>
      <blockquote type="cite">On 10/23/2016 2:35 PM, Don Brutzman wrote:
        <br>
        <blockquote type="cite">On 10/22/2016 8:35 PM, Andreas Plesch
          wrote:
          <br>
          <blockquote type="cite">On Oct 22, 2016 6:27 PM, "Don
            Brutzman" <a class="moz-txt-link-rfc2396E" href="mailto:brutzman@nps.edu"><brutzman@nps.edu></a> wrote:
            <br>
          </blockquote>
        </blockquote>
        <br>
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">- loading HTML that contains
              embedded X3D scene
              <br>
            </blockquote>
            <br>
            parsing HTML into a DOM is very available. I am not quite
            sure what scenario you would have in mind here.
            <br>
          </blockquote>
          <br>
          something like
          <br>
          <br>
             
          <a class="moz-txt-link-freetext" href="http://www.web3d.org/x3d/content/examples/HelloWorldCobweb.html">http://www.web3d.org/x3d/content/examples/HelloWorldCobweb.html</a>
          <br>
          or
          <br>
             
          <a class="moz-txt-link-freetext" href="http://www.web3d.org/x3d/content/examples/HelloWorldX3dom.xhtml">http://www.web3d.org/x3d/content/examples/HelloWorldX3dom.xhtml</a>
          <br>
          <br>
          in other words, an HTML document that contains an X3D scene,
          should we have a utility method that loads the document but
          strips out any HTML/CSS/etc. and leaves only X3D scene
          <br>
        </blockquote>
        <br>
        This is potentially risky because JavaScript can modify or even
        create the HTML as the file is loading to produce different
        results. Some HTML frameworks (e.g., React.js) load partial
        content until the region to be display is nearly visible to the
        user, then the entire region is loaded. The scene may also
        contain some vendor-specific scene elements that should not be
        filtered out.
        <br>
        <br>
        It is probably much easier (and safer) if you only accept
        straight X3D than start mandating that the embedded X3D in HTML
        follow some very specific design constraints.
        <br>
      </blockquote>
      <br>
      Security issues are certainly always worth considering.
      <br>
    </blockquote>
    <br>
    Security is potentially an issue. I was thinking of something much
    more just related to content.<br>
    <br>
    Consider the following HTML code snippet<br>
    <br>
    <br>
    <tt><script></tt><tt><br>
    </tt><tt>document.writeln ('<X3D id="x3d_scene" ...>');</tt><tt><br>
    </tt><tt></script></tt><tt><br>
    </tt><tt>    <Scene></tt><tt><br>
    </tt><tt>        <Transform>...</Transform></tt><tt><br>
    </tt><tt>            :</tt><tt><br>
    </tt><tt>
                  :</tt><tt><br>
    </tt><tt>
          </Scene></tt><tt><br>
    </tt><tt></X3D></tt><tt><br>
    </tt><br>
    <br>
    Without the part in the script, there the opening X3D tag is
    missing; however, a browser would handle this correctly. <br>
    <br>
    Another case: Someone is developing a new node -- StereoViewpoint.
    If the extractor program knew X3D nodes, then StereoViewpoint would
    not be identified as such. If the extractor program did not know
    about X3D nodes but took everything between <x3d> and
    </x3d>, then any non-X3D nodes (e.g. HTML elements) would be
    included. <br>
    <br>
    My point being that requiring a capability to store X3D nodes in an
    HTML document is creating a very difficult and perhaps unsolvable
    requirement. For an analogy, you don't see HTML embedded in JPEGs.<br>
    <br>
    <br>
    Leonard Daly<br>
    <br>
    <br>
    <br>
    <br>
    <blockquote cite="mid:99da75df-a5fc-6506-3037-d7a1afca3862@nps.edu"
      type="cite">
      <br>
      Any DOM-tree document is subject to prior modification before
      loading.
      <br>
      <br>
      Importing a DOM document is not a live self-modifying object at
      time of import, rather it is simply the string data contained in
      the DOM element/attribute tree.
      <br>
      <br>
      If a utility method filters out everything but the X3D-related
      document subgraph within an HTML document graph, the security
      issues would seem to be the same as importing an X3D document in
      the first place.
      <br>
      <br>
      all the best, Don
      <br>
    </blockquote>
    <br>
    <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>