[x3d-public] Preliminary Announcement for XSeen: problems in motivation phrasing; multi-spec clarity, DOM interface immediacy

[Leonard Daly]

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.

HTML + DOM + SVG + X3D is really HTML + X3D as HTML, DOM, and SVG are 
all part of the same interoperable standards suite.

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.

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.


I expect to be able to do things like

<HTML-element>.addEventListener("X3D-event", event-handler);
<X3D-element>.addEventListener("HTML-event", event-handler);
and, might as well
<X3D-element>.addEventListener("X3D-event", event-handler);

Also the same for dispatching events
<HTML-element>.dispatchEvent (X3D-event);
<X3D-element>.dispatchEvent (HTML-event);
<X3D-element>.dispatchEvent (X3D-event);

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]

Scripts need to behave like HTML JavaScript

var f = function (x,y) {/*do something...*/};
f(u,v)        // operates on u,v as the function arguments

var _f = f
var f = function (i, e) {/*do something completely different...*/};
f(2,_f); // now performs an operation on 2 and the previous function 'f'

function g() {/* something... */}
var j = {
             'a' : 0,
             'b': 1,
             'c': = function (a,b) {},
             'init': function (z) {
                 this.a = z;
                 this.b = 10*(this.a * this.a) +1;
                 if (this.b > 100) {
                     this.c = f;
                 } else {
                     this.c = _f;
                 }
                 return this;
               }
             };

j.init(2).c(j.a, j.b);    // operate on two scalars
j.init(5).c(j.b, g);      // operates on a scalar and a function

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.]


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.


>
> 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.

I believe that this is in response to my statement:

>
>> 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.


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).



-- 
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170709/90dfa04d/attachment.html>