[X3D-Public] [X3D] containerField is should or must ?
Keith
keithrvictor at gmail.com
Sat Aug 7 09:32:40 PDT 2010
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
More information about the X3D-Public
mailing list