[X3D-Public] Contour2D containerField analysis

Thu Aug 29 15:58:56 PDT 2013

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 forensics!)

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.

http://www.web3d.org/files/specifications/19776-1/V3.3/Part01/EncodingOfNodes.html#NurbsCurve2D

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

http://www.web3d.org/specifications/

http://www.web3d.org/specifications/X3dDoctypeDocumentation3.3.html#NurbsCurve2D

http://www.web3d.org/specifications/X3dSchemaDocumentation3.3/x3d-3.3_NurbsCurve2D.html#Link149

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

http://www.web3d.org/x3d/stylesheets/EncodingOfNodes.html#Contour2D

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" default="trimmingContour"/>

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

   <Contour2D containerField="trimmingContour"/>

   <NurbsCurve2D/>
   <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:

http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/nurbs.html

- NurbsTrimmedSurface can contain Contour2D as a trimmingContour field

- and no others?

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

http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/concepts.html#InterfaceHierarchy

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

27.4.1 Contour2D

http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/nurbs.html#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 4.4.2.3 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."
http://www.winstonchurchill.org/learn/speeches/speeches-of-winston-churchill/103-never-give-in

http://www.youtube.com/watch?v=ywDZKfZ-iZA

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<https://webmail.nps.edu/owa/redir.aspx?C=G3Rvfdu1Z0m0CnW8jzwQBCHaiiZ4dNAIOPiX7qnFTuF1i1OfTKg-1pEk4WCkULkqa1xpCoWVd0w.&URL=http%3a%2f%2ffaculty.nps.edu%2fbrutzman>
________________________________
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
http://www.web3d.org/x3d/content/examples/Basic/NURBS/NurbsTrimmedSurface.x3d
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:
http://www.web3d.org/files/specifications/19776-1/V3.2/Part01/EncodingOfNodes.html#NurbsCurve2D
- X3D 3.3:
http://www.web3d.org/files/specifications/19776-1/V3.3/Part01/EncodingOfNodes.html#NurbsCurve2D

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

<Contour2D>
   <NurbsCurve2D containerField="children" ..>
   ...
</Contour2D>

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 rule
will be added to view3dscene, the warning will disappear :)

Michalis

_______________________________________________
X3D-Public mailing list
X3D-Public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20130829/3116d1d1/attachment.html>