[x3d-public] Preliminary Announcement for XSeen: problems inmotivation phrasing

Leonard Daly Leonard.Daly at realism.com
Sun Jul 9 09:35:02 PDT 2017


John,

These are all reasonable questions. I'll try to answer each one.

> Leonard writes:
>
> >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. That may happen in the 
> future, but that has been worked on without public results for over 
> three years.
>
> I have some questions.  What are the requirements for being DOM 
> integrated?
>

At this time there are no public requirements for DOM integration. See 
http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development#Candidate_Capabilities 
for the most complete statement I could find on that.


> Which DOM do you refer to? Isn’t DOM more of a language or library 
> feature rather than a potential X3D feature?
>

DOM is an API for HTML/XHTML pages. From https://www.w3.org/DOM/

"The Document Object Model is a platform- and language-neutral interface 
that will allow programs and scripts to dynamically access and update 
the content, structure and style of documents. The document can be 
further processed and the results of that processing can be incorporated 
back into the presented page. This is an overview of DOM-related 
materials here at W3C and around the web."

It's not a language, it's an API. It's not a feature, its the API of the 
web browser.

> Is it merely that X3D Scripts support DOM?
>

No. Since it is the API and describes how all of the components of a web 
page interact with each other and the browser, it defines element 
interaction. Everything (tag, attribute, etc.) in the DOM is an element.


> I have loaded DOM into both Cobweb and X3DOM, without the need for 
> many complex extensions, just a DOM producer and JQuery or interfaces 
> to the browser ($(selector).append () line 405 of 
> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/loaderJQuery.js 
> for X3DOM, importDocument() line 205 of 
> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/loaderJQuery.js 
> for Cobweb).
>


You can't load DOM into anything. Things interact with other things via 
DOM. The $(selector) interface is jQuery, which is a support library on 
top of DOM, originally designed to provide a standardized interface to 
different browsers. Much of the basic functionality of jQuery has been 
included in standardized DOM, which all modern (FF, Chrome, Edge, 
Safari, Opera (I think)) support.



> By using DOM, you can get DOM events, however, I think what you are 
> saying is that Cobweb and X3DOM scenegraphs are not DOM event 
> integrated.  I can see that.
>

You get DOM events once you are in a browser. What you do with them is 
up to your code. Once you are in a browser, you can produce DOM events. 
These are not the same as X3D events, nor do they follow the X3D event 
cascade. X3DOM does use DOM events (at least for some or maybe all) 
operations. If there is a cascade mechanism in X3DOM, then it is all 
custom-built as part of X3DOM. I do not know enough about Cobweb to comment.


> If we want the X3D scenegraph integrated with the DOM events, that 
> will likely take a lot of work, which I believe Leonard is the only 
> brave soul doing—I have been off generating events from JavaScript. 
> However, I would warn him that it’s likely that the THREE.js 
> scenegraph isn’t DOM integrated either, but likely he knows the answer 
> to this better than I do.
>

There are incompatibilities between X3D and DOM. It might be possible to 
build a lot of software that runs in a DOM environment to emulate X3D, 
particularly the event model. I have a partial implementation of events. 
I can handle events
  1) from HTML elements to XSeen nodes
  2) from XSeen nodes to XSeen nodes
  3) from XSeen nodes to HTML elements

all using regular (including custom) DOM events. I don't think this 
solution is particularly elegant, so I think it needs more thought; but 
it does work. Examples to be posted within a couple of days.


I don't believe it is possible to have the 3D scene graph fully 
integrated with the DOM. If it were, we wouldn't be doing this work. 
What is really needed is that the interface to the 3D scene graph is 
fully integrated. That means changing the property (not necessarily the 
attribute) of an element shows up in the 3D scene graph and a scene 
graph change shows up in the element's property. It means that events 
are handled uniformly throughout the page. It means that scripts are 
defined and work the same whether they operate on X3D nodes, HTML 
elements, or the browser.

The whole goal of this effort is to get W3C approval of a 3D language 
that is as fully integrated into the browser as HTML rendering is now.


> Will we ever see a scenegraph integrated with the DOM events? Isn’t 
> that the goal?
>
> Perhaps the best approach to DOM integration is to try it OUTSIDE the 
> web environment first.
>

It is possible as the W3C has defined bindings for Java. There are also 
non-W3C DOM Bindings that could be used.

But, if you worked outside the web environment, why is this organization 
called Web3D Consortium?


-- 
*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/441a6faa/attachment-0001.html>


More information about the x3d-public mailing list