[x3d-public] VRML grammar generator. Was: Re: [...] HAnim2 X3D4BoxMan update: does ClassicVRML Grammar allows ROUTE in children?
John Carlson
yottzumm at gmail.com
Thu Jan 5 21:33:24 PST 2023
On Thu, Jan 5, 2023 at 8:54 PM Joseph D Williams <joedwil at earthlink.net>
wrote:
>
> - While I tried to find an issue with the VRML grammar, and i had
> several misperceptions, and on review, i didn’t find any problems that just
> “popped out.”
>
>
>
> John, Good, that is Good, that is Very Good.
>
I hope so! My lack of knowledge surrounding. VRML is great. I have not
worked a great deal with VRML, so i am using my meager XML and JSON skills,
hoping at some point to start a VRML project.
>
>
> - Your thoughts? I know everyone (besides me) is busy.
>
>
>
> I just need a simple thing to change V1 names to v2 names, get some
> dimensions and complete the Part 1 Annex A LOA4.
>
Joe,
I’m concerned that if I accomplish such tools/scenes that they won’t get to
you. I need to revamp or create a repository. I’m not sure i can
duplicate the “LOA4” that was previously sent, but i can try looking
through my emails. It was the one with the partially attached hands,
hoping you could provide any joints or segments necessary. I will search
for To:joe.
Brb, searching through email.
I’m not really wanting to enlist my wife, and I’m already in the doghouse
for previous emails. I do not have a standard body to get dimensions
from, I’m 6’8”. But perhaps that’s 2 meters, 1 meter above root? Am I
“standard”? Lol
Maybe someday, i can look at some VRML and claim, ”They took my hands!”
> Joe
>
>
>
>
>
> *From: *John Carlson <yottzumm at gmail.com>
> *Sent: *Thursday, January 5, 2023 3:45 PM
> *To: *Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> *Cc: *Joseph D Williams <joedwil at earthlink.net>; Michalis Kamburelis
> <michalis.kambi at gmail.com>; Patrick Dähne <pdaehne at gmail.com>; X3D Public
> Mailing List (x3d-public at web3d.org) <x3d-public at web3d.org>
> *Subject: *VRML grammar generator. Was: Re: [x3d-public] [...] HAnim2
> X3D4BoxMan update: does ClassicVRML Grammar allows ROUTE in children?
>
>
>
> While I tried to find an issue with the VRML grammar, and i had several
> misperceptions, and on review, i didn’t find any problems that just “popped
> out.” Perhaps my dry eyes have worsened.
>
>
>
> Perhaps we should provide generation of VRML grammar from X3DUOM, if not
> done already? We can have thousands of checks of examples against VRML
> grammar, as you have said. I have not kept track of VRML “stuff.”
>
>
>
> Your thoughts? I know everyone (besides me) is busy.
>
>
>
> I can even try to accomplish myself with existing grammar and X3DUOM. I
> can try with writing Xslt first, and if that’s too burdensome, possibly
> start from the JSON schema generator and branch out.
>
>
>
> Trying to make this as easy for someone to do as possible, can we make the
> right implementation choice? What limitations? Declarative
> implementations seem important.
>
>
>
> I agree that supporting one-offs in X3D Validator is useful and we
> probably don’t want to support batch web-based validation at this time.
>
>
>
> I have also researched “schema from example” and “grammar from example.”
> It might be worth applying new AI research to this problem with the right
> prompt.
>
>
>
> Maybe i should apply AI to the JSON schema. Hmm!
>
>
>
> John
>
>
>
> On Thu, Jan 5, 2023 at 11:01 AM Brutzman, Donald (Don) (CIV) <
> brutzman at nps.edu> wrote:
>
> Patrick, thanks for these important insights.
>
>
>
> Am looking closely and tracing the grammar. As you know, such grammars
> are very important because they formally and unambiguously describe what is
> allowed. Also pretty tricky to follow!
>
>
>
> - Extensible 3D (X3D) encodings, Part 2: Classic VRML encoding Annex A
> (normative), Grammar
> -
> https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html
>
>
>
> Am finding following excerpts of interest. Hopefully addition of
> color-coding helps:
>
>
>
> 1. *node *::=
>
> nodeTypeId { *nodeBody* } |
>
> Script { scriptBody } |
>
> ComposedShader {composedShaderBody} |
>
> PackagedShader {packagedShaderBody} |
>
> ShaderProgram {shaderProgramBody} ;
>
> 1. *nodeBody *::=
>
> *nodeBodyElement* |
>
> *nodeBodyElement* *nodeBody* |
>
> empty ;
>
>
>
> 1. mfnodeValue ::=
>
> *nodeStatement *|
>
> [ ] |
>
> [ nodeStatements ] ;
>
>
>
> 1. nodeStatements ::=
>
> *nodeStatement* |
>
> *nodeStatement* nodeStatements ;
>
>
>
> 1. *nodeStatement*::=
>
> *node* |
>
> DEF nodeNameId *node* |
>
> USE nodeNameId ;
>
>
>
> 1. *nodeBodyElement *::=
>
> initializeOnlyId fieldValue |
>
> inputOutputId fieldValue |
>
> initializeOnlyId IS initializeOnlyId |
>
> inputOnlyId IS inputOnlyId |
>
> outputOnlyId IS outputOnlyId |
>
> inputOutputId IS inputOutputId |
>
> routeStatement |
>
> protoStatement ;
>
>
>
> 1. routeStatement ::=
>
> *ROUTE* nodeNameId . outputOnlyId TO nodeNameId . inputOnlyId ;
>
>
>
> 1. *statement* ::=
>
> *nodeStatement* |
>
> importStatement |
>
> exportStatement |
>
> protoStatement |
>
> routeStatement ;
>
>
>
> 1. sfnodeValue ::=
>
> *nodeStatement *|
>
> NULL ;
>
>
>
>
>
> So it looks like there are several chains of interest as follows:
>
>
>
> 1. mfnodeValue > nodeStatements > *nodeStatement* > *node *>
> nodeTypeId {* nodeBody* } > *nodeBodyElement* > routeStatement >
> *ROUTE*
>
>
>
> 1. sfnodeValue > *nodeStatement > *(etc. as shown immediately above in
> chain 1)
>
>
>
> 1. *statement* > routeStatement > *ROUTE*
>
>
>
> From these three chains in ClassicVRML grammar, it appears logical to
> conclude that *ROUTE* is allowed to appear wherever an MFNode, SFNode or
> statement is allowed to appear.
>
>
>
> That would be a consistent match with the parent-child relationships
> defined in X3D XML Schema and DTD.
>
>
>
> Hopefully I have the chain of logic correct here. All scrutiny and review
> is welcome, we definitely need to get this right.
>
>
>
> If there is any unintended omission in the Backus-Naur logic here, then
> great! We can agree now on corrections, and fix any issues in this year’s
> expected update of the ClassicVRML encoding from X3D3 to X3D4. Correction
> of converters can also proceed immediately upon achieving consensus.
>
>
>
> - Wikipedia: Backus-Naur form
> - https://en.wikipedia.org/wiki/Backus-Naur_form
>
>
>
> Again thanks for careful strictness, careful checking of model content is
> one of our greatest strengths.
>
>
>
> Have fun with ClassicVRML X3D! 8)
>
>
>
> 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
>
>
>
> -----Original Message-----
> From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of Patrick Dähne
> Sent: Thursday, January 5, 2023 3:05 AM
> To: Joseph D Williams <joedwil at earthlink.net>
> Cc: X3D Public Mailing List (x3d-public at web3d.org) <x3d-public at web3d.org>
> Subject: Re: [x3d-public] [...] HAnim2 X3D4 BoxMan update
>
>
>
>
>
> > Am 05.01.2023 um 03:33 schrieb Joseph D Williams <joedwil at earthlink.net
> >:
>
> >
>
> > • Classic VRML does not allow to declare ROUTEs inside
> MFNode fields. Move them outside.
>
> >
>
> > There may be other x3d Statements and some rules, but I don’t see any
> spec language for what you describe regarding ROUTE.
>
>
>
> The (only) relevant part of the „Classic VRML encoding“ spec is „Annex A:
> Grammar“:
>
>
>
> https://www.web3d.org/documents/specifications/19776-2/V3.3/index.html
>
>
>
> The grammar is written in Backus-Naur form. It is the „Scheme“ of classic
> encoding. Have a look at the rule „mfnodeValue“. You won’t find the symbol
> „routeStatement“ on the right hand side of that rule.
>
>
>
> ROUTEs are only allowed:
>
>
>
> 1. At the top level of the scene
>
> 2. Inside the node body (between fields)
>
>
>
> In my opinion it does not make much sense to forbid ROUTEs inside MFNode
> fields, and I am actually surprised that someone implemented it such
> strictly.
>
>
>
> Bye,
>
>
>
> Patrick
>
>
>
>
>
> _______________________________________________
>
> x3d-public mailing list
>
> x3d-public at web3d.org
>
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230105/bcbebe41/attachment-0001.html>
More information about the x3d-public
mailing list