[x3d-public] containerField updates pushed for X3D 4.0 XML Schema, DTD and X3DUOM

Don Brutzman brutzman at nps.edu
Tue Jun 19 22:52:03 PDT 2018


On 6/12/2018 10:14 AM, Don Brutzman wrote:
> As many of you know, in the X3D XML encoding, each containerField value is the field name from the X3D Specification that indicates a contained node's relationship to its parent node.

Candidate solutions for all containerField variations are now posted in the X3D 4.0 XML Schema, DTD, X3D Unified Object Model (X3DUOM) and X3DJSAIL library.  Of note is that zero changes to any legitimate X3D content is expected, rather this provides yet another facet of strict validation and Quality Assurance (QA) for X3D.

Special thanks to Mike McCann and Nicholas Polys for discussions and design insights on these edge cases, here at Web3D 2018 Conference.

Next week I will work on regression testing against ~4000 scenes, coercing defined X3D version to 4.0.  Subject to others' feedback and testing, am planning to apply these changes to X3D versions 3.0 though 3.3.  Testing will tell the story.

Once that succeeds, we can then begin to work towards refactoring the names of non-ambiguous child SFNode/MFNode fields in X3D version 4.0.  As indicated in the following analysis, I think that about half of the containerField variations can be eliminated, to good effect.  Such refinement will likely provide modest but useful improvements for all file encodings and language bindings of X3D v4.0.  Small but useful changes to all X3D software will eventually be required to achieve X3D v4.0 support.

All scrutiny and feedback welcome, thanks for considering these possibilities.  Current assets and writeup follow, both for your convenience and also to have a record in our email archive.

Have object-oriented fun with X3D!

====================================================================================
X3D Specifications: Schema and DOCTYPE Validation
http://www.web3d.org/specifications/contents.html

X3D 4.0 XML Schema  documentation
http://www.web3d.org/specifications/X3dSchemaDocumentation3.3/x3d-4.0.html

X3D 4.0 XML DOCTYPE documentation
http://www.web3d.org/specifications/X3dDoctypeDocumentation4.0.html

X3D 4.0 X3DUOM source, documentation
http://www.web3d.org/specifications/X3DUOM.html
http://www.web3d.org/specifications/X3dUnifiedObjectModel-4.0.xml

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

X3D Scene Authoring Hints: containerField
http://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#containerField

*containerField*

Each containerField value is the field name from the X3D Specification that indicates a contained node's relationship to its parent node.

Addition of containerField values only occurs in the XML encoding of .x3d scenes. For example: <Transform><Shape containerField='children'/></Transform> indicates that the Shape node is one of the children of the Transform node.

The X3D XML Schema, X3D DTD and X3D Tooltips each define all default containerField values, which are optional and can be omitted for scene terseness.

*    Default containerField values for each node are correct in most cases, so the need to override default containerField values is relatively rare.
*    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.
*    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 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.

_Non-default containerField values_

Disambiguation of parent-child field relationships is sometimes necessary, since a few parent nodes have more than one child field that can accept the same node type. In those ambiguous cases, the child node must have a correct containerField value in order to precisely define parent-child field relationships.

Specifically, care must be taken with the following non-default child containerField values.
	Variations from containerField defaults
