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

[Joe D Williams]

> But containerField is also a rather unintuitive concept, requiring 
> to think 'backwards', eg. up the hierarchy.

It really helps to look at the X3D Classic and VRML encodings. Not 
really up the hierarchy except to verify that the parent can contain 
the following node. Mostly it is as straightforward as

Not

 <proxy>
   <Group DEF=”group3” />
 </proxy>

but instead

   <Group DEF=”group3” containerField=”proxy”/>

another is, for X3D Classic or VRML encoding

 material Material {
     diffuseColor 0 0 0 specularColor 0 0 0
     ambientIntensity 0.0
}

vs X3D XML encoding

This:

<Material diffuseColor='0 0 0' specularColor='0 0 0'
              ambientIntensity='0.0'  containerFIeld='material'
</Material>

Not this

<material>
  <Material diffuseColor='0 0 0' specularColor='0 0 0'
      ambientIntensity='0.0'
  </Material>
</material>

The VRML syntax has the 'container' built into the syntax and so it 
was known something was needed. The XML schema could give default 
values, so the 'container' was made into an attribute (along with 
other 'content' fields, even big ones, because, as one consideration, 
validation of strongly typed data in the body of an element was not 
then available in XML schema).

Thanks,
Joe

----- Original Message ----- 
From: "Andreas Plesch" <andreasplesch at gmail.com>
To: "Roy Walmsley" <roy.walmsley at ntlworld.com>
Cc: "X3D Graphics public mailing list" <x3d-public at web3d.org>
Sent: Monday, October 10, 2016 2:55 PM
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/P
> art01/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



--------------------------------------------------------------------------------


> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>