[x3d-public] X3DJSAIL: X3D Java Scene Access Interface Library update

[Brutzman, Donald (Don) (CIV)]

X3D Java Scene Access Interface Library (X3DJSAIL) supports programmers with standards-based X3D Java interfaces and objects, all as open source.

	http://www.web3d.org/specifications/java/X3DJSAIL.html

/New/. The current useful update provides results from a few week's work:
a. Refactoring internal representations of MFNode arrays to allow ProtoInstance as well as all built-in node types.
b. Eliminated need for containerField setting by programmers when using Java set methods.
c. For X3dToJava.xslt, autocorrection of missing containerField information if possible using local ProtoDeclare.
d. ProtoInstanceObject utility constructor now takes prototypeName as first parameter and DEF value as second.
e.Improved handling of shader nodes, so further testing/debugging of example scenes is now appropriate.

/Notable/.  John Carlson's testing, insights and code contributions have been crucial for this progress.  We continue improvements on JSON, Java and Python implementations for X3D during Web3D teleconferences each Wednesday afternoon 1400-1530 pacific on the Web3D Consortium teleconference line.

Everything is tested against example source HelloWorldProgram.java with smoke test results recorded.  An additional 3900+ smoke tests can be found at

	http://www.web3d.org/x3d/content/examples/build.java.all.log.txt
using
	X3D Resources Examples: Scene Archives for X3D
	http://www.web3d.org/x3d/content/examples/X3dResources.html#Examples

More on containerField issues is found as follows:
==================================================
X3D Scene Authoring Hints: containerField
http://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#containerField

Each containerField value is the field name from the X3D Specification that indicates a contained node's relationship to its parent node.  The XML containerField is optional and typically can be omitted for scene terseness.

- *Usually ignorable*. Default containerField values for each node are correct in most cases, so the need to override default containerField values is relatively rare.
- *Terse match to other X3D encodings*. The containerField attribute is part of XML encoding for X3D scenes, and corresponds to the always-declared field labels in the ClassicVRML and VRML97 file encodings.
- *Examples*. Example values include containerField='geometry' for Box node, containerField='children' for Group node, containerField='proxy' for hidden proxy shape within a Collision node, etc.
- *USE node flexibility*. USE nodes are allowed to have a containerField value that is different than the corresponding DEF declaration of that node, since the containerField attribute describes each node's relationship with its parent.
- *ProtoInstance node flexibility*. ProtoInstance nodes are similarly allowed to have a containerField value that is different than default for their node type, again since the containerField attribute describes each node's relationship with its parent.
==================================================

Specification comment to follow:  as mentioned in last week's X3D Working Group teleconference and minutes, the absence of node type information in ExternProtoDeclare means that type errors from ProtoInstance nodes can only be found during deployment run time (in front of an end user) rather than in advance when validating a scene.  To my knowledge, this is the only case of lurking/lingering validation errors in X3D - everything else can be figured out by an authoring tool.  Further analysis is likely to produce a recommended improvement for X3Dv4.

	X3D Version 4
	http://www.web3d.org/x3d4

Feedback always welcome.  Have fun with X3DJSAIL!  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 http://faculty.nps.edu/brutzman