<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:147326208;
mso-list-template-ids:-297516010;}
@list l1
{mso-list-id:1575163572;
mso-list-type:hybrid;
mso-list-template-ids:-2051369316 -397508472 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l1:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal>Hi,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>During today’s X3D WG meeting we had some discussion on this topic.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>One viewpoint was expressed that the grammar as currently written is satisfactory, and more clear than the proposal below.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I agree that the existing grammar is not incorrect. But, is the use of nodeTypeId for both user defined prototypes and built-in nodes desirable.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The X3D suite of standards are written with major classes of users in mind. One is the scene author, the other is the player implementer.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>For the first user class, the scene author, the dual usage of nodeTypeId does indeed represent what goes into the syntax. An author would use them in the same way, and, other than providing the PROTO/EXTERNPROTO declaration, not be concerned about the difference.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Contrast this with the second user class, the player implementer. Now, this dual-usage is very different. When nodeTypeId represents a built-in node, the player can instantiate from a class definition built into the software. When representing a user-defined prototype, the instantiation needs to find the declaration in the prior user code, and build the instantiation from that. This requirement for a different approach is not clear in the grammar.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>As previously noted in clause A.1.2 Overview, (see <a href="http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html#Overview">http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html#Overview</a>), the first paragraph reads:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>“It is not possible to parse X3D files using a context-free grammar. Semantic knowledge of the names and types of fields (either built-in or user-defined using <b>PROTO</b> or <b>EXTERNPROTO</b>) shall be used during parsing so that the parser knows which field type is being parsed.”<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I agree with the first sentence. I disagree with the reason in the second sentence. Semantic knowledge of built-in nodes and fields could be incorporated into the grammar. It would make it very long. But it could be done. The only reason that parsing is not possible using a context-free grammar is the semantic knowledge of the names and types of fields from user-defined prototypes (using either <b>PROTO</b> or <b>EXTERNPROTO</b>).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Let me illustrate this with a grammar excerpt.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In my proposed grammar alternative, nodeTypeId still has the following production:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><i><span style='mso-fareast-language:EN-GB'>nodeTypeId </span></i><span style='mso-fareast-language:EN-GB'>::= <o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><i><span style='mso-fareast-language:EN-GB'>Id</span></i><span style='mso-fareast-language:EN-GB'> ; <o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>This production could be replaced as follows:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><i><span style='mso-fareast-language:EN-GB'>nodeTypeId </span></i><span style='mso-fareast-language:EN-GB'>::= <o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><b><span style='mso-fareast-language:EN-GB'>Anchor</span></b><b><span style='mso-fareast-language:EN-GB'> </span></b><span style='mso-fareast-language:EN-GB'>|<b><o:p></o:p></b></span></p><p class=MsoNormal style='margin-left:36.0pt'><b><span style='mso-fareast-language:EN-GB'>Appearance</span></b><b><span style='mso-fareast-language:EN-GB'> </span></b><span style='mso-fareast-language:EN-GB'>|<b><o:p></o:p></b></span></p><p class=MsoNormal style='margin-left:36.0pt'><b><span style='mso-fareast-language:EN-GB'>Arc2D</span></b><b><span style='mso-fareast-language:EN-GB'> </span></b><span style='mso-fareast-language:EN-GB'>|<b><o:p></o:p></b></span></p><p class=MsoNormal style='margin-left:36.0pt'><b><span style='mso-fareast-language:EN-GB'>….<o:p></o:p></span></b></p><p class=MsoNormal style='margin-left:36.0pt'><b><span style='mso-fareast-language:EN-GB'>VolumePickSensor</span></b><b><span style='mso-fareast-language:EN-GB'> </span></b><span style='mso-fareast-language:EN-GB'>|<b><o:p></o:p></b></span></p><p class=MsoNormal style='margin-left:36.0pt'><b><span style='mso-fareast-language:EN-GB'>WindPhysicsModel</span></b><b><span style='mso-fareast-language:EN-GB'> </span></b><span style='mso-fareast-language:EN-GB'>|<b><o:p></o:p></b></span></p><p class=MsoNormal style='margin-left:36.0pt'><b><span style='mso-fareast-language:EN-GB'>WorldInfo</span></b><b><span style='mso-fareast-language:EN-GB'> </span></b><span style='mso-fareast-language:EN-GB'>;<b><o:p></o:p></b></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Once the node type is known, so are the permitted fields and their types. So the grammar could be extended to cover each node type individually. Note that this approach has already been taken for four nodes (Script, ComposedShader, PackagedShader, and ShaderProgram). In fact, applying this approach to all built-in node types would make nodeTypeId redundant for built-in nodes.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thinking about this raised another question. Should the built-in node types be reserved keywords?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>For example, according to the current standard the following line is valid Classic VRML syntax:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal> DEF Anchor Anchor { }<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Should it be?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>All the best,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Roy<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='mso-fareast-language:EN-GB'>From:</span></b><span lang=EN-US style='mso-fareast-language:EN-GB'> x3d-public [mailto:x3d-public-bounces@web3d.org] <b>On Behalf Of </b>Roy Walmsley<br><b>Sent:</b> 19 July 2017 19:11<br><b>To:</b> 'X3D Graphics public mailing list' <x3d-public@web3d.org><br><b>Cc:</b> x3d@web3d.org<br><b>Subject:</b> Re: [x3d-public] [x3d] Spec Comment by brutzman on 19776-2: ClassicVRML Encoding - V3.3 [Mantis 1167]<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoPlainText>Hi,<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Having looked at the grammar relating to prototype instances I think it does not actually need modification. That said, however, I think clarity could be improved. I suggest the following.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>The current productions for the non-terminals proto and externproto are as follows:<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoNormal><i><span style='mso-fareast-language:EN-GB'>proto </span></i><span style='mso-fareast-language:EN-GB'>::= <o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><b><span style='mso-fareast-language:EN-GB'>PROTO</span></b><i><span style='mso-fareast-language:EN-GB'> nodeTypeId </span></i><b><span style='mso-fareast-language:EN-GB'>[</span></b><i><span style='mso-fareast-language:EN-GB'> interfaceDeclarations</span></i><b><span style='mso-fareast-language:EN-GB'> ] {</span></b><i><span style='mso-fareast-language:EN-GB'> protoBody </span></i><b><span style='mso-fareast-language:EN-GB'>}</span></b><span style='mso-fareast-language:EN-GB'> ; <o:p></o:p></span></p><p class=MsoNormal><i><span style='mso-fareast-language:EN-GB'>externproto </span></i><span style='mso-fareast-language:EN-GB'>::= <o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><b><span style='mso-fareast-language:EN-GB'>EXTERNPROTO</span></b><i><span style='mso-fareast-language:EN-GB'> nodeTypeId</span></i><b><span style='mso-fareast-language:EN-GB'> [</span></b><i><span style='mso-fareast-language:EN-GB'> externInterfaceDeclarations </span></i><b><span style='mso-fareast-language:EN-GB'>]</span></b><i><span style='mso-fareast-language:EN-GB'> URLList </span></i><span style='mso-fareast-language:EN-GB'>;<o:p></o:p></span></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>The non-terminal nodeTypeId is the same non-terminal that is used in the definition of the production for the non-terminal node:<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoNormal><i><span style='mso-fareast-language:EN-GB'>node </span></i><span style='mso-fareast-language:EN-GB'>::= <o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><i><span style='mso-fareast-language:EN-GB'>nodeTypeId </span></i><b><span style='mso-fareast-language:EN-GB'>{</span></b><span style='mso-fareast-language:EN-GB'> <i>nodeBody </i><b>}</b> | <o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><b><span style='mso-fareast-language:EN-GB'>Script {</span></b><i><span style='mso-fareast-language:EN-GB'> scriptBody </span></i><b><span style='mso-fareast-language:EN-GB'>}</span></b><span style='mso-fareast-language:EN-GB'> |<o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><b><i><span style='mso-fareast-language:EN-GB'>ComposedShader</span></i></b><span style='mso-fareast-language:EN-GB'> <b><i>{</i></b><i>composedShaderBody<b>}</b> |<br><b>PackagedShader</b> <b>{</b>packagedShaderBody<b>}</b> |<br><b>ShaderProgram</b> <b>{</b>shaderProgramBody<b>} </b>;</i> <o:p></o:p></span></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>I think this could be improved by introducing two additional non-terminals, namely protoInstance and protoNodeTypeId. Taking the latter first, this would align with nodeTypeId and have the following production:<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoNormal><i><span style='mso-fareast-language:EN-GB'>protoNodeTypeId </span></i><span style='mso-fareast-language:EN-GB'>::= <o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><i><span style='mso-fareast-language:EN-GB'>Id</span></i><span style='mso-fareast-language:EN-GB'> ; <o:p></o:p></span></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>The production for protoInstance, aligning with node, would be:<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoNormal><i><span style='mso-fareast-language:EN-GB'>protoInstance </span></i><span style='mso-fareast-language:EN-GB'>::= <o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><i><span style='mso-fareast-language:EN-GB'>protoNodeTypeId </span></i><b><span style='mso-fareast-language:EN-GB'>{</span></b><span style='mso-fareast-language:EN-GB'> <i>nodeBody </i><b>} </b>; <o:p></o:p></span></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>The productions for the non-terminals proto and externproto would then be amended to<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoNormal><i><span style='mso-fareast-language:EN-GB'>proto </span></i><span style='mso-fareast-language:EN-GB'>::= <o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><b><span style='mso-fareast-language:EN-GB'>PROTO</span></b><i><span style='mso-fareast-language:EN-GB'> protoNodeTypeId </span></i><b><span style='mso-fareast-language:EN-GB'>[</span></b><i><span style='mso-fareast-language:EN-GB'> interfaceDeclarations</span></i><b><span style='mso-fareast-language:EN-GB'> ] {</span></b><i><span style='mso-fareast-language:EN-GB'> protoBody </span></i><b><span style='mso-fareast-language:EN-GB'>}</span></b><span style='mso-fareast-language:EN-GB'> ; <o:p></o:p></span></p><p class=MsoNormal><i><span style='mso-fareast-language:EN-GB'>externproto </span></i><span style='mso-fareast-language:EN-GB'>::= <o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><b><span style='mso-fareast-language:EN-GB'>EXTERNPROTO</span></b><i><span style='mso-fareast-language:EN-GB'> protoNodeTypeId</span></i><b><span style='mso-fareast-language:EN-GB'> [</span></b><i><span style='mso-fareast-language:EN-GB'> externInterfaceDeclarations </span></i><b><span style='mso-fareast-language:EN-GB'>]</span></b><i><span style='mso-fareast-language:EN-GB'> URLList </span></i><span style='mso-fareast-language:EN-GB'>;<o:p></o:p></span></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Finally, the production for the non-terminal nodeStatement would be expanded to explicitly include protoInstance, as follows:<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoNormal><i><span style='mso-fareast-language:EN-GB'>nodeStatement </span></i><span style='mso-fareast-language:EN-GB'>::= <o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><i><span style='mso-fareast-language:EN-GB'>node</span></i><span style='mso-fareast-language:EN-GB'> | <o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><i><span style='mso-fareast-language:EN-GB'>protoInstance</span></i><span style='mso-fareast-language:EN-GB'> |<o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><b><span style='mso-fareast-language:EN-GB'>DEF </span></b><i><span style='mso-fareast-language:EN-GB'>nodeNameId node</span></i><span style='mso-fareast-language:EN-GB'> | <o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><b><span style='mso-fareast-language:EN-GB'>DEF</span></b><span style='mso-fareast-language:EN-GB'> <i>nodeNameId protoInstance </i>|<o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><b><span style='mso-fareast-language:EN-GB'>USE</span></b><i><span style='mso-fareast-language:EN-GB'> nodeNameId</span></i><span style='mso-fareast-language:EN-GB'> ;<o:p></o:p></span></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>This has the following advantages:<o:p></o:p></p><ol style='margin-top:0cm' start=1 type=1><li class=MsoNormal style='margin-left:0cm;mso-list:l1 level1 lfo3'>It allows text that states the non-terminal nodeTypeId can be the type of any of the built-in nodes defined in the abstract standard 19775-1. <o:p></o:p></li><li class=MsoNormal style='margin-left:0cm;mso-list:l1 level1 lfo3'>It allows text that states the non-terminal protoNodeTypeId is the type of any user defined prototype<o:p></o:p></li><li class=MsoNormal style='margin-left:0cm;mso-list:l1 level1 lfo3'>It clearly separates the built-in nodes from prototypes within the grammar.<o:p></o:p></li></ol><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>All the best,<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Roy<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><span lang=EN-US style='mso-fareast-language:EN-GB'>-----Original Message-----<br>From: x3d [<a href="mailto:x3d-bounces@web3d.org">mailto:x3d-bounces@web3d.org</a>] On Behalf Of Spec Feedback<br>Sent: 19 July 2017 17:59<br>To: <a href="mailto:x3d@web3d.org">x3d@web3d.org</a><br>Subject: [x3d] Spec Comment by brutzman on 19776-2: ClassicVRML Encoding - V3.3</span><o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>-- Submitter indicates that this comment may be public: *Yes* --<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Comment on 19776-2: ClassicVRML Encoding - V3.3 Annex A (normative) Grammar <a href="http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html"><span style='color:windowtext;text-decoration:none'>http://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/grammar.html</span></a><o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>-----------------<o:p></o:p></p><p class=MsoPlainText>Subject: need explicit definition of DEF and USE associated with prototype instances in ClassicVRML grammar<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>ClassicVRML formal grammar does not include explicit definition of DEF and USE associated with prototype instance statements.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>The current grammar seems to lean on prose definitions in section A.2 to augment rules in A.3. More is needed: better prose, additional rule(s), or both.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Email thread exploring this issue found at <a href="http://web3d.org/pipermail/x3d-public_web3d.org/2017-July/007155.html"><span style='color:windowtext;text-decoration:none'>http://web3d.org/pipermail/x3d-public_web3d.org/2017-July/007155.html</span></a><o:p></o:p></p><p class=MsoPlainText>(see second half)<o:p></o:p></p><p class=MsoPlainText>-----------------<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Submitted on Wednesday, 2017, July 19 - 9:59am by brutzman (brutzman )<o:p></o:p></p><p class=MsoPlainText>IP: 162.225.68.164<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>See: <a href="http://www.web3d.org/node/1694/submission/1396"><span style='color:windowtext;text-decoration:none'>http://www.web3d.org/node/1694/submission/1396</span></a><o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>_______________________________________________<o:p></o:p></p><p class=MsoPlainText>x3d mailing list<o:p></o:p></p><p class=MsoPlainText><a href="mailto:x3d@web3d.org"><span style='color:windowtext;text-decoration:none'>x3d@web3d.org</span></a><o:p></o:p></p><p class=MsoPlainText><a href="http://web3d.org/mailman/listinfo/x3d_web3d.org"><span style='color:windowtext;text-decoration:none'>http://web3d.org/mailman/listinfo/x3d_web3d.org</span></a><o:p></o:p></p></div></body></html>