[x3d-public] [x3d] Spec Comment by brutzman on 19776-2: ClassicVRML Encoding - V3.3 [Mantis 1167] grammar syntax diagrams
Don Brutzman
brutzman at nps.edu
Fri Jul 28 00:13:29 PDT 2017
Roy: am thinking that formal tool support would be great, but likely remains impractical.
But - we can likely create a relationship diagram of some sort.
https://en.wikipedia.org/wiki/Formal_grammar
aha, how about a "railroad-track" diagram similar to JSON? Wonderfully clear and unambiguous, we could label nodes & arcs to match constructions in the VRML grammar.
https://en.wikipedia.org/wiki/Syntax_diagram
http://www.json.org
Anyone know of a good tool for drawing that? Some links are provided on that Wikipedia page.
aha #2, Visio (which we already use for other spec-related diagrams) appears to have such support via a contribution by Paul Herber in UK:
https://gallery.technet.microsoft.com/office/Syntax-diagram-shapes-for-965c6d10
http://www.paulherber.co.uk/articles/visio-articles/syntax-diagrams
Such a diagram (or diagrams) would be an excellent review tool to verify VRML grammar completeness/clarity and likely a worthy addition to the specification as well.
On 7/26/2017 11:55 AM, Roy Walmsley wrote:
> 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.html#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.html
>
> -----------------
>
> 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
>
> (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
>
> _______________________________________________
>
> x3d mailing list
>
> x3d at web3d.org <mailto:x3d at web3d.org>
>
> http://web3d.org/mailman/listinfo/x3d_web3d.org
>
>
>
> _______________________________________________
> x3d mailing list
> x3d at web3d.org
> http://web3d.org/mailman/listinfo/x3d_web3d.org
>
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
More information about the x3d-public
mailing list