<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">This is a long email and there is no
way I can hit on all of the points in it. I will respond to a few
that caught my eye as I was reading through it.<br>
<br>
HTML + DOM + SVG + X3D is really HTML + X3D as HTML, DOM, and SVG
are all part of the same interoperable standards suite.<br>
<br>
Requiring that X3D make adjustments to HTML and/or DOM is like
requiring the period at the end of this sentence to have input
into every web page. <br>
<br>
I always thought that we (Web3D Consortium) was trying to get X3D
fully integrated into the web page environment. That requires that
X3D be fully integrated into HTML, DOM, and browser. Note that
this is X3D being integrated into... not X3D creating a bubble in
HTML/DOM for it to operate. It also means that X3D should
"look-like" existing HTML and JavaScript.<br>
<br>
<br>
I expect to be able to do things like<br>
<br>
<tt><HTML-element>.addEventListener("X3D-event",
event-handler)</tt><tt>;<br>
</tt><tt><X3D-element>.addEventListener("HTML-event",
event-handler);</tt><tt><br>
</tt>and, might as well<br>
<tt><X3D-element>.addEventListener("X3D-event",
event-handler);</tt><tt><br>
</tt><br>
Also the same for dispatching events<br>
<tt><HTML-element>.dispatchEvent (X3D-event);</tt><tt><br>
</tt><tt><X3D-element>.dispatchEvent (HTML-event);</tt><tt><br>
</tt><tt><X3D-element>.dispatchEvent (X3D-event);<br>
</tt><tt></tt><br>
Note that all of the events above are DOM events. Although not
illustrated here, events need to be capturable and bubble. DOM
provides a mechanism for defining custom events. [FYI: XSeen does
all of this and handles ROUTE statements as well]<br>
<br>
Scripts need to behave like HTML JavaScript<br>
<br>
<tt>var f = function (x,y) {/*do something...*/};</tt><tt><br>
</tt><tt>f(u,v) // operates on u,v as the function
arguments</tt><tt><br>
</tt><tt><br>
</tt><tt>var _f = f</tt><tt><br>
</tt><tt>var f = function (i, e) {/*do something completely
different...*/};</tt><tt><br>
</tt><tt>f(2,_f); // now performs an operation on 2 and the
previous function 'f'</tt><tt><br>
</tt><tt><br>
</tt><tt>function g() {/* something... */}</tt><br>
<tt>var j = {</tt><tt><br>
</tt><tt> 'a' : 0,</tt><tt><br>
</tt><tt> 'b': 1,</tt><tt><br>
</tt><tt> 'c': = function (a,b) {},</tt><tt><br>
</tt><tt> 'init': function (z) {<br>
this.a = z; <br>
this.b = 10*(this.a * this.a) +1; </tt><tt><br>
if (this.b > 100) {<br>
this.c = f;<br>
} else {<br>
this.c = _f;<br>
}<br>
return this;<br>
}<br>
</tt><tt> };<br>
<br>
j.init(2).c(j.a, j.b); // operate on two scalars<br>
</tt><tt>j.init(5).c(j.b, g); // operates on a scalar and a
function<br>
</tt><tt><br>
</tt>If things like this can't be done in X3D, then X3D is working
in a bubble in HTML/DOM. [Note that this is intended as developer
code, not code in an X3D library running in a web page.]<br>
<br>
<br>
You might be able to create an X3D V3-compliant event model, but
it will differ from DOM in that there is no concept of a cascade
that halts the clock in DOM. A triggered event is scheduled for
execution at the next available time. In all applications
(browsers) that I have seen, this means after the current thread
completes execution. If the main execution thread generates an
event A, that will run at the first break in the main thread. If A
generates an event B, that runs after A. If B then generates A,
there is no need to loop-breaking because there is no loop.<br>
<br>
<br>
</div>
<blockquote type="cite"
cite="mid:d89449ea-1cb1-387b-1cfb-2402d17fd70f@nps.edu">
<br>
Again as before: it is important to be wary of incorrect
characterizations that can contradict or confound others, helping
no one. It is better to build, since getting clear about
challenges helps focus candidate solutions to best effect.
<br>
</blockquote>
<br>
I believe that this is in response to my statement:<br>
<br>
<blockquote type="cite"
cite="mid:d89449ea-1cb1-387b-1cfb-2402d17fd70f@nps.edu"><br>
<blockquote type="cite">X3D in all public releases of the standard
is not DOM integrated. There are no public documents that
explicitly show how a future generation of X3D would be DOM
integrated. <br>
</blockquote>
</blockquote>
<br>
<br>
The rebuttal offers no public document that shows how X3D would be
integrated with DOM. The extensive reply puts together a lot of
pieces that don't really address the issue (no illustration of how
to solve the big discrepancies), just a recognition that they exists
("special API calls needed" -- from whiteboard picture).<br>
<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 & Cloud Consultant<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>