[x3d-public] containerField modifications by script

[Don Brutzman]

1. Agreed, mostly...  Mutation is even more worrisome when you consider that inserting an incorrect attribute value for containerField might contradict the actual DOM tree structure.

2. However, the DOM tree itself reflects XML tree structure.  So how would you create the following in DOM without a mutator method?

	<Collision><Shape USE='SomeVisibleGeometry'/><!-- containerField='children' --></Shape></Collision>
and
	<Collision><Shape containerField='proxy'><Box/></Shape></Collision>

So, using the DOM, it appears you would need to set the containerField='proxy' attribute (on the second Shape) to match XML-style scene semantics.

Is that a correct match for your current effort?

3.Meanwhile the containerField defaults are indeed listed in the X3D Object Model as support for tool builders.  Other field default values are included similarly.

In the Java SAI Library, the object-oriented structure of each scene subgraph is discernable by the object-member-variable field name.  Example:

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

	http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/java/Navigation/CollisionClass.html

	see SFNode methods clearProxy() setProxy() and setProxy(), versus MFNode methods addChildren()clearChildren() setChildren() etc.

4. Again, in the Java SAI Library, the only occasion I see to use those values is when serializing XML output, to avoid providing those unnecessary default values in XML output.  That code is being produced next.

Of potential interest to the X3D object model:  where choice exists, the number of legal containerField values is finite - there are no indefinite possibilities.  (The X3D-Edit code excerpt pointed to them.)  So this is probably good information to put in the X3D Schema annotations and the X3D Object model.

I believe the X3D Tooltips also include them.  See Collision then containerField hint at

	http://www.web3d.org/x3d/content/X3dTooltips.html#Collision

5. Will likely add containerField_DEFAULT string constants to each concrete node class as information a programmer might want, but will not ever (never, not rarely) need in practice, unless they are building their own special X3D parsing program in Java to handle such content.

Still no need in Java SAI Library for "setContainerField()" methods because there is never an occasion to do that, given each scene graph's strict O-O organization.

6.  Tricky business, all right.

Take-away principle: the parent-child relationship has to be labeled somewhere for the rare occasions needing disambiguation.

Take-away example: if you can't tell whether a Shape is either a proxy field or else one of the children for a parent Collision node, then you likely need containerField.

Good luck, hope this helps!


On 10/26/2016 4:08 PM, Andreas Plesch wrote:
> Thanks. This is valuable feedback.
>
> Andreas
>
>
> On Oct 26, 2016 11:43 AM, "Yves Piguet" <yves.piguet at gmail.com <mailto:yves.piguet at gmail.com>> wrote:
>
>     I'd rather consider the containerField as just a convenience of the XML encoding. The node with a containerField value is a child of its parent which perhaps you might want to detach and reattach explicitly; not the opposite where the containerField value would be some kind of a child property of the node. I wouldn't keep a containerField property once the X3D scene tree is built. So I agree with you to not support containerField mutation.
>
>     Yves
>
>     On 26 oct. 2016, at 17:20, Andreas Plesch wrote:
>
>     > There may be rare circumstances when an application may want to modify the containerField value of an existing x3d node although I am not sure if this is ever a concern.
>     >
>     > So for cobweb_dom, I do think mutations to the containerField attribute may only need to lead to a warning that such is not supported and ignored.
>     >
>     > Unless there is some situation where this would be valuable ? An application can always delete the x3d node (causing a set_ event to defaults) and then add a new x3d node in place (causing a set_ event to the new value).
>     >
>     > -Andreas


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