[X3D-Public] [X3D] containerField is should or must ?

[Braden McDaniel]

On Fri, 2010-08-06 at 00:53 +0200, Michalis Kamburelis wrote: 
> Joe D Williams wrote:
> > But, since xml processors were not smart enough then and maybe not even
> > now about this type of inference for validation, and due to proto first
> > node needs, we got ahead using containerField.
> 
> Just a note: there are situations when explicit containerField is really
> needed, even without the prototypes.
> 
> For example the Collision node,
> http://web3d.org/x3d/specifications/ISO-IEC-19775-1.2-X3D-AbstractSpecification/Part01/components/navigation.html#Collision
> , has the "proxy" and "children" fields, both accepting any
> X3DChildNode. So if you define <Shape> inside <Collision> node, by
> default it goes into Collision.children. You have to use explicit <Shape
> containerField="proxy"> if you want to place it inside Collision.proxy.
> There is no way for a browser to automatically guess which shapes are
> "more suitable" for a "proxy" field than "children" field.
> 
> (We could invent some wrapper node, like Proxy, to workaround this and
> other such cases. But this would make node graph unnecessarily more
> complicated. Basically, I like the containerField idea --- it solves the
> problem universally, for all corner cases similar to the Collision node.)

There's no question that containerField is made necessary by other
aspects of the XML encoding.  Unfortunately, time has shown that those
aspects are themselves poor design choices.

fieldValue wrapper nodes were talked about some months ago as an
approach to resolve issues with overly large attribute values.  These
wrappers also render containerField unnecessary; and in light of their
availability, it probably makes sense to deprecate containerField.

-- 
Braden McDaniel <braden at endoframe.com>