[x3d-public] [x3d] Use of containerField in V4+

[Leonard Daly]

On 12/15/2015 3:54 AM, Don Brutzman wrote:
> containerField describes a node's relationship to its parents.  The 
> default values are typically not needed by authors or generators.

Do you mean "... typically sufficient for authors or generators"? If 
not, I do not understand the above statement. Can you please clarify?


>
> Debate on this topic was a lengthy effort a long time ago. Wrapper 
> tags only simplify rare occurrences,such as Collision node children, 
> distinguishing between a 'proxy' Shape and 'children' Shape nodes.

There is also the need for 'containerField' with MetadataSet. It is used 
in the X3D resources at 
http://www.web3d.org/x3d/content/examples/Basic/development/_pages/page39.html 
(http://www.web3d.org/x3d/content/examples/Basic/development/MetadataExamples.html).

For those few cases when a 'containerField' is required, is it 
reasonable to define wrapper tags. That way 'containerField' could be 
eliminated (deprecated). Many people I talk to are confused how to 
properly use 'containerField' or know when it is required. Using wrapper 
tags for the rare cases when it is needed will address most of the 
concerns listed on the page below while making the structure of the X3D 
field easier to understand.


Leonard Daly


>
> Extensive reasons against wrapper tags in the XML encoding can be 
> found in
> http://www.web3d.org/x3d/content/examples/Basic/development/WrapperTagsConsideredHarmful.html 
>
>
> As a result we have a much terser XML encoding with corresponding 
> reductions in file size, transfer times and scene loading.
>
> Meanwhile, the developmental JSON encoding currently uses the field 
> names directly, similar to the manner that you describe. Also seems to 
> parse OK.
>
> I think this illustrates the difference between a document-oriented 
> encoding like XML and an object-oriented encoding like JSON.
>
>
> On 12/14/2015 1:06 PM, Leonard Daly wrote:
>> A long (Internet-) time ago, the X3D Working Group came up with the 
>> idea of containerField to indicate which child element belonged to 
>> which parent field. This only really applies when an X3D node has 
>> fields that can be nodes. E.g., Transform can have 'children' to 
>> define geometry and appearance and metadata to define metadata. Most 
>> of the time the relationship is obvious, especially when a field can 
>> can only contain one type of node.
>>
>> In all of the XML I have seen for many other applications (documents, 
>> books, medical records, government records, etc.) do not use that 
>> sort of structure. Everything is put into explicit child nodes. That 
>> would mean something like Transform would be:
>>
>> <Transform ...>
>>      <children>
>>          <Shape>...</Shape>
>>          <Shape>...</Shape>
>>          <Shape>...</Shape>
>>      </children>
>>      <metadata>
>>          <MetadataString ... />
>>          <MetadataFloat ... />
>>          <MetadataInteger ... />
>>          <MetadataString ... />
>>          <MetadataString ... />
>>      </metadata>
>> </Transform>
>>
>> This completely eliminate the ambiguity of use without a 
>> containerfield with the expense of adding in an extra layer for every 
>> use. I think this format is easier to read and certainly parses 
>> easier in standard parsers that come with PHP and Perl.
>>
>> Do other people have any thoughts on this?
>>
>> -- 
>> *Leonard Daly*
>> 3D Systems & Cloud Consultant
>> X3D Co-Chair on Sabbatical
>> LA ACM SIGGRAPH Chair
>> President, Daly Realism - /Creating the Future/
>
> all the best, Don


-- 
*Leonard Daly*
3D Systems & Cloud Consultant
X3D Co-Chair on Sabbatical
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20151216/44b9ee62/attachment.html>