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

[Dave A]

Please excuse my brevity, I'll follow up with more details, but xml provides inherent containment, the only reason I can rationalize containerfields is to make it somewhat easier to shoehorn xml encoding to existing vrml parsers. Is there a push to correct this? i'm for that.

"Keith" <keithrvictor at gmail.com> wrote:

>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
>
>_______________________________________________
>X3D-Public mailing list
>X3D-Public at web3d.org
>http://web3d.org/mailman/listinfo/x3d-public_web3d.org

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.