[x3d-public] Use of containerField in V4+

[doug sanden]

Leonard,
Good idea.
-Doug
more..
 In theory the containerField does the same thing. But we couldn't rely on exporters/authors putting that in as an attribute -exporter writers would have to understand what containerField means (it took me 5 years to figure it out)- so we would have to program special agorithms to figure out what the containerFields should have been if inot in the file. And that's a headache. (freewrl has some pretty haywire code for it). Whereas with elements, if the element structure isn't right it just doesn't parse. And its easier for exporter developers to get the idea when its an element.




From: x3d-public <x3d-public-bounces at web3d.org> on behalf of Leonard Daly <Leonard.Daly at realism.com>
Sent: December 14, 2015 2:06 PM
To: 'x3D WG'; X3D Graphics public mailing list
Subject: [x3d-public] Use of containerField in V4+
  
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