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

[Don Brutzman]

On 12/16/2015 8:04 AM, Leonard Daly wrote:
> 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.

yes

>  Can you please clarify?

in the great majority of cases they don't need to worry about containerField because it is taken care of for them.

>> 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.

Possibly... but based on many prior efforts am not optimistic.  It sounds straightforward but it is often difficult or impossible to integrate such a change in the content-model design patterns for contained nodes because they get so convoluted/confounded so quickly due to non-deterministic child sequencing requirements.

Paraphrased, a "simple" pattern for authors can sometimes by a byzantine/unmanageable pattern for spec or tool developers.

>> 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.

I updated the supporting example to show full number of wrapper tags which should be provided (attached).

Scene includes 21 nodes, 34 open/close element tags, 44 wrapper tags, producing 78 scene-graph tags total if wrapper tags are required.

>> 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?

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20151219/3807d853/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WrapperTagsExample.x3d
Type: model/x3d+xml
Size: 4872 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20151219/3807d853/attachment-0001.x3d>