<p dir="ltr">Thanks. This is valuable feedback.</p>
<p dir="ltr">Andreas</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Oct 26, 2016 11:43 AM, "Yves Piguet" <<a href="mailto:yves.piguet@gmail.com" target="_blank">yves.piguet@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
> --<br>
> Andreas Plesch<br>
> 39 Barbara Rd.<br>
> Waltham, MA 02453<br>
> ______________________________<wbr>_________________<br>
> x3d-public mailing list<br>
> <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a><br>
<br>
</blockquote></div></div>