[x3d-public] [x3d] Spec Comment by brutzman on 19776-2: ClassicVRML Encoding - V3.3 [Mantis 1167]

Wed Jul 26 11:55:28 PDT 2017

Hi,

During today's X3D WG meeting we had some discussion on this topic.

One viewpoint was expressed that the grammar as currently written is
satisfactory, and more clear than  the proposal  below.

I agree that the existing grammar is not incorrect. But, is the use of
nodeTypeId for both user defined prototypes and built-in nodes desirable.

The X3D suite of standards are written with major classes of users in mind.
One is the scene author, the other is the player implementer.

For the first user class, the scene author, the dual usage of nodeTypeId
does indeed represent what goes into the syntax. An author would use them in
the same way, and, other than providing the PROTO/EXTERNPROTO declaration,
not be concerned about the difference.

Contrast this with the second user class, the player implementer. Now, this
dual-usage is very different. When nodeTypeId represents a built-in node,
the player can instantiate from a class definition built into the software.
When representing a user-defined prototype, the instantiation needs to find
the declaration in the prior user code, and build the instantiation from
that. This requirement for a different approach is not clear in the grammar.

As previously noted in clause A.1.2 Overview, (see
http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.ht
ml#Overview), the first paragraph reads:

"It is not possible to parse X3D files using a context-free grammar.
Semantic knowledge of the names and types of fields (either built-in or
user-defined using PROTO or EXTERNPROTO) shall be used during parsing so
that the parser knows which field type is being parsed."

I agree with the first sentence. I disagree with the reason in the second
sentence. Semantic knowledge of built-in nodes and fields could be
incorporated into the grammar. It would make it very long. But it could be
done. The only reason that parsing is not possible using a context-free
grammar is the semantic knowledge of the names and types of fields from
user-defined prototypes (using either PROTO or EXTERNPROTO).

Let me illustrate this with a grammar excerpt.

In my proposed grammar alternative, nodeTypeId still has the following
production:

nodeTypeId ::= 

Id ; 

This production could be replaced as follows:

nodeTypeId ::= 

Anchor |

Appearance |

Arc2D |

..

VolumePickSensor |

WindPhysicsModel |

WorldInfo ;

Once the node type is known, so are the permitted fields and their types. So
the grammar could be extended to cover each node type individually. Note
that this approach has already been taken for four nodes (Script,
ComposedShader, PackagedShader, and ShaderProgram). In fact, applying this
approach to all built-in node types would make nodeTypeId redundant for
built-in nodes.

Thinking about this raised another question. Should the built-in node types
be reserved keywords?

For example, according to the current standard the following line is valid
Classic VRML syntax:

                DEF Anchor Anchor { }

Should it be?

All the best,

Roy

From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of Roy
Walmsley
Sent: 19 July 2017 19:11
To: 'X3D Graphics public mailing list' <x3d-public at web3d.org>
Cc: x3d at web3d.org
Subject: Re: [x3d-public] [x3d] Spec Comment by brutzman on 19776-2:
ClassicVRML Encoding - V3.3 [Mantis 1167]

Hi,

Having looked at the grammar relating to prototype instances I think it does
not actually need modification. That said, however, I think clarity could be
improved. I suggest the following.

The current productions for the non-terminals proto and externproto are as
follows:

proto ::= 

PROTO nodeTypeId [ interfaceDeclarations ] { protoBody } ; 

externproto ::= 

EXTERNPROTO nodeTypeId [ externInterfaceDeclarations ] URLList ;

The non-terminal nodeTypeId is the same non-terminal that is used in the
definition of the production for the non-terminal node:

node ::= 

nodeTypeId { nodeBody } | 

Script { scriptBody } |

ComposedShader {composedShaderBody} |
PackagedShader {packagedShaderBody} |
ShaderProgram {shaderProgramBody} ; 

I think this could be improved by introducing two additional non-terminals,
namely protoInstance and protoNodeTypeId. Taking the latter first, this
would align with nodeTypeId and have the following production:

protoNodeTypeId ::= 

Id ; 

The production for protoInstance, aligning with node, would be:

protoInstance ::= 

protoNodeTypeId { nodeBody } ; 

The productions for the non-terminals proto and externproto would then be
amended to

proto ::= 

PROTO protoNodeTypeId [ interfaceDeclarations ] { protoBody } ; 

externproto ::= 

EXTERNPROTO protoNodeTypeId [ externInterfaceDeclarations ] URLList ;

Finally, the production for the non-terminal nodeStatement would be expanded
to explicitly include protoInstance, as follows:

nodeStatement ::= 

node | 

protoInstance |

DEF nodeNameId node | 

DEF nodeNameId protoInstance |

USE nodeNameId ;

This has the following advantages:

1.	It allows text that states the non-terminal nodeTypeId can be the
type of any of the built-in nodes defined in the abstract standard 19775-1. 
2.	It allows text that states the non-terminal protoNodeTypeId is the
type of any user defined prototype
3.	It clearly separates the built-in nodes from prototypes within the
grammar.

All the best,

Roy

-----Original Message-----
From: x3d [mailto:x3d-bounces at web3d.org] On Behalf Of Spec Feedback
Sent: 19 July 2017 17:59
To: x3d at web3d.org <mailto:x3d at web3d.org> 
Subject: [x3d] Spec Comment by brutzman on 19776-2: ClassicVRML Encoding -
V3.3

-- Submitter indicates that this comment may be public: *Yes* --

Comment on 19776-2: ClassicVRML Encoding - V3.3 Annex A (normative) Grammar
<http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.h
tml>
http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.ht
ml

-----------------

Subject: need explicit definition of DEF and USE associated with prototype
instances in ClassicVRML grammar

ClassicVRML formal grammar does not include explicit definition of DEF and
USE associated with prototype instance statements.

The current grammar seems to lean on prose definitions in section A.2 to
augment rules in A.3.  More is needed: better prose, additional rule(s), or
both.

Email thread exploring this issue found at
<http://web3d.org/pipermail/x3d-public_web3d.org/2017-July/007155.html>
http://web3d.org/pipermail/x3d-public_web3d.org/2017-July/007155.html

(see second half)

-----------------

Submitted on Wednesday, 2017,  July 19 - 9:59am by brutzman (brutzman )

IP: 162.225.68.164

See:  <http://www.web3d.org/node/1694/submission/1396>
http://www.web3d.org/node/1694/submission/1396

_______________________________________________

x3d mailing list

 <mailto:x3d at web3d.org> x3d at web3d.org

 <http://web3d.org/mailman/listinfo/x3d_web3d.org>
http://web3d.org/mailman/listinfo/x3d_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170726/e6f30d49/attachment-0001.html>