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

Don Brutzman brutzman at nps.edu
Fri Jul 6 06:36:25 PDT 2018

Regression testing that applied X3D v4 Schema to all scenes in X3D Example Archives has uncovered another set of containerField cases for the in the Volume Rendering component.


🔖 Variations from containerField defaults

14. 	X3DTexture3DNode nodes ComposedTexture3D, ImageTexture3D and PixelTexture3D nodes can have one of several containerField values, depending on relationship to parent node: texture (default), gradients, surfaceNormals, segmentIdentifiers, watchList (for ImageTexture3D with parent LoadSensor), or voxels.

These are now addressed and disambiguated from 2D texture nodes by the following documented enumeration types.

🔖 Validation choices for containerField

j. containerFieldChoicesX3DTexture2DNode for PixelTexture, MultiTexture.

k. containerFieldChoicesX3DTexture3DNode for nodes with abstract type X3DTexture3DNode, namely ComposedTexture3D, ImageTexture3D and PixelTexture3D.

Matching changes have been checked in and deployed for X3D v4 XML Schema and DTD.

All regression tests now pass on this issue, and no other containerField issues are currently identified.

Next up, will be looking at

40.4.5 ParticleSystem

which has uniquely named SFNode fields
   SFNode   []       colorRamp         NULL      [X3DColorNode]
   SFNode   []       texCoordRamp      NULL      [TextureCoordinate]

Am expecting this will add potential containerField values to Color, ColorRGBA and TextureCoordinate.  Further expect to add these to list of unnecessary containerField (SF/MFNode naming) complications that can be simplified in X3D v4, collected here:

🔖 Future changes for improving containerField
Ongoing work for X3D Version 4 and X3D Unified Object Model (X3DUOM) makes a number of optimizations possible and desirable. The following changes to SFNode/MFNode field names might reduce the number of containerField specifications by half.

We are very close to having all known containerField special cases covered in X3D XML Schema DTD and X3DUOM.  None of this tighter validation affects existing legal scenes.

Continued review welcome.  When ready, am expecting to ripple changes backward from X3D v4 to all X3D v3.x versions for consistency.

On 6/29/2018 9:15 AM, Don Brutzman wrote:
> Work continues to improve containerField validation, with another update pushed today.
> A new Ant build target coerces validation of all scenes in the X3D Examples Archive using the draft x3d-4.0.xsd schema.  Everything seems to be running pretty cleanly, but every new test reveals new edge cases.  The latest notable restriction is on Group LOD Shape and Transform for containerField='skin' when contained by a parent HAnimHumanoid node.
> The X3D v4 schema and DTD updates are now deployed.  These changes are also reflected in X3D Tooltips, X3D Unified Object Model (X3DUOM) and X3DJSAIL.  For ease of inspection, the updated containerField section on X3D Scene Authoring Hints appears below.
> Once through all of the regression tests, I'll be applying all changes in X3D 3.0 through 3.3 as well.  There are no forward/backward compatibility issues, just "good hygiene" and strict quality assurance (QA).
> It is clear that we will be able to rapidly advance X3D v4 validation tools to track the specification development.  As X3DUOM "squares away" XML VRML and JSON encodings plus Java/Javascript programming language bindings, forthcoming X3D variants for binary, C/C++/C# and Python will be able to follow closely behind without loss of generality.  Indeed "X3D Anywhere" will mean a lot.
> As ever, all feedback testing and improvements are welcome.  Have fun with X3D anywhere!  8)
> On 6/19/2018 10:52 PM, Don Brutzman wrote:
>> 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
>> http://www.web3d.org/specifications/java/X3DJSAIL.html
>> ====================================================================================
> X3D Scene Authoring Hints: containerField
> http://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#containerField
> [current copy]
> _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.
> 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'). See containerFieldChoicesGroupLODShapeTransform.
> 3.     Collision can contain a single nonrendered proxy Shape (or X3DGroupingNode) node with containerField='proxy' (rather than default containerField='children'). See containerFieldChoicesGroupLODShapeTransform.
> 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.     HAnimHumanoid can contain a single Group, LOD, Shape or Transform with containerField='skin' rather than default containerField='children'. See containerFieldChoicesGroupLODShapeTransform.
> 7.     HAnimJoint       has default containerField='children' when parent is another HAnimJoint, and has containerField value of joints or skeleton when parent node is HAnimHumanoid.
> 8.     HAnimSegment has default containerField='children' when parent node is an HAnimJoint, and has containerField='segments' when parent node is HAnimHumanoid.
> 9.     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.
> 10.     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.
> 11.     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').
> 12.     Sound can contain a single MovieTexture node with containerField='source' (rather than default containerField='texture').
> 13.     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 relatively 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.
> 🔖 *Validation choices for containerField*
> Quality Assurance (QA): the X3D Validator checks default and defined containerField values for logical correctness.
> The following simple types are defined in X3D Schema and X3D DOCTYPE definitions to explicitly validate these allowed-value relationships.
> a.    containerFieldChoicesAudioClip for AudioClip.
> b.    containerFieldChoicesDISEntityTypeMapping for DISEntityTypeMapping.
> c.    containerFieldChoicesGroupLODShapeTransform for Group, LOD, Shape, Transform.
> d.    containerFieldChoicesHAnimJoint for HAnimJoint
> e.    containerFieldChoicesHAnimSegment for HAnimSegment.
> f.    containerFieldChoicesHAnimSite for HAnimSite.
> g.    containerFieldChoicesMetadata for six Metadata* nodes MetadataBoolean, MetadataDouble, MetadataFloat, MetadataInteger, MetadataString, MetadataSet.
> h.    containerFieldChoicesPackagedShader for PackagedShader.
> i.    containerFieldChoicesShaderPart for ShaderPart.
> j.    containerFieldChoicesTexture for PixelTexture, MultiTexture.
> k.    containerFieldChoicesUrlObjectTexture for ImageTexture, MovieTexture, ImageCubeMapTexture, ImageTexture3D.
> l.    containerFieldChoicesX3DUrlObject for additional nodes supporting X3DUrlObject: Anchor, GeoMetadata, Inline, Script.
> *Future improvements for containerField*
> 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.
> *    Collision: content model definitions for contained nodes are insufficiently strict. See issue Mantis 1149.
> *    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: see issue Mantis 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.
> *    Nodes in the Programmable shader component all deserve a further close look. While everything works correctly, node naming is confusing and certainly improvable.
> 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