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

Tony Parisi tparisi at gmail.com
Thu Aug 5 18:59:03 PDT 2010


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



More information about the X3D-Public mailing list