[x3d-public] containerField modifications by script

[Andreas Plesch]

On Wed, Oct 26, 2016 at 10:31 PM, Don Brutzman <brutzman at nps.edu> wrote:

> 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.
>

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.


> 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?
>
>
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.


> 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/X3dJavaSceneAuthori
> ngInterface.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.
>
>
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.


> 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.
>

The question is if it should be possible to change that parent-child
relationship after it is initially established. Probably not.

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/brutzma
> n
>



-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161027/f3a62266/attachment.html>