[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