[x3d-public] X3Dv4 and event passing between X3D scenes and HTML5/DOM page

Brutzman, Donald (Don) (CIV) brutzman at nps.edu
Fri Mar 22 15:06:00 PDT 2019


Thanks for the excellent observations Andreas, you are right that we need to be precise.  We should refer to W3C Recommendations closely/carefully in order to do that.

Yes I was “starting simple” and thinking earlier from point of view that HTML attribute names/values, and corresponding DOM tree names/values, are string based.  Am pretty sure that DOM still has different levels, with different functionality on each - will check.  If I recall correctly, basic set/get accessors at Level 1 are string based.  Apologies if that has changed or is incorrect.  Getting crisp about value definitions versus event definitions is important.

Looking forward to our paying close attention to the DOM specifications, nomenclature, levels, specialty methods, conformance requirements, etc. etc.  If we follow design patterns shown by SVG we also might conceivably define specialty DOM methods for X3D... but we should likely resist the urge to customize whenever possible in order to utilize existing DOM functionality.  Starting with conservative capabilities can hopefully provide the foundation to help us maximize deployment and library-compatibility options... then continue towards more advanced object-based approaches when advisable.

Certainly X3DOM and X_ITE approaches need to be carefully considered in detail. Whatever works - broadly, and for long term stability/evolution.  Looking forward to next steps: improved understanding, X3D-string value mappings, X3D-DOM event mappings, analysis of alternatives, X3D-HTML render-loop timing considerations, design reconciliation, and specification documentation together.

Hope that helps.  Continued improvement welcome, again thanks.

 v/r Don

Sent from my handheld device

On Mar 21, 2019, at 2:19 PM, Andreas Plesch <andreasplesch at gmail.com<mailto:andreasplesch at gmail.com>> wrote:

I am not sure how to interpret the statement below that DOM events
have string values. HTML attributes (similar to fields) have string
values. But DOM events carry an event object as payload (value)
supplied to an event listener function. This event object is of type
object and can include any typed values in key-value pairs. For
example, x_ite_dom generates DOM events for each X3D output event
which has the X3D output as typed value in an event.value key.
Conversely, x_ite_dom does not use DOM events to map changes in HTML
attributes to X3D input events (or other SAI actions). It uses another
DOM facility, called the MutationObserver, which is what is
recommended.

I think we need to start to be more careful in using nomenclature if
there is to be better compatibility. Generally speaking, DOM events
are quite different from X3D events. Also, HTML is markup, and DOM is
an object model which is generated from the markup and has an API so
it can manipulated. The DOM is what the browser uses to generate a
page view. This means, for example, that almost all of a web page can
be generated dynamically, with minimal markup.

Best, Andreas

Date: Thu, 21 Mar 2019 16:53:37 +0000
From: "Brutzman, Donald (Don) (CIV)" <brutzman at nps.edu<mailto:brutzman at nps.edu>>
To: John Carlson <yottzumm at gmail.com<mailto:yottzumm at gmail.com>>
Cc: X3D Graphics public mailing list <x3d-public at web3d.org<mailto:x3d-public at web3d.org>>
Subject: Re: [x3d-public] FW: X3Dv4 and event passing between X3D
       scenes and HTML5/DOM page

[modified subject line to match topic]

Your analysis looks correct to me.

Am happy to note that event consistency with HTML5/DOM is indeed central to the X3Dv4 specification efforts.  Overview and detailed goals remain online at

       X3D Version 4
       http://www.web3d.org/X3D4

       X3D Version 4.0 Development
       http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development

Of note: all DOM events have string values.  All X3D events have typed values, which can be read in or written out as strings.  Clock timestamps are the same for both.  Thus compatibility is feasible.

As you also note, X3DOM and X_ITE can each handle such events (with some differences in their respective approaches).  I think it is great that we have two implementations because it guarantees eventual success and currently gives us two variations on this critical theme.  Consistency and well-written specification prose are needed next.

Current focus continues to be explored via the list: clearly defining timing requirements for event passing, and building example pages/scenes that can be used as demonstration tests for implementers.  Coding skills in plain-old JavaScript scripting and  X3DOM/X_ITE codebases are really important in this regard.  Reconciliation and harmonization have the potential to support... um, well, everyone on the Web.

Progress continues.  State of play will be presented at Web3D 2019 conference in LA this summer.  X3Dv4 functional lockdown is 16 DEC 2019.  Total bliss is expected to occur sometime this year, between now and then...

Having fun with X3D, HTML5 and DOM!   8)


On 3/21/2019 1:45 AM, John Carlson wrote:
From below:

types??? It seems like X3DOM and X_ITE are already handling some events differently.?? Likely this will drive a deathstrike to the standard if events aren?t standardized.? Browsers will all go invent their own event types, and content won?t play across different browsers.? If we adopt HTML5 as a way to create events, that is **independent** of X3D browser, that might be a way to go.

This really needs to be looked at carefully.?? One reason that X11 failed to capture the games market was they didn?t get sound events coordinated with graphics events in time.? I do not know if this is still an issue with Linux.

I am pretty sure there?s already a way to coordinate things in time with timestamp.? I am not sure how many browsers use the timestamp in events.?? We may need to coordinate events across the network for the NetworkSensor.? OpenCroquet/OpenCobalt may have a way: https://en.wikipedia.org/wiki/Croquet_Project#Synchronization_architecture https://en.wikipedia.org/wiki/Open_Cobalt#Synchronization_architecture

(written in Squeak).

John

Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

*From: *John Carlson <mailto:yottzumm at gmail.com>
*Sent: *Thursday, March 21, 2019 3:17 AM
*To: *X3D Graphics public mailing list <mailto:x3d-public at web3d.org>
*Subject: *X3Dv4
[...]

Already submitted in another place.

http://tools.realism.com/comment/15#comment-15

Is there going to be a standard for event type

John
all the best, Don

--
Andreas Plesch
Waltham, MA 02453

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org<mailto:x3d-public at web3d.org>
http://web3d.org/mailman/listinfo/x3d-public_web3d.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190322/071dac3b/attachment-0001.html>


More information about the x3d-public mailing list