<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Michael, X3D community,<br>
      <br>
      I think you raise some very good and valid points here. X3D is at
      a point where patchwork solutions will not be enough to remain
      relevant. Hence in my opinion its not just about nodes and
      encodings that need to be re-considered, but also some of the
      fundamental concepts.<br>
      <br>
      I hope that this discussion (I tried to encourage as well with my
      mail) has not died but is continued on the member mailing list.<br>
      <br>
      Best,<br>
        Kristian<br>
      <br>
    </div>
    <blockquote cite="mid:565B94E7.4060204@noegenesis.com" type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=windows-1252">
      Being not a deeply technical computer graphics person, but being a
      member of the Board as a Professional Member representative, I
      wanted to voice my opinion regarding the direction of X3D 4.0 as I
      interpret it from Don's post below.<br>
      <br>
      To remain a viable and robust 3D standard for years to come, and
      to in fact be an archival 3D standard, X3D must remain relevant. 
      When I say relevant, that means to be easy to understand, to take
      advantage of current technology trends and to be widely adopted. 
      Whereas X3D has weathered many ups and downs in the 3D industry
      over the past 25 years, outlasting numerous 3D files formats and
      initiatives, it is a completely different environment now.  <br>
      <br>
      The democratization of 3D content is upon us, fueled by decades of
      video game technology providing the impetus for better and better
      software tools, higher and higher performance graphics hardware,
      and a culture that now demands 3D experiences both within and
      without of the video gaming experience.  These forces have
      permeated the mobile industry, which is rapidly becoming the
      hardware platform of choice.  WebGL has enabled 3D within browsers
      without a plugin, making the browser an ideal distribution vehicle
      for 3D data and content, regardless of the device.  Soon all
      mobile devices will be 3D content generators, thanks to built in
      3D cameras, and virtual reality displays, thanks to Cardboard and
      GearVR (and others to come).  <br>
      <br>
      In my opinion, X3D cannot wait out the 3D storm this time, because
      forces influencing this industry are going to fundamentally change
      how 3D fits into society, (think 3D printing, VR videos, etc.).  
      X3D must adapt to meet this change, and with the web being the
      ideal distribution vehicle, X3D must adapt to the HTML
      environment.  Don's post to me speaks instead to a stay the course
      strategy, maintaining paradigms in contradistinction to HTML. 
      There are key concepts in X3D which clash with HTML, and if not
      reconciled, this will be to X3D's detriment and potential road to
      irrelevance.  Why?  Simple: Compare the number of web developers
      to the number of X3D developers; the difference is several orders
      of magnitude! This is the target audience of X3D, and they will
      not tolerate learning 2 different ways to do many of the functions
      necessary to create a dynamic 3D environment.  Some may say that
      different vertical industries will create their own proprietary
      applications and that web development is irrelevant, and I argue
      that while that is true, the volume and value of those
      applications pale in comparison to web applications within any
      industry.  Being part of one of the biggest vertical industries
      (healthcare) as an IT executive, I can tell you that off-the-shelf
      technology based on the web/cloud is the preferred choice.  Web
      applications are easier to maintain, easier to implement and
      easier to have personnel trained on their use. <br>
      <br>
      Many may argue that this approach can endanger backwards
      compatibility, which is critically important for an <b><i>archival</i></b>
      standard, but to that I say that members of the Consortium are
      very smart and capable of doing things that people say never could
      happen, like having polygons and voxels living together (gasp!) in
      the same scene.  They can develop converters for old content so
      that 20 year old content still runs on the newest browsers.<br>
      <br>
      Many may say that web developers aren't our target audience, which
      to that I say, are you interested in protecting some academic
      institutions and a small portion of industrial applications from
      from vendor lock-in, or do you want to protect the majority of
      content developers, consumers and the majority of industrial
      applications from this lock-in (whose savings would then be passed
      on to the consumer)?  I choose the latter.<br>
      <br>
      The way forward does not lack suggestions: Leonard Daly has done a
      significant amount of thinking and work on providing a vision of a
      possible X3D 4.0 that blends well with HTML concepts, Tony Parisi
      has developed GLAM,
      <meta charset="utf-8">
      another "declarative language for creating 3D web content" and
      Kristian Sons' post on November 26 with subject: "XML3D 5.0 and
      X3D V4.0" (XML3D being another declarative 3D web language)
      provides great lessons learned
      <meta charset="utf-8">
      on some ways that X3D can adapt HTML concepts.  The Consortium can
      co-opt all the best from these suggestions to provide a phenomenal
      3D standard for the future.<br>
      <br>
      I have been involved in some form with the Consortium for 20
      years, from the VeRGe meetups organized by Linda Jacobson and
      Timothy Childs in the 90s, to founding a startup using VRML
      technology in 2000, to representing the Consortium at SIGGRAPH and
      Professional Members on the Board for the last several years.  I
      want the Consortium to succeed in its original mission to provide
      an open, ISO ratified, royalty free, archival standard that is
      like an HTML for 3D on the web.  To achieve that mission, the
      Consortium needs to make X3D a web native language.<br>
      <br>
      Thank you,<br>
      <br>
      Michael Aratow, MD<br>
      Board of Directors, Web3D Consortium<br>
      Chief Medical Information Officer, San Mateo Medical Center<br>
      CEO, VRecover<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <table class="moz-email-headers-table" border="0" cellpadding="0"
        cellspacing="0">
        <tbody>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject:
            </th>
            <td>Re: [x3d-public] [x3d] Ideas for discussion during V4.0
              Concepts: Name scopes and node name conflicts</td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date: </th>
            <td>Wed, 18 Nov 2015 09:28:26 -0800</td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th>
            <td>Don Brutzman <a moz-do-not-send="true"
                class="moz-txt-link-rfc2396E"
                href="mailto:brutzman@nps.edu"><brutzman@nps.edu></a></td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Organization:


            </th>
            <td>Naval Postgraduate School</td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
            <td>Roy Walmsley <a moz-do-not-send="true"
                class="moz-txt-link-rfc2396E"
                href="mailto:roy.walmsley@ntlworld.com"><roy.walmsley@ntlworld.com></a></td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">CC: </th>
            <td>X3D Graphics public mailing list <a
                moz-do-not-send="true" class="moz-txt-link-rfc2396E"
                href="mailto:x3d-public@web3d.org"><a class="moz-txt-link-rfc2396E" href="mailto:x3d-public@web3d.org"><x3d-public@web3d.org></a></a>,
              X3D Graphics Working Group <a moz-do-not-send="true"
                class="moz-txt-link-rfc2396E"
                href="mailto:x3d@web3d.org"><x3d@web3d.org></a></td>
          </tr>
        </tbody>
      </table>
      <br>
      <br>
      <br>
      [cc: x3d-public]<br>
      <br>
      Thanks for the excellent leading questions and deep exploration in
      today's X3D working group teleconference.<br>
      <br>
      Questions and my first-cut responses follow.<br>
      <br>
      On 11/18/2015 2:40 AM, Roy Walmsley wrote:<br>
      > Some things to consider and/or discuss re X3D V4.0 during X3D
      WG meeting.<br>
      ><br>
      > ·What is DOM?<br>
      <br>
      DOM is the simplest possible API for accessing and traversing an
      HTML/XML tree structure, with accessors typically getting/setting
      nodes and attributes using string values.<br>
      <br>
      DOM also includes several event models that are associated with
      navigating a tree, and passing values from one node to another.<br>
      <br>
      DOM bindings have been formally specified for JavaScript and
      Java.  No doubt a number of libraries exist in other languages as
      well.<br>
      <br>
      The essential stability of the data structures, and the potential
      flexibility of the event-passing mechanisms, are the key to DOM's
      long-running stability, popularity and effectiveness.<br>
      <br>
      > ·What specification(s) should we be normatively considering?
      (<a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="http://www.w3.org/TR">http://www.w3.org/TR</a>)<br>
      <br>
      DOM level 3 has been a stable W3C Recommendation for 10 years<br>
      <a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="http://www.w3.org/TR/DOM-Level-3-Core">http://www.w3.org/TR/DOM-Level-3-Core</a><br>
      <br>
      DOM behavior is central to HTML5 design.<br>
      <br>
      3 Semantics, structure, and APIs of HTML documents<br>
      <a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="http://www.w3.org/TR/html5/dom.html#dom">http://www.w3.org/TR/html5/dom.html#dom</a><br>
      <br>
      DOM level 4 is where DOM refinements are heading.  The editors
      include critical individuals in this long evolution.  Based on
      current status, it is pretty far down the W3C Process towards
      final approval.<br>
      <br>
      W3C DOM4, W3C Proposed Recommendation 6 October 2015<br>
      <a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="http://www.w3.org/TR/dom/">http://www.w3.org/TR/dom/</a><br>
      <br>
      An important working document, but not normative, is the "DOM
      Living Standard" by the whatwg<br>
      <a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="https://dom.spec.whatwg.org">https://dom.spec.whatwg.org</a><br>
      <br>
      Of course "living" standard/document is a euphemism that actually
      means "unstable" or "nonstandard."<br>
      <br>
      I believe our strategy should be:<br>
      <br>
      a. Let HTML5 be HTML5 and let X3D be X3D.  Each is well defined.<br>
      b. Let X3D v4 add minimal general capabilities that provide a
      clean elegant stable alignment with HTML5 and DOM level 4.<br>
      c. The essence of this alignment is event passing between HTML5
      DOM and X3D event graph.<br>
      d. Do not add any functionality to X3D that breaks the current
      event model, or might have to change in the future when further
      DOM embellishments occur.<br>
      <br>
      Suggest that the next question to explore is:<br>
      <br>
      - What is SAI?  What are differences between "internal" and
      "external" SAI?<br>
      <br>
      In short, SAI reconciled internal event passing and external event
      passing with the series of X3D API specifications.<br>
      <br>
      No longer needed:  External Authoring Interface (EAI). 
      Nevertheless interesting (and possibly helpful) approaches were
      specified there.<br>
      <br>
      > ·How does DOM compare to SAI? (<a moz-do-not-send="true"
        class="moz-txt-link-freetext"
        href="http://www.w3.org/TR/DOM-Level-3-Core/introduction.html">http://www.w3.org/TR/DOM-Level-3-Core/introduction.html</a>
      and <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/concepts.html#General">http://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/concepts.html#General</a>).


      Are they conceptually different?<br>
      <br>
      Comparing/contrasting each of these approaches with DOM APIs for
      tree manipulations and event passing will be fruitful.<br>
      <br>
      X3DOM (and presumably Cobweb) provide existence proofs that event
      passing between each is possible and can be pretty simple.<br>
      <br>
      Key X3D constructs:  ROUTEs, Inline IMPORT/EXPORT.<br>
      <br>
      Also important parts of event-model review (identified by Joe) are
      Script directOut functionality, the notion of a render frame (time
      step) and event cascades, loop-breaking rule, etc.<br>
      <br>
      Since many events between X3D and DOM will be related to user
      interaction, closely aligned topics are javascript callbacks,
      browser render loops, etc. etc.<br>
      <br>
      Our eventual X3D v4 specification solution will define DOM
      constructs with equivalent 2-way functionality.<br>
      <br>
      >  Should SAI be renamed / substituted by DOM?<br>
      <br>
      No.  Such a change would likely break X3D event semantics, either
      now or in the future.  That outcome is not acceptable.<br>
      <br>
      Comparisons between SAI, EAI and DOM will let us assess what needs
      to be specified to align X3D and DOM.<br>
      <br>
      > ·What does the DOM say about namespaces? How have MathML and
      SVG been incorporated?<br>
      ><br>
      > ·Can we point to examples that illustrate difficulties?<br>
      ><br>
      > ·What practical steps should we take to progress?<br>
      <br>
      Worthy questions deserving further elaboration.  We need to
      include CSS and Javascript in that review as well.<br>
      <br>
      If/when we do this correctly, X3D rises to the level of being an
      effective addition that integrates well within the Open Web
      Platform (OWP).<br>
      <a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="http://www.w3.org/wiki/Open_Web_Platform">http://www.w3.org/wiki/Open_Web_Platform</a><br>
      <br>
      Precise terminology and descriptions are critical ingredients for
      effective design.  Thanks for all due diligence on these central
      topics.<br>
      <br>
      all the best, Don<br>
      -- <br>
      Don Brutzman  Naval Postgraduate School, Code USW/Br       <a
        moz-do-not-send="true" class="moz-txt-link-abbreviated"
        href="mailto:brutzman@nps.edu"><a class="moz-txt-link-abbreviated" href="mailto:brutzman@nps.edu">brutzman@nps.edu</a></a><br>
      Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA  
      +1.831.656.2149<br>
      X3D graphics, virtual worlds, navy robotics <a
        moz-do-not-send="true" class="moz-txt-link-freetext"
        href="http://faculty.nps.edu/brutzman"><a class="moz-txt-link-freetext" href="http://faculty.nps.edu/brutzman">http://faculty.nps.edu/brutzman</a></a><br>
      <br>
      _______________________________________________<br>
      x3d-public mailing list<br>
      <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
        href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
      <a moz-do-not-send="true" 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><br>
      <br>
      <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>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
_______________________________________________________________________________

Kristian Sons
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH, DFKI
Agenten und Simulierte Realität
Campus, Geb. D 3 2, Raum 0.77
66123 Saarbrücken, Germany

Phone: +49 681 85775-3833
Phone: +49 681 302-3833
Fax:   +49 681 85775–2235
<a class="moz-txt-link-abbreviated" href="mailto:kristian.sons@dfki.de">kristian.sons@dfki.de</a>
<a class="moz-txt-link-freetext" href="http://www.xml3d.org">http://www.xml3d.org</a>

Geschäftsführung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff

Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
_______________________________________________________________________________</pre>
  </body>
</html>