<div dir="ltr"><div dir="ltr"><div>Am not trying to be convincing, rather am just listing why an X3D scene graph containing multiple nodes with the same value for DEF identifiers is a bad practice and typically invalid.</div><div><br></div><div>A related fact is that if an X3D scene graph has any node with two parents, then the graph is not a Directed Acyclic Graph (DAG) as required.</div><div><ul><li>Wikipedia Directed Acyclic Graph (DAG)</li><li><a href="https://en.wikipedia.org/wiki/Directed_acyclic_graph">https://en.wikipedia.org/wiki/Directed_acyclic_graph</a></li></ul><div>Permitting USE references before creating DEF nodes is a recent relaxation since X3D parsing speed is no longer a performance bottleneck.</div><div><br></div><div>These constraints are carefully chosen in X3D design. Programming languages can create many other variations that do not meet these important X3D Architecture requirements. Thus validation of results always remains useful, for each file encoding (XML, VRML, JSON, x3db) and programming language (JavaScript, Java, Python, others) that might be used to create an X3D model.</div></div><div><br></div><div>Hopefully this helps you and others when designing X3D models, by whatever means you choose.</div><div><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div style="color:rgb(34,34,34)"><font face="monospace">all the best, Don</font></div><div style="color:rgb(34,34,34)"><font face="monospace">-- </font></div><div style="color:rgb(34,34,34)"><font face="monospace">X3D Graphics, Maritime Robotics, Distributed Simulation</font></div><div style="color:rgb(34,34,34)"><font face="monospace">Relative Motion Consulting <a href="https://RelativeMotion.info" target="_blank">https://RelativeMotion.info</a></font></div></div></div></div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Apr 30, 2026 at 1:14 PM John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Thanks, Don, but you’re not convincing when both Michalis and Holger solve the same problem. I agree that they don’t export Java *from XML*.</div><div dir="auto"><br></div><div dir="auto">X3D model or scenegraph? This is really trying to fix USE before DEF in XML output or 2+ DEFs with the same value <span>in XML output. <b>It’s couched in terms of multiple DEFs, but there’s only one in the scene graph. The same ideas apply. I’m actually not creating multiple DEFs,</b> I’m using a variable reference to an instance in a Java in multiple parents node setters and adders. AFAIK, multiple references to a node with a DEF (or a DEF in a descendant) should be allowed in the scenegraph (not XML). I’m actually preventing duplication of a lot of data if a DEF is midway down the descendant hierarchy in the scenegraph, and the hierarchy is inserted twice.</span></div><div dir="auto"><span><br></span></div><div dir="auto"><span>From below: <b>“</b></span><span style="font-family:verdana,arial,helvetica,sans-serif;font-size:inherit"><b style="font-family:verdana,arial,helvetica,sans-serif">Instead, the same node is inserted into the scene graph a second time, resulting in the node having multiple parents”</b>. That’s exactly what addChild() does perfectly, except for containerField (containerField is an ancestor and is only in XML, but it might throw a wrench in my idea, clarification welcome). AFAIK, it’s perfectly fine to add a child more than one time with no DEF in the child’s descendants. So there’s some mysterious restriction that in some cases, you can’t call an addChild passing the same node twice.</span></div><div dir="auto"><span style="font-family:verdana,arial,helvetica,sans-serif;font-size:inherit"><br></span></div><div dir="auto"><span style="font-family:verdana,arial,helvetica,sans-serif;font-size:inherit">I think most of us would agree that the restriction should be lifted, and XML output should be fixed, according to Michalis’ method. Please talk to Michalis about how he does it in the castle model converter.</span></div><div dir="auto"><span style="font-family:verdana,arial,helvetica,sans-serif;font-size:inherit"><br></span></div><div dir="auto"><span style="font-family:verdana,arial,helvetica,sans-serif;font-size:inherit">There’s no need to put USE before DEF.</span></div><div dir="auto"><span style="font-family:verdana,arial,helvetica,sans-serif;font-size:inherit"><br></span></div><div dir="auto"><span style="font-family:verdana,arial,helvetica,sans-serif;font-size:inherit">From what I gather, <b style="font-family:verdana,arial,helvetica,sans-serif">this is a well known pattern in dealing with outputting DAGs in enterprise software and should not be considered problematic</b> (maybe patented? IDK. ThreadLocal should prevent threading issues). Even vectors are patented for real world purposes. See GeoVector.l</span></div><div dir="auto"><br></div><div dir="auto">I haven’t decided whether to eliminate the USE nodes in the scenegraph yet, but reread the quote above. Let’s deal with the cases where a DEF is halfway down a tree I have a reference to, and I want to create another reference to the tree. Are you saying I have to do a deep copy of the tree, and create a USE node halfway down?</div><div dir="auto"><br></div><div dir="auto">Think this through in Java or Pascal. Put the emphasis on how to serialize a DAG without creating duplicate subtrees by outputting USE instead of a whole tree.</div><div dir="auto"><br></div><div dir="auto">But yeah, solving according to author intent would be cool too, just much harder, I would say.</div><div dir="auto"><br></div><div dir="auto">Since the USE is created in XML in any case, there will be no issue converting that to Java. X3dToJava.xslt, etc. can remain the same. I’m fairly sure we can keep setUSE() as is.</div><div dir="auto"><br></div><div dir="auto">The main reason not to do this is to allow XML snippets. Create an output function that initializes the DEF table , serializes a node, and clears the table </div><div dir="auto"><br></div><div dir="auto">You seem to always avoid the quote above when it’s brought up. Why? You even probably quoted it on purpose?</div><div dir="auto"><br></div><div dir="auto">Please be use a more precise term than model. I am referring to scenegraphs in memory or CPU cache, not something in a file on disk.</div><div dir="auto"><br></div><div dir="auto">Note that the code I shared only works when there’s only one DEF value for a single node and follows the quote when dealing with USE nodes. If you’re not following the quote, the code will’s change slightly, but you’ll get the idea if you look at it. And the ThreadLocal Stack for name scoping.</div><div dir="auto"><br></div><div dir="auto">If desired, I can create examples instead of emailing. Say the word.</div><div dir="auto"><br></div><div dir="auto">Is the quote wrong and not what X3DJSAIL does?</div><div dir="auto"><br></div><div dir="auto">But, yeah, adding a few lines of Java is to a stylesheet is harder than changing a standard?</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto"><br></div><div dir="auto">John<br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, Apr 30, 2026 at 1:05 PM Don Brutzman <<a href="mailto:don.brutzman@gmail.com" target="_blank">don.brutzman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Multiple duplicate DEF names in a single X3D model is a bad practice, for multiple reasons.</div><div><br></div><div dir="auto">I've updated Scene Authoring Hints accordingly, see highlighted text which follows plus additional references. Hope this helps.</div><div><ul><li>X3D Scene Authoring Hints: Naming Conventions</li><li><a href="https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#NamingConventions" target="_blank">https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#NamingConventions</a></li></ul><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><h3 style="font-family:"Times New Roman";color:rgb(0,0,0)"><font size="2" style="font-family:"Times New Roman";color:rgb(0,0,0)"><a href="https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#NamingConventions" style="font-family:"Times New Roman"" target="_blank">🔖</a> <u style="font-family:"Times New Roman""><a id="m_-2563442855548187273m_-6663236019683028423gmail-NamingConventions" style="font-family:"Times New Roman"">Naming Conventions</a></u></font></h3><p style="font-family:"Times New Roman";color:rgb(0,0,0)">Models are simple representations for some part of reality. Simulations show the behavior of models over time.</p><ol type="a" style="font-family:"Times New Roman";color:rgb(0,0,0)"><li style="font-family:"Times New Roman"">Clarity is essential when naming components to design a meaningful model.</li><li style="font-family:"Times New Roman"">Names matter, suggesting how to think about purpose and relationships.</li><li style="font-family:"Times New Roman"">These naming conventions are suitable for X3D scenes, XML tagset design, accompanying HTML pages, and corresponding source code written JavaScript/Java/Python/etc.</li><li style="font-family:"Times New Roman"">These naming conventions also match the node and field naming conventions found in the <a href="https://www.web3d.org/x3d/progress" style="font-family:"Times New Roman"" target="_blank">X3D Standards</a> themselves (and elsewhere).</li><li style="font-family:"Times New Roman"">Success Metric: when is a name successful?<br>(Ironic) Answer: when no one has to discuss that name any more, it is simply understood.</li></ol><p style="font-family:"Times New Roman";color:rgb(0,0,0)">Naming conventions are appropriate for file names, DEF node identifiers and USE node references, prototype names, unique IDs, and more.</p><p style="font-family:"Times New Roman";color:rgb(0,0,0)">Here is a combined set of guidelines.</p><ol style="font-family:"Times New Roman";color:rgb(0,0,0)"><li style="font-family:"Times New Roman"">Using clear and consistent names for node names and DEF labels greatly improves the clarity of how a scene works.</li><li style="font-family:"Times New Roman"">In effect, descriptive names can make the purpose and mechanics of a scene self-documenting.</li><li style="font-family:"Times New Roman""><span style="font-family:"Times New Roman";background-color:rgb(255,242,204)">Avoid <a href="https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#DuplicateDEF" style="font-family:"Times New Roman"" target="_blank">duplicate DEF</a> identifier naming as a bad practice</span>, even when identical names might seem reasonable when declaring a prototype in a model. The resulting model will fail XML validation, fail semantic query, and not make sense due to unclear definitions. Bookmarks in X3D Documentation pages will also fail since duplicate paragraph anchors will be present.</li></ol></blockquote><div><span style="font-family:"Times New Roman";color:rgb(0,0,0)">[...]</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><a href="https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#ProtoDeclare" style="font-family:"Times New Roman";font-size:medium" target="_blank">🔖</a><span style="font-family:"Times New Roman";font-size:medium;color:rgb(0,0,0)"> </span><b style="font-family:"Times New Roman";color:rgb(0,0,0)"><a id="m_-2563442855548187273m_-6663236019683028423gmail-ProtoDeclare" style="font-family:"Times New Roman"">Prototype Declarations</a></b><span style="font-family:"Times New Roman";color:rgb(0,0,0)"> define a template for a new node</span><ul style="font-family:"Times New Roman";color:rgb(0,0,0)"><li style="font-family:"Times New Roman"">Follow <a href="https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#NamingConventions" style="font-family:"Times New Roman"" target="_blank">Naming Conventions</a> for node and <a href="https://www.web3d.org/x3d/content/X3dTooltips.html#field" style="font-family:"Times New Roman"" target="_blank">field</a> definitions.</li><li style="font-family:"Times New Roman"">Provide useful/safe default initialization values for each field, rather than depending on default field values internal to the <code style="font-family:monospace">ProtoBody</code>.</li><li style="font-family:"Times New Roman"">Include annotation tooltips for each field.</li><li style="font-family:"Times New Roman"">Avoid copying <code style="font-family:monospace">ProtoDeclare</code> definitions into additional scenes, instead copy <code style="font-family:monospace">ExternProtoDeclare</code>/<code style="font-family:monospace">ProtoInstance</code> definitions.</li><li style="font-family:"Times New Roman"">Tooltips for <a href="https://www.web3d.org/x3d/content/X3dTooltips.html#ProtoDeclare" style="font-family:"Times New Roman"" target="_blank"><code style="font-family:monospace">ProtoDeclare</code></a>, <a href="https://www.web3d.org/x3d/content/X3dTooltips.html#ProtoInterface" style="font-family:"Times New Roman"" target="_blank"><code style="font-family:monospace">ProtoInterface</code></a> and <a href="https://www.web3d.org/x3d/content/X3dTooltips.html#ProtoBody" style="font-family:"Times New Roman"" target="_blank"><code style="font-family:monospace">ProtoBody</code></a></li><li style="font-family:"Times New Roman""><a id="m_-2563442855548187273m_-6663236019683028423gmail-DuplicateDEF" style="font-family:"Times New Roman""></a>Avoid <span style="font-family:"Times New Roman";background-color:rgb(255,242,204)">duplicate DEF names </span>for nodes inside multiple prototype declarations contained in a single file. Although the DEF namespaces contained inside each independent ProtoBody declaration are logically independent from an X3D perspective, duplicate DEF names will provoke XML validation errors regarding duplicate ID names. They can also easily lead to author confusion, providing semantic ambiguity both notionally and if performing Semantic Web Queries in Turtle.</li><li style="font-family:"Times New Roman"">X3D Specification clause: <a href="https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#PrototypeSemantics" style="font-family:"Times New Roman"" target="_blank">Prototype Semantic</a></li></ul></blockquote><div>Further discussion can also be found in</div><div><ul><li><i><a href="https://x3dgraphics.com/" target="_blank">X3D: Extensible 3D Graphics for Web Authors</a>,</i> Don Brutzman and Leonard Daly, Morgan Kaufmann Publishers, Elsevier, 2007</li><li><a href="https://x3dgraphics.com" target="_blank">https://x3dgraphics.com</a></li><li>Chapter 3 Grouping Nodes, 2. Concepts, 1.4 DEF and USE (pp 71-72)</li></ul><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">2.4. DEF and USE<br>DEF and USE names are the X3D mechanism for efficiently defining and copying a<br>node, multiple nodes, or even groups of nodes. Copied nodes require far less memory<br>and computation because they need only be created once. This efficiency can greatly<br>improve rendering performance when extensively used in large scenes.<br>When a node is given a DEF name, that name is an identification label that is unique<br>in the file. The DEF name must start with a letter and can contain letters, numbers, and<br>the special characters underscore, hyphen, and period. DEF names must not include<br>whitespace or other special characters. Uppercase and lowercase alphabetic characters<br>are considered strictly different; therefore, DEF names are case sensitive.<br>USE names refer back to a node with a DEF name. These references allow faster and<br>more efficient rendering of graphics objects. Note that the actual DEF node name definition<br>must be located in the scene graph before any USE references. This permits X3D<br>browsers to read and load a scene graph in a single pass, avoiding undefined references<br>and thereby yielding faster parsing and loading. This performance boost not only helps<br>when users first load a scene, but is also valuable when further subscenes are loaded<br>within a parent scene. Authors also must be careful with animation of the fields of a DEF<br>node, because this will equally affect all of the USE copies.<br>When authoring large scenes, using descriptive DEF names improves clarity and<br>helps document a model. CamelCaseNaming is a good way to accomplish this: capitalize<br>each word, never use abbreviations, strive for clarity, and be brief but complete.<br>Avoiding underscore characters improves readability, because pretty-print HTML versions<br>of scenes usually hyperlink these names, and underlined hyperlinks hide</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> underscore characters from the user. ROUTE statements that connect one node’s field to</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">another node’s field are much more understandable when the purpose and type of the<br>node are evident in the DEF names themselves. Examples provided with this book strive<br>to provide useful examples of good naming practices. ROUTE connections are covered<br>in Chapter 7, Event Animation and Interpolation.<br>A good rule of thumb is that a proper DEF name can be sensibly used in a sentence.<br>For example, “The fraction_changed field of the SpinningBoxClock TimeSensor node<br>is ROUTED to the set_fraction field of the SpinningBoxInterpolator node.” Although<br>a bit long winded, such sentences provide a clear and sensible explanation for a given<br>behavior.</blockquote></div><div><br></div><div>Authoritative reference is always X3D Architecture.</div><div><ul><li>X3D Architecture v4.1 draft, clause 4 Concepts, 4.4.3 DEF/USE semantics</li><li><a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/concepts.html#DEF_USE_Semantics" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/concepts.html#DEF_USE_Semantics</a></li></ul><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><h2 style="margin-top:18px;font-family:Verdana,Arial,Helvetica,sans-serif;color:rgb(0,0,0)"><span title="Mantis 1526" style="font-family:Verdana,Arial,Helvetica,sans-serif;background-color:yellow"><font size="2" style="font-family:Verdana,Arial,Helvetica,sans-serif;color:rgb(0,0,0)">4.4.3 DEF/USE semantics</font></span></h2><p style="font-family:Verdana,Arial,Helvetica,sans-serif;color:rgb(0,0,0)">Node DEF names are limited in scope to a single X3D file, prototype definition, or string submitted to either CreateX3DFromString, CreateX3DFromStream, or CreateX3DFromURL X3D browser service (as specified in <a href="https://www.web3d.org/specifications/X3Dv4Draft/references.html#I19775_2" style="font-family:Verdana,Arial,Helvetica,sans-serif" target="_blank">ISO/IEC 19775-2</a>).</p><p style="font-family:Verdana,Arial,Helvetica,sans-serif;color:rgb(0,0,0)">The USE statement does not create a copy of the node identified by a DEF name. Instead, the same node is inserted into the scene graph a second time, resulting in the node having multiple parents (see <a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/concepts.html#TransformationHierarchy" style="font-family:Verdana,Arial,Helvetica,sans-serif" target="_blank">4.3.5 Transformation hierarchy</a>, for restrictions on self-referential nodes).</p><p style="font-family:Verdana,Arial,Helvetica,sans-serif;color:rgb(0,0,0)">Node names shall be unique in the context within which the associated DEF name occurs. <span title="editorial, Mantis 1526" style="font-family:Verdana,Arial,Helvetica,sans-serif;background-color:yellow">Any USE node reference without a corresponding DEF, within the scope of the current scene or prototype declaration, is an error.</span></p><p style="margin-top:18px;margin-bottom:18px;font-family:univers,arial,sans-serif;color:rgb(0,0,0)"><span title="ensure consistent implementations, Mantis 1526" style="font-family:univers,arial,sans-serif;background-color:yellow">NOTE DEF names are not required to precede USE references.</span></p></blockquote></div><div>Have fun building understandable models with X3D! 😁 👍</div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">all the best, Don</span></div></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div style="color:rgb(34,34,34)"><font face="monospace" style="font-family:monospace;color:rgb(34,34,34)">-- </font></div><div style="color:rgb(34,34,34)"><font face="monospace" style="font-family:monospace;color:rgb(34,34,34)">X3D Graphics, Maritime Robotics, Distributed Simulation</font></div><div style="color:rgb(34,34,34)"><font face="monospace" style="font-family:monospace;color:rgb(34,34,34)">Relative Motion Consulting <a href="https://RelativeMotion.info" style="font-family:monospace" target="_blank">https://RelativeMotion.info</a></font></div></div></div></div><br></div><br><div class="gmail_quote"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 30, 2026 at 3:25 AM John Carlson via x3d-public <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-size:inherit" dir="auto">Summary: to employ multiple DEFs with same value, employ a table per name scope of DEF information in per Java thread java.lang.ThreadLocal memory for encoded output with one DEF per DEF/USE value. See bolded table description below.</div><div style="font-size:inherit" dir="auto"><br></div><div style="font-size:inherit" dir="auto">Feel free to forward.</div><div style="font-size:inherit" dir="auto"><br></div><div style="font-size:inherit" dir="auto">Is many DEFs with same value for<span style="font-size:inherit"> a scenegraph node being considered in discussions? Say I want to addChild() the same Shape node several times to different Transforms</span><span style="font-size:inherit">, and the Shape node or descendants have DEFs in them. In X3DJ</span><span style="font-size:inherit">SAIL, of course. </span><span style="font-size:inherit">This is easily done in an SAI binding like X3DJSAIL, just use the same variable passed to several addChild() methods.</span></div><div style="font-size:inherit" dir="auto"><span style="font-size:inherit"></span></div><div style="font-size:inherit" dir="auto"><br></div><div style="font-size:inherit" dir="auto">If it is allowed, what comes out in XML? I am hoping one leading DEF and several USEs for backwards compatibility. I think Castle has shown that this is doable.</div><div style="font-size:inherit" dir="auto"><br></div><div style="font-size:inherit" dir="auto">I am not saying VRML, XML, DOM, or HTML should have multiple parents of a child node. If a browser wants to implement a proxy when a DEF/USE appears more than once, they should be free to do that. (Hint: JavaScript’s Proxy class.) Maybe each mention of a DEF value (second or following) or USE value (any natural number of them) should create a Proxy on setting or adding?</div><div style="font-size:inherit" dir="auto"><br></div><div style="font-size:inherit" dir="auto">I do think the encodings are doing the right thing, no changes there. How can we achieve that output and support multiple parents (references or proxies to children) in X3DJSAIL with one DEF node per DEF value <span style="font-size:inherit">output?</span></div><div style="font-size:inherit" dir="auto"><br></div><div style="font-size:inherit" dir="auto">I’m particularly wondering for X3DJSAIL.</div><div style="font-size:inherit" dir="auto"><br></div><div style="font-size:inherit" dir="auto">Do we need proxies, or will table(s) also solve the issue of multiple DEFs, and replace all but the first with USE on output<span style="font-size:inherit">? Also perhaps assuming there’s a DEF table per name scope. How does X3DJSAIL support name scopes? (I’m clueless, currently). <b>I’m imagining a table with DEF_value, DEF_found, reference_count, DEF_nodes and USE_nodes columns. Maybe a name_scope and node_type_name as well.</b> These table(s) would be initialized when output begins potentially when a name scope is entered, and filled out as the XML is created. Multiple threads? The table can be stored in ThreadLocal memory. Bingo, if it’s still a thing.</span></div><div style="font-size:inherit" dir="auto"><span style="font-size:inherit"><br></span></div><div style="font-size:inherit" dir="auto"><span style="font-size:inherit">Please let me know if such a thing is already available.</span></div><div style="font-size:inherit" dir="auto"><span style="font-size:inherit"><br></span></div><div style="font-size:inherit" dir="auto"><span style="font-size:inherit">Someone else can solve for X3DPSAIL?</span></div><div style="font-size:inherit" dir="auto"><span style="font-size:inherit"><br></span></div><div style="font-size:inherit" dir="auto">Will this also handle USE before DEF?</div><div style="font-size:inherit" dir="auto"><br></div><div style="font-size:inherit" dir="auto">John</div></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div>
</blockquote></div></div>
</blockquote></div></div>