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

[Michalis Kamburelis]

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

Michalis