[x3d-public] [x3d] Classic VRML Keyword questions

[Don Brutzman]

[adding x3d-public list for possible additional insights]

On 7/26/2017 10:54 AM, Roy Walmsley wrote:
> Hi,
> 
> We were discussing the Classic VRML grammar today, albeit not reaching consensus. I have a question now:
> 
> Are either of the following lines valid Classic VRML encoded X3D syntax?
> 
> DEF RigidBody RigidBody { }
> 
> DEF COMPONENT RigidBody { }

Hmmm.  To properly answer this question, it looks like we have to go back to the X3D Abstract Specification.

==================================================================================================
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#DEFL_USESemantics
4.4.3 DEF/USE semantics

Node names are limited in scope to a single X3D file, prototype definition, or string submitted to either CreateX3DFromString, CreateX3DFromStream, or CreateX3DFromURL browser service or a construction for SFNodes within a script. The USE statement does not create a copy of the node. Instead, the same node is inserted into the scene graph a second time, resulting in the node having multiple parents (see 4.3.5 Transformation hierarchy, for restrictions on self-referential nodes).

Node names shall be unique in the context within which the associated DEF keyword occurs.

==================================================================================================
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#PrototypeSemantics
4.4.4 Prototype semantics
4.4.4.1 Introduction

The PROTO statement defines a new node type in terms of already defined (built-in or prototyped) node types. Once defined, prototyped node types may be instantiated in the scene graph exactly like the built-in node types.

Node type names shall be unique in each X3D file. The results are undefined if a prototype is given the same name as a built-in node type or a previously defined prototype in the same scope.

==================================================================================================

Using this terminology for a construct like

	DEF MyFavoriteShapes Group { }

means that "MyFavoriteShapes" would be a *node name*, and "Group" would be a *node type*.

Continuing in that manner:

> Consider the following texts from ISO/IEC 19776-2 V3.3.
> 
> 4.3.1 Classic VRML encoding (see http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/concepts.html#ClassicVRMLEncoding), last three paragraphs.

especially

"The following reserved keywords shall not be used for field, event, PROTO, EXTERNPROTO, or node names" [...]

which presumbably is consistent and states "node names" meaning DEF names here.

Sidebar... curiously, the list that follows has more reserved words (i.e. head, Scene, X3D) than

	Table A.2 — X3D Classic VRML encoding lexical elements
	http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html#t-LexicalElements

I think the two lists are different because head Scene and X3D are not explicitly used in the ClassicVRML encoding/grammar. Related: I place comment symbol # before them when translating for clarity, e.g.

# [X3D] version=3.3
# [X3D] noNamespaceSchemaLocation=http://www.web3d.org/specifications/x3d-3.3.xsd
# [head]
# [Scene] ========== ========== ==========

TODO: another possible editorial improvement would be to use identical alphabetization of these two lists, to facilitate such double checking.

> A.1.2 Overview (see http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html#Overview).

includes use of the term "node types" in this manner:

"_6 Encoding of nodes_ contains a description of the allowed fields for all pre-defined node types."

> My interpretation is that “RigidBody” is an acceptable DEF name, whereas “COMPONENT” is not.
> 
> Is my conclusion correct?

Looks like a correct interpretation to me too.

> If so, why are the existing reserved keywords so chosen? And why are node types not included in that list?

Historically, we were being cautious to list the prohibitions we did.  For some of those statements it may well be possible to create ambiguous constructs with overloaded DEF names (e.g. "ROUTE ROUTE.outputField to PROTO.inputField" or somesuch).

Should we similarly prohibit use of "node type" names as DEF names?  Quite possibly, since "DEF Group Transform { }" and "ROUTE MyPI.value_changed TO Group.translation" don't seem very helpful.  But even if obfuscating, they do seem to be legal and unambiguous and correctly implementable.

  At this late stage (twenty years in) we shouldn't be adding new restrictions unless good justification is found.  Suggested precautions before we decide to add any such restrictions:
a. ensure we are really fixing a problem, rather than something cosmetic which is workable.
b. be wary of creating a new class of errors for translators and code generators that didn't exist before.
c. put any changes in the X3D Abstract Specification and implement them consistently across encodings.

First law of engineering likely applies here: "if it ain't broke, don't fix it."  YMMV, the issue is a worthy question.

One more TODO: have never seen any formal checking of the VRML grammar - that would be helpful, if someone knows how to accomplish it.

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