[x3d-public] getContainerField() [was cobweb DOM integration]

Andreas Plesch andreasplesch at gmail.com
Mon Oct 10 17:02:01 PDT 2016


On Oct 10, 2016 7:17 PM, "Roy Walmsley" <roy.walmsley at ntlworld.com> wrote:
>
> Hi all,
>
> I did recall later that MetadataBoolean can be used in MetadataSet, not
just in the metadata field, but also in the value field.
>
Sorry, I missed that.
>
> And another example is any node derived from X3DRigidJointNode, which has
the two fields body1 and body2, both of which take a RigidBody child node.
>

Is this is a case where a containerField value may be best required, eg. a
default of null ?

>
> And going back to your comments on the Collision node having both
children, an MFNode field, and proxy an SFNode field; all you can deduce
without reference to containerField info, is that a maximum of one child
goes into proxy.
>

Hmm, not sure I follow. Does this mean proxy accepts a MFNode with a single
SFNode item? Oh, I see, in XML there is no way to distinguish between this
case and a SFNode. Perhaps there should be a way ? A <Multiple> element ?

>
> Roy
>
>
>
> From: Andreas Plesch [mailto:andreasplesch at gmail.com]
> Sent: 10 October 2016 22:56
> To: Roy Walmsley <roy.walmsley at ntlworld.com>
> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>; doug sanden <
highaspirations at hotmail.com>
>
> Subject: Re: [x3d-public] getContainerField() [was cobweb DOM integration]
>
>
>
> On Mon, Oct 10, 2016 at 3:47 PM, Andreas Plesch <andreasplesch at gmail.com>
wrote:
>>
>> Hi Roy,
>>
>> On Oct 10, 2016 10:27 AM, "Roy Walmsley" <roy.walmsley at ntlworld.com>
wrote:
>> >...
>> > Q1 – Usually (always) just one field for a given parent nodetype. I
don’t have an exhaustive answer, but I will give an example. It may be the
only one, not sure. Look at the Collision node, (19775-1, 23.4.2,
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/navigation.html#Collision.
Note that there is a children field and a proxy field, both of which accept
X3DChildNode. In other words, what can go in one can also go in the other.
>> >
>>
>> This may not be the best example since children is a mfnode and proxy is
a sfnode. So based on the node type of the child it would be still possible
to determine which field is targeted ?
>
> I was grepping through the web3d and savage examples to get a quick sense
of how containerField is used. One type of usage seems to be just repeating
the default containerField value, presumably as an aid for a human
interpreter of the x3d, particularly in the savage archive. Another type of
usage is with user defined fields in proto instances where the default
container field value necessarily does not apply. A third type is with
certain components: H-Anim, Rigid Body seem to use it most. Volume
Rendering, as Doug noticed, also requires containerField='voxels' for
VolumeData.
>
> I can see why for XML it was decided to have containerField rather than
wrapper tags. It is awkward to have a <Children> element under grouping
nodes when the wrapped elements are actually child nodes, and particularly
so when repeated many times. But containerField is also a rather
unintuitive concept, requiring to think 'backwards', eg. up the hierarchy.
Well, I am sure this was discussed at length and it would be difficult to
come up with a better solution without deep changes.
>
>
>
> -Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161010/1ef3c315/attachment.html>


More information about the x3d-public mailing list