<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 26, 2016 at 10:31 PM, Don Brutzman <span dir="ltr"><<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br></blockquote><div><br></div><div>Yes. But this may not be too different from the initial parsing of a DOM tree with an invalid containerField value. So x3d browsers have to do checking at that point, unless they assume a strictly conforming x3d scene description. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. However, the DOM tree itself reflects XML tree structure. So how would you create the following in DOM without a mutator method?<br>
<br>
<Collision><Shape USE='SomeVisibleGeometry'/><!-<wbr>- containerField='children' --></Shape></Collision><br>
and<br>
<Collision><Shape containerField='proxy'><Box/><<wbr>/Shape></Collision><br>
<br>
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.<br>
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is that a correct match for your current effort?<br>
<br></blockquote><div><br></div><div>Yes, containerField is handled by cobweb correctly, eg. it accepts values other than the default value. The question is if it should be possible to later (after initial parsing and loading) then mutate the existing 'proxy' value of the second Collision node to another value (say 'children'), in a live scene. I cannot think of a scenario where doing so would be advantageous.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
In the Java SAI Library, the object-oriented structure of each scene subgraph is discernable by the object-member-variable field name. Example:<br>
<br>
<a href="http://www.web3d.org/specifications/java/X3dJavaSceneAuthoringInterface.html" rel="noreferrer" target="_blank">http://www.web3d.org/specifica<wbr>tions/java/X3dJavaSceneAuthori<wbr>ngInterface.html</a><br>
<br>
<a href="http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/java/Navigation/CollisionClass.html" rel="noreferrer" target="_blank">http://www.web3d.org/specifica<wbr>tions/java/javadoc/org/web3d/<wbr>x3d/java/Navigation/CollisionC<wbr>lass.html</a><br>
<br>
see SFNode methods clearProxy() setProxy() and setProxy(), versus MFNode methods addChildren()clearChildren() setChildren() etc.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I believe the X3D Tooltips also include them. See Collision then containerField hint at<br>
<br>
<a href="http://www.web3d.org/x3d/content/X3dTooltips.html#Collision" rel="noreferrer" target="_blank">http://www.web3d.org/x3d/conte<wbr>nt/X3dTooltips.html#Collision</a><br>
<br>
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.<br>
<br></blockquote><div><br></div><div>cobweb has a node.getContainerField() method which returns the default containerField value for each node. It is used in the parser to determine the default field name of the parent node whose value will be set. If there is a XML containerField attribute, the attribute value will be used instead if it matches one in the node's array of possible fields.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
6. Tricky business, all right.<br>
<br>
Take-away principle: the parent-child relationship has to be labeled somewhere for the rare occasions needing disambiguation.<br></blockquote><div><br></div><div>The question is if it should be possible to change that parent-child relationship after it is initially established. Probably not.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
Good luck, hope this helps!<br>
<br>
<br>
On 10/26/2016 4:08 PM, Andreas Plesch wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks. This is valuable feedback.<br>
<br>
Andreas<br>
<br>
<br>
On Oct 26, 2016 11:43 AM, "Yves Piguet" <<a href="mailto:yves.piguet@gmail.com" target="_blank">yves.piguet@gmail.com</a> <mailto:<a href="mailto:yves.piguet@gmail.com" target="_blank">yves.piguet@gmail.com</a>><wbr>> wrote:<br>
<br>
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.<br>
<br>
Yves<br>
<br>
On 26 oct. 2016, at 17:20, Andreas Plesch wrote:<br>
<br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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).<br>
><br>
> -Andreas<br>
</blockquote>
<br>
<br>
all the best, Don<span class="HOEnZb"><font color="#888888"><br>
-- <br>
Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA <a href="tel:%2B1.831.656.2149" value="+18316562149" target="_blank">+1.831.656.2149</a><br>
X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzma<wbr>n</a><br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div></div>