[x3d-public] VRML grammar, X3DJSONLD JSON report. Was: Re: [...] HAnim2 X3D4 BoxMan update: does ClassicVRML Grammar allows ROUTE in children?

Sun Jan 8 21:36:16 PST 2023

The VRML Grammar is simply part of the specification to formalize rules.
Since it has strict and formal (meaning precise and unambiguous) expressive
power, it is an important part of the VRML97 and X3D ClassicVRML
international specifications.

I do not know of any software tools (in X3D or elsewhere) that have ever
used such BNF grammars programmatically in the types of ways you are
describing.  They are strong contributions mostly to theory, much less
directly to practice.  Backus Naur Form grammars have helped inspire
numerous other diverse grammars, libraries and approaches.

Incidentally this is why the X3D XML Schema has always been so critically
important, it lets us formally test 3D models for compliance.  Adding lots
of further verification tools (mostly available using XML as basis) has
given us a rich suite of testing tools.  Familiar link covering immense
detail:

*	X3D Resources, Quality Assurance (QA)
*
https://www.web3d.org/x3d/content/examples/X3dResources.html#QualityAssuranc
e

Hope this is all clearer now John.  Perhaps a lot of detail but the same
story, over and over.

When errors occur, they can be detected and then corrected.  Our big
achievement: X3D models can run in many different file formats and
programming languages, equivalently and correctly.

Someday if JSON Schema ever gets standardized, we’ll be able to add that
too.  Thanks for keeping that possibility alive.

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

From: John Carlson <yottzumm at gmail.com> 
Sent: Thursday, January 5, 2023 9:01 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: Re: VRML grammar, X3DJSONLD JSON report. Was: Re: [x3d-public]
[...] HAnim2 X3D4 BoxMan update: does ClassicVRML Grammar allows ROUTE in
children?

ClassicVRML, batch parsing?

I guess the primary thing to do is validate vrml examples against a
hand-checked vrml grammar.  I think what you’re saying is, the standardized
3.3 grammar for ClassicVRML already works great in X3D-Edit.  Do i test with
the check button?  Do we do hand-checks with each vrml file—can we batch up
a set of files?  SHIFT-left mouse click?

I fully realize that many tools provide some degree of parsing of VRML.
What i am asking for is batch validation.

At this point, it seems like we’re trying to validate the X3D VRML grammar
found in the 3.3 standard, either with tools or otherwise (vrml examples and
human brains), and possibly upgrade to grammar for 4.0.

If it’s possible to translate ClassicVRML to .x3d and then validate, that
seems like a good path, if we add batching.

——————

ROUTEs and JSON

I do remember when we dealt with JSON, we had to bring out ROUTEs from inner
contexts, but I don’t remember the reason.

For X3DJSONLD, all JSON based ROUTEs come from X3dToJson.xslt.  If you need
to test JSON roundtrips of this stylesheet, let me know.

Note, I have DOM2JSONSerializer.js, but it gets into deep recursion calls
beyond my debugging capabilities at this point, so I can’t offer a solution
there.  I can’t recall if I handled ROUTEs properly or not.

I also think that X3dToJson.xslt may not working in some cases
“IllegalChild
 was getting generated on some JSON files, but these problems
are not currently reproduced (try using a *recent* Saxon-JS in a web
browser—the problem presented itself in a web browser is old versions of
Saxon-CE, not the Java versions).

I have gotten rid of the JSON files since I can’t regenerate them.

Any additional X3dToJson.xslt problems swept under the carpet for now.  I
may need to update the Saxon-JS on my website.  X3DJSONLD git push is
currently not working, i may need to delete some build files from my
repository.

——

On Thu, Jan 5, 2023 at 6:55 PM Brutzman, Donald (Don) (CIV)
<brutzman at nps.edu <mailto:brutzman at nps.edu> > wrote:

Simple summary of ROUTE conversions:

