[x3d-public] question on X3D Object Model 3.3. declaring fields.

[Don Brutzman]

On 3/9/2017 3:54 PM, john at carlsonsolutiondesign.com wrote:
> Here’s and excerpt from the ObjectModel for fields on statements and concrete nodes.  I am wondering about the differences between the statements and the concrete nodes (highlighted in red) and why the concrete nodes do not have field elements with name=”field”.  I generally ignore StatementContentMoel and FieldDeclaration and go straight for the field element, so it would be nice to have it in the concrete nodes if possible.  Thanks.

I'm also ignoring ContentModel, StatementContentModel and FieldDeclaration.  Just using the field definitions for type="MFNode" which are sufficient and complete.

> This will also help with missing map to method objects in the serializers that I currently provide.  More on this in a previous and soon to be generated message (possibly missing items from X3D Object Model).
>
> If this correct as stands, I will need to figure out how to generate the map to method objects from this object model syntax.

I started with methods that implement the Java SAI abstract node interfaces

	http://www.web3d.org/documents/specifications/19777-2/V3.0/Part2/abstracts.html

and then added a growing variety of utility methods for programmer use, always looking for strict typing throughout.

The Java concrete classes are woefully incomplete but do provide a few examples.  Close inspection reveals that they are incorrectly/confusingly defined as interfaces, not concrete classes.  A spec update will need to be generated at some point.  Further design decisions are likely appropriate then regarding minimum essential concrete-class method definitions.

	Specification Changes under Consideration
	http://www.web3d.org/specifications/java/X3dJavaSceneAuthoringInterface.html#SpecificationChanges

* X3dJavaSpecificationChangesAndIssues.txt lists noted problems with the governing specification X3D Java SAI Language Bindings (ISO/IEC 19777-2).
* Specification prose is needed to define necessary support for DEF, USE and class attributes.
* Consider appropriate specification issues for abstract SAI and corresponding encoding specifications.
* Not needed: adding Annex D Java SAI Concrete Classes for standalone scene programming, since other approaches can be accomplished compatibly.
* Mantis issue tracker keeps track of details, alternatives and resolution for each specification issue.
* Web3D Consortium github (member-only access) is used to maintain editors-draft Web3D specifications in version control.

and
	http://www.web3d.org/specifications/java/X3dJavaSpecificationChangesAndIssues.txt

Anyway, for comparison to a Javascript SAI, you can use the X3DJSAIL javadoc for org.web3d.x3d.sai abstract interfaces to see how this plays out when extrapolating the interfaces package, and X3DJSAIL javadoc for org.web3d.x3d.jsail concrete classes to see the added classes.  Both at

	http://www.web3d.org/specifications/java/javadoc/overview-summary.html

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