[x3d-public] Discussion of API to generate X3D documents, based on X3D Object Model and X3DSAIL

Don Brutzman brutzman at nps.edu
Mon Feb 26 08:04:00 PST 2018

Hi John.  Lots of interesting ideas!


1. At face value, what you are describing are methods or programs.  X3DJSAIL is designed to make it easy to create programs that manipulation X3D.  So an API design approach may not be needed.

2. X3D Validator and X3DJSAIL include many tests already, most quite robust and together pretty thorough.  In general these tools evolve as follows:
a. X3D Mantis issue resolutions, and X3D v4 additions: new blocks in X3D XML DTD, XML Schema, Unified Object Model and X3D JSON Schema.
b. Special case detection: new rules in X3D Schematron.
c. Correction of ambiguous errors: new rules in X3D Tidy.
d. Synopsis, clarification and hints/warnings regarding specification guidance: X3D Tooltips
e. Demonstrating features and illuminating gaps: addition of example scenes to X3D Examples corpus of unit tests.

	X3D Resources: Quality Assurance (QA)

	X3D Tooltips

	X3D Mantis Issue Tracker

	X3D Resources: X3D Examples

3. Given this existing thoroughness, we probably should look at test frameworks and Test-Driven Development to see how they might complement existing tests.

4. Suggested paths forward:
a. Writing test programs as your suggest, exercising X3DJSAIL capabilities and adding utility methods when identified.
b. Ongoing spiral improvement of assets 2a..2e above.
c. Integrate improved testing techniques into the autogenerated validate() self-test methods found in .java versions of X3D Examples corpus.
d. Focus on advanced v3.3 and new v4.0 X3D components with few test example scenes.
e. Continued "lather-rinse-repeat" since the X3D value proposition keeps getting better every single day.

This might be a good meeting topic if you think further discussion is warranted.  Thanks for "pushing the envelope" farther!

p.s. "You Get What You Measure" is an important truism.

	Performance Measurement Column: "You Are What You Measure"
	Dan Ariely, June 2010, Harvard Business Review (HBR)

v/r Don

On 2/25/2018 3:12 AM, John Carlson wrote:
> So I’m starting to work an API to generate X3D documents. I think I want something based on X3DObject in X3DJSAIL, probably as an extension of X3DJSAIL, so your help would be appreciated.  I am thinking something like
> X3DObject obj = X3DObject.generateSemiRandomScenegraph(seed);
> X3DObject obj2 = X3DObject.generateCompleteScenegraph(seed);
> Then similar to how toStringX3D() goes down through hierarchy, I would have a generate…Scenegraph(); at each node.  I would need some probabilistic or occurrence-based configuration to generate the number of children and which attributes get set and which nodes get generated.   My question becomes, how to I generate things which are dependent on each other?   Like DEF/USE, Routes, and IndexedFaceSet attributes, for example.  I think I can do this through something similar to validation, but I haven’t spent much time thinking about it--generateValid()???  Have you spent anytime thinking about it?
> What do you think about extending X3DJSAIL, and how do I go about getting my changes integrated?   Should I start a similar independent stylesheet which just does generation?  Should I output a different language than Java?
> Your thoughts are welcome!
> The only reason I am doing this Is to test the schema.  If you have a better approach, let me know!
> Also, if anyone has done any occurrence-based analysis of X3D documents, I would be eager to hear about it.
> John

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