1. 	CADFace can contain a single Shape, LOD or Transform node with containerField='shape' (rather than default containerField='children').
2. 	CollidableShape can contain a single Shape node with containerField='shape' (rather than default containerField='children').
3. 	Collision can contain a single nonrendered proxy Shape (or X3DGroupingNode) node with containerField='proxy' (rather than default containerField='children'). TODO: Mantis 1149.
4. 	ComposedCubeMapTexture can contain up to six X3DTexture2DNode (e.g. ImageTexture) nodes, each with a unique containerField value: back, bottom, front, left, right, or top (rather than default containerField='texture').
5. 	GeoLOD can contain multiple X3DChildNode nodes with containerField='rootNode'. Curiously GeoLOD is not allowed to have child nodes with default containerField='children' defined in a scene, since that field is defined differently with accessType outputOnly and thus is only able to send MFNode events at run time.
6. 	HAnimJoint       has default containerField='children' when parent is another HAnimJoint, and has containerField value of joints or skeleton when parent node is HAnimHumanoid.
7. 	HAnimSegment has default containerField='children' when parent node is an HAnimJoint, and has containerField='segments' when parent node is HAnimHumanoid.
8. 	HAnimSite        has default containerField='children' when parent node is an HAnimSegment, and has containerField value of sites, skeleton or viewpoints when parent node is HAnimHumanoid.
9. 	LoadSensor is a parent node that can monitor the loading of one or multiple child nodes having containerField='watchlist'. Such child nodes implement object interface X3DUrlObject and include Anchor, AudioClip, DISEntityTypeMapping, GeoMetadata, ImageCubeMapTexture, ImageTexture, ImageTexture3D, Inline, MovieTexture, PackagedShader, Script, ShaderPart and ShaderProgram.
9. 	MetadataSet can contain multiple other child X3DMetadataNode nodes by setting their containerField='value' (rather than default containerField='metadata'). Similar to the other metadata nodes, MetadataSet can also contain a single X3DMetadataNode node describing itself (with default containerField='metadata').
10. 	Sound can contain a single MovieTexture node with containerField='source' (rather than default containerField='texture').
11. 	TextureBackground can contain up to six X3DTexture2DNode (e.g. ImageTexture) nodes, each with unique containerField values: backTexture, bottomTexture, frontTexture, leftTexture, rightTexture, or topTexture (rather than default containerField='texture').

All X3D encodings define parent-child relationships. Only a small number of nodes in .x3d XML encoding might require a non-default containerField value, so the XML encoding is actually much more terse than other X3D encodings.

Quality Assurance (QA): the X3D Validator checks default and defined containerField values for logical correctness.
Validation choices

The following simple type restrictions are being developed for containerField Quality Assurance (QA).

*    containerFieldChoicesAudioClip for AudioClip.
*    containerFieldChoicesDISEntityTypeMapping for DISEntityTypeMapping
*    containerFieldChoicesHAnimJoint for HAnimJoint
*    containerFieldChoicesHAnimSegment for HAnimSegment
*    containerFieldChoicesHAnimSite for HAnimSite
*    containerFieldChoicesMetadata for six Metadata* nodes MetadataBoolean, MetadataDouble, MetadataFloat, MetadataInteger, MetadataString, MetadataSet.
*    containerFieldChoicesLODShapeTransform for LOD, Shape, Transform.
*    containerFieldChoicesTexture for PixelTexture, MultiTexture.
*    containerFieldChoicesX3DUrlObjectTexture for ImageTexture, MovieTexture, ImageCubeMapTexture, ImageTexture3D.
*    containerFieldChoicesX3DUrlObject for additional nodes supporting X3DUrlObject: Anchor, GeoMetadata, Inline, Script.
*    containerFieldChoicesPackagedShader for PackagedShader.
*    containerFieldChoicesShaderPart for ShaderPart

_Future improvements_

Ongoing work for X3D Version 4 and X3D Unified Object Model (X3DUOM) makes a number of optimizations possible and desirable. Current improvements are testing whether complete validation of containerField values can be accomplished by multiple tools.

*    CADFace issue Mantis 1234 to change unnecessarily different containerField='shape' and rename as containerField='children' instead.
*    DISEntityTypeMapping: enter Mantis issue to change unnecessarily different containerField='mapping' and rename as containerField='children' instead.
*    CollidableShape: enter Mantis issue to change unnecessarily different field name containerField='shape' and rename as containerField='children' instead.
*    ComposedCubeMapTexture, TextureBackground: enter Mantis issue to make six sets of field names identical for contained textures, e.g. backTexture becomes back etc.
*    GeoLOD Mantis issue 920 to change unnecessarily different field name containerField='rootNode' and rename as containerField='children' instead. Also enter Mantis issue to implement object interface X3DUrlObject.
*    GeoMetadata: enter Mantis issue to implement object interface X3DUrlObject.
*    LoadSensor enter Mantis issue to change unnecessarily different field name containerField='watchList' and rename as containerField='children' instead. Child node restrictions can achieve a functionally equivalent effect and improve the object-oriented design.
*    Shader nodes deserve a further close look.

These changes will be considered by Web3D Consortium members with subsequent review by the X3D Community. Companies, institutions, agencies and individuals are invited to Join Web3D Consortium to participate and influence this important continuing evolution of X3D.
====================================================================================

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