[X3D-Public] Contour2D containerField analysis

Joe D Williams joedwil at earthlink.net
Mon Sep 2 07:45:55 PDT 2013


> 9.  Section " Object hierarchy" diagram shows that Contour2D 
> is an X3DGroupingNode (default containerField="children")


Not in what I see. It is shown as X3DNode.


27.4.1 Contour2D
Contour2D : X3DNode {...
 children       []   [NurbsCurve2D|ContourPolyline2D] ... }

So that is correct.

The next mentions are:

27.4.5 NurbsCurve2D ...
27.4.2 ContourPolyline2D ...
"NurbsCurve2D nodes are used as children of the Contour2D group."

which appears to be correct.

Then NurbsTrimmedSurface is a almost a grouping node except the 
add/remove names are different and no bb and includes

trimmingContour       []    [Contour2D]

The trimmingContour field, if specified, shall contain a set of 
Contour2D ...
so here the containerField is "trimmingContour"

So from what I see the Contour2D should always be containerField=
trimmingContour" and Contour2D could almost be an X3DGroupingNode but 
it doesn't need a bounding box.

I think I remember that there were two reasons Countour2D was not a 
grouping node. At one point the add/remove fields were named like 
NurbsTrimmedSurface and, like NurbsTrimmedSurface did not need a bb.

We actually almost needed a grouping node without bb for these.

But now it seems like I can't find an instance where he containerField 
for Contour2D should ever be anything else than "trimmingContour".

> Incidentally this whole problem is never an issue in ClassicVRML 
> encoding because field names must always be spelled out in that form

  Appearance Appearance { material Material {} } ) etc.

> Don't' get me started /don't get me started on that!  No further 
> discussion needed there.

Right, all you gotta do to fully step up to XML Schema and get rid of 
containerField :) or else to make sure that if the containerField is 
not there we give a suitable default, and that if it is there then is 
it a correct choice. That way we don't need masses of wrappers in our 
user code, like if we actually transcoded literally and did not rely 
on a schema to advise the processor about structures and content 

Thanks and Best,

----- Original Message ----- 
From: "Brutzman, Donald (Don) (CIV)" <brutzman at nps.navy.mil>
To: "Michalis Kamburelis" <michalis.kambi at gmail.com>; "Vincent 
Marchetti" <vmarchetti at ameritech.net>
Cc: "Cad3D working group" <Cad at web3d.org>; "X3D Graphics public 
mailing list" <x3d-public at web3d.org>
Sent: Thursday, August 29, 2013 3:58 PM
Subject: Re: [X3D-Public] Contour2D containerField analysis

Apologies for being relatively quiet.  Thanks for the dialog.

Here is a Contour2D analysis regarding the XML encoding.  Warning: 
kinda long (welcome to the wild and wonderful world of DTD/Schema 

1.  When Annex 6 says containerField="geometry" it is describing the 
default value, not a required value.

However this version (official draft but old) document appears to be 
incorrect; more to follow.


2. Mismatched default values are provided by X3D DTD 
(containerField="trimmingContour") and X3D Schema documentation 




A revised version of the Encoding of Nodes document shows 
containerField="trimmingContour" and is found at


The X3D Schema documentation is autogenerated using XML Spy.  It 
appears to be ignoring the override value. I will look into this.

3.  I looked back through the changelogs but did not find an occasion 
where these values changed.

4. Checking the DTD and Schema themselves reveals a default value of 
containerField="trimmingContour" for both, consistently.

http://www.web3d.org/specifications/x3d-3.3.dtd line 2406-7

<!ATTLIST Contour2D
 containerField NMTOKEN "trimmingContour"

http://www.web3d.org/specifications/x3d-3.3.xsd line 9860

  <xs:attribute name="containerField" type="xs:NMTOKEN" 

This confirms that there is a bug in the Schema documentation 
generator.  Or perhaps X3DNode should not get a default 
containerField, requiring it to be set explicitly each time (and 
thereby avoiding mismatch errors).  Will investigate further.

5.  Note that XML rules state that specifying default values for an 
attribute are not required.  Thus each of the following pairs of nodes 
are equivalent:


   <Contour2D containerField="trimmingContour"/>

   <NurbsCurve2D containerField="children"/>

Incidentally this whole problem is never an issue in ClassicVRML 
encoding because field names must always be spelled out in that form

  Appearance Appearance { material Material {} } ) etc.

