[X3D-Public] Contour2D containerField analysis
Joe D Williams
joedwil at earthlink.net
Mon Sep 2 07:45:55 PDT 2013
http://www.web3d.org/files/specifications/19775-1/V3.3/index.html
> 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#f-Objecthierarchy
Not in what I see. It is shown as X3DNode.
http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/nurbs.html#Contour2D
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
models.
Thanks and Best,
Joe
----- 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
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
--------------------------------------------------------------------------------
> _______________________________________________
> 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