[x3d-public] Problem in x3dviewscene: ROUTE placement

[vmarchetti at kshell.com]

> On Jun 11, 2023, at 5:09 PM, Brutzman, Donald (Don) (CIV) <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/Part01/fieldTypes.html <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/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/WrapperTagsConsideredHarmful.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/20230611/3dcab2c1/attachment-0001.html>