Don't' get me started /don't get me started on that!  No further 
discussion needed there.

6.  What is not (yet) seen.  One could make the case that Contour2D 
containerField values should be limited to "trimmingContour" (and 
maybe another if found) since those are the only ones found in the 
specification.  I originally thought that an author might want a 
different containerField name when they create a prototype with an 
SFNode field - but that case is handled by ProtoInstance/fieldValue 
tags.  Similarly a Script/field tags could also contain Contour2D - 
again ignoring containerField value.  So... we could restrict values 
to the allowed enumeration value(s) if everyone is satisfied that they 
are the only use cases.  Since that would identify broken content, it 
is a good idea and consistent with past design.

7.  What rules:  the X3D Abstract Specification.  We always try to 
adjust DTD and Schema to most strictly validate what the spec says, to 
improve content quality, and not prevent the creation of valid 
content.  If they can be improved further to better match the 
specification, without error, then we do.

8.  When I check the X3D Abstract Specification, am finding the 
following parent nodes for Contour2D:


- NurbsTrimmedSurface can contain Contour2D as a trimmingContour field

- and no others?

9.  Section " Object hierarchy" diagram shows that Contour2D is 
an X3DGroupingNode (default containerField="children")


which is a mismatch to the deciding definition showing Contour2D is an 

27.4.1 Contour2D


This was probably the primary point of origin for our woes on this 
particular topic.

10.  For anyone still following, recommendations:

- Specification bug: change Contour2D node type to X3DNode in the diagram

- Verify whether other containerField child options exist (paragraph 
8), then

- Restrict allowed values to only those needed in DTD and Schema,

- I troubleshoot and fix default definitions so that the schema 
documentation generator matches the specification

Comments welcome, let's review them on the next X3D weekly 
teleconference and then we can proceed with fixes.

p.s. Quote of the day: Winston Churchill.

"Never give in. Never give in. Never, never, never, never—in nothing, 
great or small, large or petty—never give in, except to convictions of 
honour and good sense. Never yield to force. Never yield to the 
apparently overwhelming might of the enemy."


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 
X3D graphics, virtual worlds, navy robotics 
From: X3D-Public [x3d-public-bounces at web3d.org] on behalf of Michalis 
Kamburelis [michalis.kambi at gmail.com]
Sent: Thursday, August 22, 2013 12:26 PM
To: Vincent Marchetti
Cc: Cad3D working group; X3D Graphics public mailing list
Subject: Re: [X3D-Public] Announcement: view3dscene 3.13.0 - Mac OS X, 
networking, more

Vincent Marchetti wrote:
> http://www.web3d.org/x3d/content/examples/Basic/NURBS/NurbsTrimmedSurface.x3d
> When a NurbsTrimmedSurface is loaded, view3dscene generates a 
> warning:
> "Unknown X3D field name (indicated by containerField value) 
> "geometry" by node "NurbsCurve2D" inside node "Contour2D"
> This is spurious, the nodes in the examples follow the v 3.2 specs 
> for the NURBS component: 
> http://www.web3d.org/files/specifications/19775-1/V3.2/Part01/components/nurbs.html

Wow, many thanks for testing view3dscene, I'm glad you found it good 

As for the warning around NurbsCurve2D: view3dscene follows here the
specification to the letter, as far as I see. The fact that nodes
arrangement in
follows the specification doesn't necessarily mean that explicit
containerField="xxx" is not needed. The X3D XML encoding specification
says that NurbsCurve2D by default is looking for a "geometry" field in
parent node:

- X3D 3.2:
- X3D 3.3:

So, if you use NurbsCurve2D and want it to attach to 
field, you really should write it like this in XML:

   <NurbsCurve2D containerField="children" ..>

So says the specification :)

It's another matter whether the specification is right. IMHO it would
make sense to change X3D XML encoding spec in X3D 3.4 to say that
NurbsCurve2D.containerField by default is "children". And when this 
will be added to view3dscene, the warning will disappear :)


X3D-Public mailing list
X3D-Public at web3d.org


> _______________________________________________
> X3D-Public mailing list
> X3D-Public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org

More information about the X3D-Public mailing list