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

[Joe D Williams]

>  ... the X3D Working Group came up with the idea of containerField 
> to indicate which child element belonged to which
parent field.

wellm maybe ... to indicate that a child element can be part of the 
parent field, and/or that the contained stuff was off a specific child 
type, and so on. .

I thought we wouldn't need it because the schema can tell all.
It turns out so far the schema cannot tell all in at least one 
instance, so we needed something.

So, instead of a containing structure named for the contained 
structure which is fine in VRML but is horrible in X3D XML we have 
concrete nodes that sometimes seem to need this attribute defined as 
other than the mostly obvious default.

>     <children>
...
>     </children>

Isn't it pleasant to have children and /children everywhere just to 
specially announce their presence and claim their indention.

> Transform can have 'children' to define geometry and appearance and 
> metadata to define metadata.

Yes, <geometry> ... </geometry> and <appearance> ... </appearance> 
and <metadata> ... </metadata> would be container nodes

> Do other people have any thoughts on this?

Please, those are a not necessary containing structure named for the 
contained structure(s).
Follow through with full production of our beloved <Shape>...</Shape> 
node to see all, or at least a lot of it.

> format is easier to read and certainly parses ...

Make a schema too. Note that there are plenty container nodes, like 
children but with different names, available for use. In fact, please 
find that there is a unique <containername> ... </containername> set 
for each different containerField you can find.

Thanks and Best,
Joe



----- Original Message ----- 
From: "Leonard Daly" <Leonard.Daly at realism.com>
To: "'x3D WG'" <x3d at web3d.org>; "X3D Graphics public mailing list" 
<x3d-public at web3d.org>
Sent: Monday, December 14, 2015 1:06 PM
Subject: [x3d] 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/
>


--------------------------------------------------------------------------------


> _______________________________________________
> x3d mailing list
> x3d at web3d.org
> http://web3d.org/mailman/listinfo/x3d_web3d.org
>