[x3d-public] [x3d] X3D-HTML event passing, let's look at simplest aspects first

[John Carlson]

So here’s the problem I think.   Separate from event handling we don’t have
a way to ROUTE to and from any script in the X3DOM.  May I suggest this is
a W3C or ECMA issue and not a Web3d  one?  Should we raise ROUTEs as a W3C
issue?  Certainly framework are trying to handle ROUTEs in various ways
(angular).

It would seem like we are trying to confound a domain specific issue with a
generic web issue.

I for one would like to ROUTEs between CSS selectors.   This would be more
generic.   This is a valuable feature we would like to see in all web
browsers, not just ones with 3d graphics.

John

On Mon, Mar 4, 2019 at 1:27 AM John Carlson <yottzumm at gmail.com> wrote:

> Do we measure how well we brought Scripting into embedded X3D Scripts in
> x3dv4 by handling fields or ignoring fields or coming up with a new syntax?
>
> If we can be honest and say we are supporting fields or not supporting
> fields from the get go, that will help us narrow our effort.   Let’s do the
> requirements before the design by all means.
>
> Is ROUTEing to and from HTML Scripts a requirement?
>
> Is ROUTEing to and from X3D Scripts a requirement?
>
> Is ROUTEing from HTML Scripts to X3D Scripts a requirement?
>
> Is ROUTEing from X3D Scripts to HTML Scripts a requirement?
>
> Is ROUTEing a requirement?
>
> Is event handling a requirement?  In script?  In XML?
>
> Once we have agreed on the requirements, we can proceed with the design
> (double loop architecture).
>
> On Mon, Mar 4, 2019 at 12:51 AM John Carlson <yottzumm at gmail.com> wrote:
>
>> Don, I am not interested in chasing loops around.   I put a full effort
>> into creating a scenegraph to JavaScript connection for X3DOM.   It’s time
>> to go somewhere else to look at the alternatives.   I highly suggest
>> looking at X_ITE’s code and other working code.  My code seems to be
>> fundamentally incomplete (does not handle namespaces properly for one).
>>
>> It starts to get really complex when you use a node as a field.  A field
>> is not just a signpost
>>
>> If someone wants to tell me X3D scripting is done for X3DOM, I will go
>> look at it.   I see absolutely no evidence that fields are handled for
>> Scripts.
>>
>> I am not focused on X3Dv4 and have other tasks.
>>
>> I do not want to battle over email.   I am just trying the best I can to
>> report the effort I made.
>>
>> John
>>
>> On Sun, Mar 3, 2019 at 4:33 PM Brutzman, Donald (Don) (CIV) <
>> brutzman at nps.edu> wrote:
>>
>>> Thanks for your helpful analysis John.  Here are some reactions.
>>>
>>> Expectation: field definitions for Script and ProtoInstance merely
>>> define logical connections where events are sent + received.  Of course a
>>> particular DOM node labeled "field" with name/type/accessType/value
>>> attributes is not the final destination we are interested in connecting -
>>> that particular DOM node is simply a signpost label, pointing towards
>>> author code living elsewhere inside the actual X3D player.
>>>
>>> Basics: the X3D scene is integral within the X3D browser, and the HTML
>>> scripts are external in the HTML page within the HTML browser.  Each is a
>>> separate set of content, handled by a pair of browsers running in separate
>>> blocks of code.
>>>
>>> We are figuring out the best way for an author to define connections for
>>> those events that are expected to pass back and forth between HTML page and
>>> X3D scene.
>>>
>>> The DOM representation of X3D scene content is just that - a
>>> representation - and any X3D player needs to listen and relay events in
>>> either direction.
>>>
>>> Remember that an "event" is simply a timestamp + value, getting passed
>>> from source to destination.
>>>
>>> There may be several ways for browsers to implement such event passing
>>> between HTML and X3D content using JavaScript.  Varieties of implementation
>>> are fine since the X3D Specifications do not legislate how the code must be
>>> written - rather the X3Dv4 specification will simply define syntax and
>>> semantics for such event passing.
>>>
>>> Thinking even more simply: of course the same activity must happen for
>>> all the other X3D nodes that produce or consume events.  The functionality
>>> for other nodes is already defined in the specification already, so that is
>>> considered straightforward in comparison.
>>>
>>> Why not start easy and gradually step up the sophistication, rather than
>>> first "diving into the deep end of the pool" with Script and ProtoInstance.
>>>
>>> Suggest we focus first on easiest aspects:
>>> a. defining HTML/X3D syntax for how simple string events can get passed
>>> between X3D scene and HTML page.
>>> b. defining HTML/X3D syntax for how numeric/typed events can similarly
>>> get passed.
>>> c. Look at X3DOM and X_ITE respectively and see how they do it currently.
>>> d. Get through basic event-passing first before tackling variations for
>>> author-defined Script and Proto fields (the extensible X in X3D).
>>>
>>> Wondering what our simplest possible [HTML page + X3D scene] example
>>> might be to show simple string event passing?
>>>
>>> v/r Don
>>>
>>>
>>> On 3/2/2019 1:57 PM, John Carlson wrote:
>>> > Yeah, I was relaxing most of the day yesterday.  I may have posted
>>> incorrect information.    But I still believe x3dom fields are not handled
>>> at all for scripts, based on prior research, and up-to-date investigation
>>> in the chrome browser (fields and related attributes are black for
>>> scripts).   .  They are handled for ComposedShader, and we might use that
>>> as an example for handling Script fields.
>>> >
>>> > Good luck, it’s up to someone else besides me.  It should be fairly
>>> simple to activate script fields I hope.  I am not sure you want them in
>>> HTML scripts anyway.
>>> >
>>> > John
>>> >
>>> > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
>>> Windows 10
>>> >
>>> > *From: *Brutzman, Donald (Don) (CIV) <mailto:brutzman at nps.edu>
>>> > *Sent: *Friday, March 1, 2019 6:11 PM
>>> > *To: *John Carlson <mailto:yottzumm at gmail.com>
>>> > *Cc: *X3D Graphics Working Group <mailto:x3d at web3d.org>; X3D Graphics
>>> public mailing list <mailto:x3d-public at web3d.org>
>>> > *Subject: *Re: [x3d] X3D meeting minutes 22 FEB 2019: X3D v4
>>> Development statuscategories
>>> >
>>> > Thanks for these observations John.
>>> >
>>> > I think this points us at the importance of syntax for sending events
>>> to destinations, either (X3D -> HTML) or (HTML -> X3D).
>>> >
>>> > There are several links in today's minutes of relevance: event
>>> descriptions and diagrams for both X3D and HTML.
>>> >
>>> > The X3Dv4 spec defines functionality - this will tell authors how to
>>> construct what they need, and tell implementers what syntax/semantics to
>>> support.  In other words, interoperable content.  It does not mandate how
>>> an implementation gets coded.
>>> >
>>> > Building examples and comparing X3DOM and X_ITE together should get us
>>> on path to convergence.
>>> >
>>> > It would be good to get Roy Walmsley's original
>>> HTML+SVG+X3D+Javascript demo of "bouncing ball" back on center stage and
>>> refreshed.  Anyone know where it is?  Valuable role here for someone...
>>> >
>>> > On 3/1/2019 2:19 PM, John Carlson wrote:
>>> >
>>> >  > In other words, to prevent script source code from appearing on the
>>> rendered page, I had to remove the text or CDATA node. I am fairly sure I
>>> removed the field nodes as well for X3DOM in X3DJSONLD, favoring my own
>>> implementation.
>>> >
>>> >  > I believe that text nodes are incompatible with execution, but it
>>> might be worth seeing how something like jsfiddle does it, if they keep a
>>> shadow script or what.
>>> >
>>> >  > I believe you can keep the fields in DOM (I didn’t) if you have an
>>> X3DOM implementation of them.
>>> >
>>> >  > On Fri, Mar 1, 2019 at 4:03 PM John Carlson <yottzumm at gmail.com
>>> <mailto:yottzumm at gmail.com>> wrote:
>>> >  >     In other words, scripts (really script fields) do not appear in
>>> DOM and do not receive or generate DOM events.
>>> >
>>> >  >     John
>>> >
>>> >  >     On Fri, Mar 1, 2019 at 3:46 PM John Carlson <yottzumm at gmail.com
>>> <mailto:yottzumm at gmail.com>> wrote:
>>> >
>>> >  >         As far as I know there is no Script “class” or source file
>>> in X3DOM, thus no place to hang fields, thus nowhere to hook up routes.  I
>>> did write one at one time, it didn’t seem that difficult, but I’m not
>>> presently on board to rewrite it.   I suggest looking at other
>>> implementations of fields.
>>> >
>>> > [...]
>>> all the best, Don
>>> --
>>> Don Brutzman  Naval Postgraduate School, Code USW/Br
>>> brutzman at nps.edu
>>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
>>>  +1.831.656.2149
>>> X3D graphics, virtual worlds, navy robotics
>>> http://faculty.nps.edu/brutzman
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190304/a1b88e0b/attachment.html>