[x3d-public] getContainerField() [was cobweb DOM integration]

[Joe D Williams]

OK, you don't have to learn Classic to see the concept of a container 
which in this case could also be considered as a parser/loader alert 
flag.

Just recall that when you are loading a scene you know what type of 
node you are in and what fields, and fields that are nodes, are 
acceptable content. All you wish for is a signal that tells you what 
to do with the field of data that comes next. So, the processor is in 
a Shape and there are a couple of possibilities available. If the next 
field is a 'geometry' then do this with the following fields; if 
'appearance' then there is probably a different set of stuffs to do; 
and so on. So, from the original crew who would refuse to turn loose 
of their highly optimized loaders, these, well, sort of 
meta-descriptor syntax, when considered in X3D became known as the XML 
wrapper tags.

The wrapper tags provided the functionality of the VRML 
<nextnodetype>...</nextnodetype> syntax. However, the VRML loader 
alert syntax is not necessary in XML since the XML schema is always 
available to look up those kind of details like if this node is 
acceptable in the current structure. And besides, those wrapper tags 
are toxic syntax in the user code.

Besides, the standard was well enough developed so the language 
structure actually used mostly defaults for this verbage. And really, 
the syntax was not a great advantage to someone learning to keyboard 
user code, especially when stuff like color Color happens. But there 
were a few exceptions, so our containerField is born or mutated from 
something else, whatever.

For now, its highest worthiness is use as documentation, probably not 
as steering your high speed scene loader. Some have called it a hack 
to move an important, perhaps the most important keyword in some 
processing applications, from a leading item only to be hidden in some 
mostly defaulted, and thus mostly absent from the user code, attribute 
field of the node. So finally, a simple attribute value of 
containerField declares the name of an abstract set of related nodes, 
one of which must be the name of this current concrete node.

Thanks and Best,
Joe


----- Original Message ----- 
From: "Andreas Plesch" <andreasplesch at gmail.com>
To: "Joe D Williams" <joedwil at earthlink.net>
Cc: "Roy Walmsley" <roy.walmsley at ntlworld.com>; "X3D Graphics public 
mailing list" <x3d-public at web3d.org>
Sent: Tuesday, October 11, 2016 8:55 AM
Subject: Re: [x3d-public] getContainerField() [was cobweb DOM 
integration]


> On Mon, Oct 10, 2016 at 7:17 PM, Joe D Williams 
> <joedwil at earthlink.net>
> wrote:
>
>> But containerField is also a rather unintuitive concept, requiring 
>> to
>>> think 'backwards', eg. up the hierarchy.
>>>
>>
>> It really helps to look at the X3D Classic and VRML encodings. Not 
>> really
>> up the hierarchy except to verify that the parent can contain the 
>> following
>> node.
>>
>
> I agree, it really helps to understand the VRML encoding although I 
> am not
> sure it is a good sign that one should do so to understand the XML 
> encoding.
>
> When I first looked at X3D, I remember that I decided to ignore the
> containerField attribute due its apparent strangeness. It took to me 
> some
> time to understand that it has to do with the parent node (after 
> some more
> time understanding that child nodes are field values, eg. fields are 
> not
> necessarily attributes). Perhaps "parentField" would have been a 
> more
> straightforward name for this attribute.
>
> -Andreas
>
>
> -- 
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453
>