<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">John,</div>
<div class="moz-cite-prefix"><br>
</div>
<blockquote type="cite"
cite="mid:CAGC3UE=_dk93=i=wQUnMKoLiTgh61ZkU5FPt+FCQM6=nQTL46g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div>
<div dir="auto">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).</div>
</div>
</blockquote>
<p><br>
DOM does not work on routes, it works on events. Routes are a
defined connection between a source and a destination node. An
event is something that zero or more destination nodes can listen
for. Code can create listeners without the assistance of the
source. A route requires the assistance of the source. <br>
</p>
<p>An event-based system can easily underlay a route-based system.
The method that creates the route creates a listener and performs
filtering on the incoming event to ensure that it matches the
route characteristics (correct type, correct node, correct field,
etc.), then consumes the event so it does not get propagated.</p>
<p>Underlying an event-system with a route-based one takes a lot
more work. Route data needs to be sent to something that creates
an event. The target needs to be wrapped with something that
listens for that event. Each route creates a dispatcher and a
listener. Since routes are from destination to target, then it is
probably better that the event created by each route be unique.
That way individual routes can be created or destroyed as needed.</p>
<p>Since a route-based system can be implemented on top of an
event-based system AND the API for HTML documents is DOM with an
event-based system, I do not see how or why this would be a W3C
issue. It certainly is not an ECMA issue because ECMA is concerned
with the language design, not the DOM and HTML events.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAGC3UE=_dk93=i=wQUnMKoLiTgh61ZkU5FPt+FCQM6=nQTL46g@mail.gmail.com">
<div dir="auto"><br>
</div>
<div dir="auto">It would seem like we are trying to confound a
domain specific issue with a generic web issue.</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
</blockquote>
<p><br>
</p>
<p>CSS is like a container. You can put things in there and
manipulate them, but the manipulation is done with JavaScript. CSS
provides the styles that are applied to the document elements.
When those elements change state different styles may be applied.
Since it takes a JavaScript action to change a CSS attribute or
selector, the "ROUTE" would just be the next statement that
changes a different attribute/selector.</p>
<p><br>
</p>
<p>Leonard Daly<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAGC3UE=_dk93=i=wQUnMKoLiTgh61ZkU5FPt+FCQM6=nQTL46g@mail.gmail.com">
<div dir="auto"><br>
</div>
<div dir="auto">John</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Mar 4, 2019 at 1:27
AM John Carlson <<a href="mailto:yottzumm@gmail.com"
moz-do-not-send="true">yottzumm@gmail.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div dir="auto">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?</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Is ROUTEing to and from HTML Scripts a
requirement?</div>
<div dir="auto"><br>
</div>
<div dir="auto">Is ROUTEing to and from X3D Scripts a
requirement?</div>
<div dir="auto"><br>
</div>
<div dir="auto">Is ROUTEing from HTML Scripts to X3D Scripts
a requirement?</div>
<div dir="auto"><br>
</div>
<div dir="auto">Is ROUTEing from X3D Scripts to HTML Scripts
a requirement?</div>
<div dir="auto"><br>
</div>
<div dir="auto">Is ROUTEing a requirement?</div>
<div dir="auto"><br>
</div>
<div dir="auto">Is event handling a requirement? In
script? In XML?</div>
<div dir="auto"><br>
</div>
<div dir="auto">Once we have agreed on the requirements, we
can proceed with the design (double loop architecture).</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Mar 4, 2019 at
12:51 AM John Carlson <<a
href="mailto:yottzumm@gmail.com" target="_blank"
moz-do-not-send="true">yottzumm@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div dir="auto">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).</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">It starts to get really complex when
you use a node as a field. A field is not just a
signpost</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto">I am not focused on X3Dv4 and have
other tasks.</div>
<div dir="auto"><br>
</div>
<div dir="auto">I do not want to battle over email.
I am just trying the best I can to report the effort
I made.</div>
<div dir="auto"><br>
</div>
<div dir="auto">John</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, Mar 3,
2019 at 4:33 PM Brutzman, Donald (Don) (CIV)
<<a href="mailto:brutzman@nps.edu"
target="_blank" moz-do-not-send="true">brutzman@nps.edu</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">Thanks for your helpful
analysis John. Here are some reactions.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Remember that an "event" is simply a timestamp +
value, getting passed from source to
destination.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Suggest we focus first on easiest aspects:<br>
a. defining HTML/X3D syntax for how simple
string events can get passed between X3D scene
and HTML page.<br>
b. defining HTML/X3D syntax for how
numeric/typed events can similarly get passed.<br>
c. Look at X3DOM and X_ITE respectively and see
how they do it currently.<br>
d. Get through basic event-passing first before
tackling variations for author-defined Script
and Proto fields (the extensible X in X3D).<br>
<br>
Wondering what our simplest possible [HTML page
+ X3D scene] example might be to show simple
string event passing?<br>
<br>
v/r Don<br>
<br>
<br>
On 3/2/2019 1:57 PM, John Carlson wrote:<br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> John<br>
> <br>
> Sent from Mail <<a
href="https://go.microsoft.com/fwlink/?LinkId=550986"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://go.microsoft.com/fwlink/?LinkId=550986</a>>
for Windows 10<br>
> <br>
> *From: *Brutzman, Donald (Don) (CIV)
<mailto:<a href="mailto:brutzman@nps.edu"
target="_blank" moz-do-not-send="true">brutzman@nps.edu</a>><br>
> *Sent: *Friday, March 1, 2019 6:11 PM<br>
> *To: *John Carlson <mailto:<a
href="mailto:yottzumm@gmail.com"
target="_blank" moz-do-not-send="true">yottzumm@gmail.com</a>><br>
> *Cc: *X3D Graphics Working Group
<mailto:<a href="mailto:x3d@web3d.org"
target="_blank" moz-do-not-send="true">x3d@web3d.org</a>>;
X3D Graphics public mailing list <mailto:<a
href="mailto:x3d-public@web3d.org"
target="_blank" moz-do-not-send="true">x3d-public@web3d.org</a>><br>
> *Subject: *Re: [x3d] X3D meeting minutes 22
FEB 2019: X3D v4 Development statuscategories<br>
> <br>
> Thanks for these observations John.<br>
> <br>
> I think this points us at the importance of
syntax for sending events to destinations,
either (X3D -> HTML) or (HTML -> X3D).<br>
> <br>
> There are several links in today's minutes
of relevance: event descriptions and diagrams
for both X3D and HTML.<br>
> <br>
> 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.<br>
> <br>
> Building examples and comparing X3DOM and
X_ITE together should get us on path to
convergence.<br>
> <br>
> 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...<br>
> <br>
> On 3/1/2019 2:19 PM, John Carlson wrote:<br>
> <br>
> > 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.<br>
> <br>
> > 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.<br>
> <br>
> > I believe you can keep the fields in
DOM (I didn’t) if you have an X3DOM
implementation of them.<br>
> <br>
> > On Fri, Mar 1, 2019 at 4:03 PM John
Carlson <<a href="mailto:yottzumm@gmail.com"
target="_blank" moz-do-not-send="true">yottzumm@gmail.com</a>
<mailto:<a href="mailto:yottzumm@gmail.com"
target="_blank" moz-do-not-send="true">yottzumm@gmail.com</a>>>
wrote:<br>
> > In other words, scripts (really
script fields) do not appear in DOM and do not
receive or generate DOM events.<br>
> <br>
> > John<br>
> <br>
> > On Fri, Mar 1, 2019 at 3:46 PM
John Carlson <<a
href="mailto:yottzumm@gmail.com"
target="_blank" moz-do-not-send="true">yottzumm@gmail.com</a>
<mailto:<a href="mailto:yottzumm@gmail.com"
target="_blank" moz-do-not-send="true">yottzumm@gmail.com</a>>>
wrote:<br>
> <br>
> > 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.<br>
> <br>
> [...]<br>
all the best, Don<br>
-- <br>
Don Brutzman Naval Postgraduate School, Code
USW/Br <a href="mailto:brutzman@nps.edu"
target="_blank" moz-do-not-send="true">brutzman@nps.edu</a><br>
Watkins 270, MOVES Institute, Monterey CA
93943-5000 USA +1.831.656.2149<br>
X3D graphics, virtual worlds, navy robotics <a
href="http://faculty.nps.edu/brutzman"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://faculty.nps.edu/brutzman</a><br>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
x3d-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>
<a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
</pre>
</blockquote>
<p><br>
</p>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Past Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>