[x3d-public] Problem in x3dviewscene: ROUTE placement

Sun Jun 11 22:36:28 PDT 2023

1.	Sorry to be unclear, that was not the relevant reference, rather the
prior email in the thread.

My mail of 9 June 16:30:04 PDT 2023 holds the relevant reference.  Excerpt
follows, quoting a quote, and have provided yellow highlights to key
phrasing this time.

*	[x3d-public] Problem in x3dviewscene: ROUTE placement
*
http://web3d.org/pipermail/x3d-public_web3d.org/2023-June/018836.html

The intent for ROUTE is that it might appear within other nodes.  The

phrasing in X3D4 Architecture is quite explicit about this:

* X3D 4.0 Part 1: Architecture and base components, clause 4 Concepts,
4.4.8.2 Routes

*
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Pa
rt01/concepts.html#Routes

*       Routes allows an author to declaratively connect the output events

of a node to input events of other nodes, providing a way to implement

complex behaviors without imperative programming. When a routed output event

is fired, the corresponding destination input event receives notification

and can process a response to that change. This processing can change the

state of the node, generate additional events, or change the structure of

the scene graph. Routes may be created declaratively in an X3D file or

programmatically via an SAI call.

*       Routes are not nodes. The ROUTE statement is a construct for

establishing event paths between specified fields of nodes. ROUTE statements

may either appear at the top level of an X3D file or inside a node wherever

fields may appear. A ROUTE statement shall only appear after the definition

of the source and destination nodes. Placing a ROUTE statement within a node

does not associate it with that node in any way. A ROUTE statement does

follow the name scoping rules as described in 4.4.7 Run-time name scope.

2.	I next took the offered example scene

*
https://www.web3d.org/x3d/content/examples/Vrml2Sourcebook/Chapter08Animatin
gPositionOrientationScale/Figure08_3PositionInterpolator.x3d

and moved entire scene graph within Scene inside a Group, i.e.

*	<Scene><Group><!-everything including ROUTE statements
--></Group></Scene>
*	Thus nothing remains in top-level MFNode list of the scene, except
for single parent Group

Then tested the modified example.

*	All validation tests passed.
*	Xj3D worked.
*	X3DOM worked.
*	After 10 minutes of reporting to Microsoft that view3dscene was
legitimate, and coercing Windows 10 to accept it, view3dscene.exe worked on
this modified example too.
*	Searching for "<ROUTE" found 4989 matches in first 500 scenes
searched (out of 4060 total archived scenes) so no doubt there are more.

3.	To my prior list of benefits for flexible placement of ROUTE
statements, here is another:

*	Simplifies author and tool addition of code-block patterns and
templates within a scene (this a feature used numerous times as an optional
authoring assist for event tracing by X3D-Edit, likely to be added as
utility features in X3DJSAIL and X3DPSAIL someday as well.)

Specifically, from X3D-Edit documentation,

*	Trace capabilities are available for ROUTE, sensors, interpolators
and other nodes that produce or consume events. Trace output results are
logged on the browser console to show the timing and values passed events.
When the Trace checkbox is selected by the author, a Script node is inserted
immediately after the node to accomplish this task. This is a useful
debugging technique.
*
https://savage.nps.edu/X3D-Edit/images/TraceFeatureReportsRoutedEventValuesO
nBrowserConsoleViaScriptOutput.png
*
https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter07-EventAnimationIn
terpolation/Chapter07-EventAnimationInterpolation-EventTracing.pdf

4.	"Consistency across all file encodings and language bindings is
possible." This is our basic design principle for separation of
functionality in X3D architecture from implementation details in all related
specifications.

We have immense interoperability already.  As promised many times, we will
smooth out any mismatches in future X3D 4.0 file encodings and language
bindings.  Test cases do help too.  So stand by for action.

Hopefully the highlighted specification requirement, the ease of creating
flexible test cases, and the value of this existing specification capability
is presented more clearly now.

Careful consideration, implementation efforts, and consensus-based progress
are always appreciated.

Having fun with X3D. I hope that others are too.

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 https://faculty.nps.edu/brutzman

From: vmarchetti at kshell.com <vmarchetti at kshell.com> 
Sent: Sunday, June 11, 2023 4:42 PM
To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; X3D-Public
<x3d-public at web3d.org>
Cc: Michalis Kamburelis <michalis.kambi at gmail.com>
Subject: Re: [x3d-public] Problem in x3dviewscene: ROUTE placement

On Jun 11, 2023, at 5:09 PM, Brutzman, Donald (Don) (CIV) <brutzman at nps.edu
<mailto:brutzman at nps.edu> > wrote:

Not trying to invent anything here, rather point out what is specified (and
also common practice).  I already gave the relevant links in the X3D 4.0
Architecture governing what is required.  

I do not see this requirement given or even implied in the link you
specified:

*
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Pa
rt01/fieldTypes.html

is a comprehensive listing of the X3D Field types, with details on SFNode
and MFNode therein, and on this page I don't see any mention of the ROUTE
statement nor does a text search on that page discover even the terms
"route" or "statement" in isolation.

...

Consistency across all file encodings and language bindings is possible.

I don't this this statement is true, or to the extent that it is true, then
long - ago X3D design decisions did not treat it as of primary importance.
As Michalis pointed out, in the ClassicVRML encoding the zero or more items
in a single MFNode value are syntactically enclosed in square brackets.
Moreover, in the ClassicVRML encoding all the field values are explicitly
identified with the name of the field. However, in the X3D encoding the XML
child elements are in most cases identified as belonging to an X3D field
through the node type-inheritance classification; and in the few cases where
that is not possible an explicit "containerField" XML attribute is used. To
make the X3D encoding consistent with ClassicVRML would entail the use of
wrapper XML elements around the element encoding of one node-element for an
SFNode value,  or the several nodes of MFNode. However, the design decision
was made long ago not to use wrapper elements in the XML encoding ( see
https://www.web3d.org/x3d/content/examples/Basic/development/WrapperTagsCons
ideredHarmful.html )

My point is that the consistency among encodings is a useful criteria but
should not automatically take precedence over other considerations. One such
consideration is maintainging stability of our formal ClassicVRML grammar.

And I think there is little additional benefit in changing the the
ClassicVRML to allow ROUTE inside MFNode encodings. Doing so does allow a
ROUTE to be placed adjacent to a node whose fields it modifies and you (Don)
have pointed out the readability benefits that offers -- but Michalis points
out that the ClassicVRML already allows that ROUTE statement to be placed
inside the body of a node it modifies, even closer!

Vince Marchetti

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230612/66f267f5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5464 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230612/66f267f5/attachment-0001.p7s>