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

[Keith]

I like containerfields!  

Sure, field wrappers would be better. But, container fields do effectively solve the problem. 

Keith Victor

Sent from my iPhone

On Aug 5, 2010, at 9:59 PM, Tony Parisi <tparisi at gmail.com> wrote:

> Wow it's Deja vu all over again.
> 
> Fwiw i'm with Braden.
> 
> Sent from my iPhone
> 
> On Aug 5, 2010, at 6:54 PM, Braden McDaniel <braden at endoframe.com> wrote:
> 
>> 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>
>> 
>> 
>> _______________________________________________
>> X3D-Public mailing list
>> X3D-Public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> 
> _______________________________________________
> X3D-Public mailing list
> X3D-Public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org