a.	We will allow ROUTEs as children, as always intended.  
b.	If the ClassicVRML Grammar indeed needs modification, we will define
that for Mantis and 2023 ClassicVRML revision.
c.	As soon as we reach consensus, we will ask converters to fix support
for ROUTEs.

Quality assurance (QA) efforts are all focused on XML and X3DUOM mappings to
different program languages. No need to autogenerate a ClassicVRML Grammar
that exists and has pretty-much worked for the past quarter century (since
1997).  If we figure out and confirm an improvement, then wow + bravo
everyone!!  If we determine that it is OK, we’ve learned more too.

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 <http://faculty.nps.edu/brutzman> 

From: John Carlson <yottzumm at gmail.com <mailto:yottzumm at gmail.com> > 
Sent: Thursday, January 5, 2023 3:46 PM
To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu <mailto:brutzman at nps.edu>
>
Cc: Joseph D Williams <joedwil at earthlink.net <mailto:joedwil at earthlink.net>
>; Michalis Kamburelis <michalis.kambi at gmail.com
<mailto:michalis.kambi at gmail.com> >; Patrick Dähne <pdaehne at gmail.com
<mailto:pdaehne at gmail.com> >; X3D Public Mailing List (x3d-public at web3d.org
<mailto:x3d-public at web3d.org> ) <x3d-public at web3d.org
<mailto:x3d-public at web3d.org> >
Subject: VRML grammar generator. Was: Re: [x3d-public] [...] HAnim2 X3D4
BoxMan 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 <mailto: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.h
tml

Am finding following excerpts of interest.  Hopefully addition of
color-coding helps:

a.	node ::=

  nodeTypeId { nodeBody } |

  Script { scriptBody } |

  ComposedShader {composedShaderBody} |

  PackagedShader {packagedShaderBody} |

  ShaderProgram {shaderProgramBody} ;

b.	nodeBody ::=

  nodeBodyElement |

  nodeBodyElement nodeBody |

  empty ;

c.	mfnodeValue ::=

   nodeStatement |

   [ ] |

   [ nodeStatements ] ;

d.	nodeStatements ::=

  nodeStatement |

  nodeStatement nodeStatements ;

e.	nodeStatement::=

  node |

  DEF nodeNameId node |

  USE nodeNameId ;

f.	nodeBodyElement ::=

  initializeOnlyId fieldValue |

  inputOutputId fieldValue |

  initializeOnlyId IS initializeOnlyId |

  inputOnlyId IS inputOnlyId |

  outputOnlyId IS outputOnlyId |

  inputOutputId IS inputOutputId |

  routeStatement |

  protoStatement ;

g.	routeStatement ::=

  ROUTE nodeNameId . outputOnlyId TO nodeNameId . inputOnlyId ;

h.	statement ::=

  nodeStatement |

  importStatement |

  exportStatement |

  protoStatement |

  routeStatement ;

i.	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

2.	sfnodeValue > nodeStatement > (etc. as shown immediately above in
chain 1)

3.	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
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipe
dia.org%2Fwiki%2FBackus-Naur_form&data=05%7C01%7Cbrutzman%40nps.edu%7C971217
be49b74d63517208daefa316f4%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C6380
85781004877078%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dmcygRdwYMkIJQcb2jgpsAR0
9PDGbf06ZAqgDOc4bdA%3D&reserved=0> 

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
<mailto: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 <http://faculty.nps.edu/brutzman> 

-----Original Message-----
From: x3d-public <x3d-public-bounces at web3d.org
<mailto: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 <mailto:joedwil at earthlink.net>
>
Cc: X3D Public Mailing List (x3d-public at web3d.org
<mailto:x3d-public at web3d.org> ) <x3d-public at web3d.org
<mailto:x3d-public at web3d.org> >
Subject: Re: [x3d-public] [...] HAnim2 X3D4 BoxMan update

> Am 05.01.2023 um 03:33 schrieb Joseph D Williams <
<mailto:joedwil at earthlink.net> 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>
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

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

 <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org <mailto: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/20230109/9e3c3699/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5353 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230109/9e3c3699/attachment-0001.p7s>