<div dir="auto">Luckily, I have a lot of Python code which uses X3DPSAIL which might be used for a starting sample code for an X3dToPython.xslt rewrite, which could be rewritten to use variables instead of USE= parameters.</div><div dir="auto"><br></div><div dir="auto"><div style="font-size:inherit"><a href="https://github.com/coderextreme/X3DJSONLD/tree/master/src/main/python/net/coderextreme/data" style="font-size:inherit">https://github.com/coderextreme/X3DJSONLD/tree/master/src/main/python/net/coderextreme/data</a></div><div style="font-size:inherit" dir="auto"><br></div><div style="font-size:inherit" dir="auto">I can likely create something for the whole archive.</div><br></div><div dir="auto">But my code itself uses USE= because I want VRML and XML to have USE, a limitation of X3DPSAIL.  X3DPSAIL could track when a DEF is output, and output USE after the first DEF when a variable/object/node is reused in a SFNode or MFNode.  The containing node would know what containerField or container field to use.</div><div dir="auto"><br></div><div dir="auto"><div style="font-size:inherit"></div></div><div dir="auto">If only someone had paid attention all the times people talked about DEF/USE.</div><div dir="auto"><br></div><div dir="auto">I’m thinking Vince may be working on something though.  X3DPSAIL 5.0?</div><div dir="auto"><br></div><div dir="auto">Anyway, so much for X3D being a directed acyclic graph.  I recognize it would be very easy to construct a cyclic graph using my style of programming, and I guess we don’t want graphics systems to do that.</div><div dir="auto"><br></div><div dir="auto">Note, if you want setters and adders to return this in SAI 4.0 C++, so hierarchical coding is possible, I suggest having Myeong start work on that.   And provide a standards annexes that are actually compilable would be great.  And X3D JSON needs a schema?</div><div dir="auto"><br></div><div dir="auto">If anyone is interested in applications involving cyclic graphs, like file systems, organizational hierarchies, and the like, we can discuss.  Of course, the hyperlinks create cyclic graphs, and those are handled by X3D.  I imagine something similar.  I realize they are not great when garbage collection is used.  Often links are persistent, though.  If we’re going to have RenderedTexture…</div><div dir="auto"><br></div><div dir="auto">Yes, I understand that directed acyclic graphs and cyclic graphs are turned into trees to simplify memory management.   The object to DEF value map has the information you need to do the memory management, on directed graphs, AFAIK.</div><div dir="auto"><br></div><div dir="auto">A binding is more capable than an encoding.</div><div dir="auto"><br></div><div dir="auto">Says the guy who built information systems user interfaces.</div><div dir="auto"><br></div><div dir="auto">Obviously, at this point,  no one is paying attention.  I realize my social skills suck.</div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Mar 27, 2026 at 9:01 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-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="auto"><span>In X3DJSAIL, why do we use different objects for calling setUSE() and setDEF() of the same DEF value</span><span>?  Should setUSE(“foo”) be disallowed after a setDEF(“foo”)?</span><br></div><div dir="auto"><br></div><div dir="auto">Think about it.  I personally would just remove setUSE(), since it violates the specification, apparently.  setUSE should only be used to specify multiple parents.  We have add… and set… which should already do that.</div><div dir="auto"><br></div><div dir="auto">This also has massive implications for X3dToJava.xslt and X3dToPython.xslt as well.</div><div dir="auto"><br></div><div dir="auto">If we hadn’t fallen into using a hierarchy for Java and Python generated code, this would have been extremely simple…</div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 27, 2026 at 8:22 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-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><div>It is not possible to avoid USE, it is fully integrated functionality in the specification.  No need to reengineer the specification.</div><div><br></div><div>Again recommend working on one very simple case at a time, to narrow down each problem and fix it.  Complexity obscures diagnosis.</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="color:rgb(34,34,34)"><font face="monospace" style="font-family:monospace;color:rgb(34,34,34)"><br></font></div><div style="color:rgb(34,34,34)"><font face="monospace" style="font-family:monospace;color:rgb(34,34,34)">all the best, Don</font></div><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" target="_blank" style="font-family:monospace">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 Fri, Mar 27, 2026 at 6:08 PM 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-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Replacing USE with DEF would massively improve the JSON schema.   I vote for that!   It would massively improve the error reporting as well.<div dir="auto"><br></div><div dir="auto">What does FreeWRL think?</div><div dir="auto"><br></div><div dir="auto">No need for two attributes for the same meaning.</div><div dir="auto"><br></div><div dir="auto">USE and DEF code be used interchangeably, and container fields could specify parents.</div><div dir="auto"><br></div><div dir="auto">The only problem I see is when USE and DEF are used together, but that’s already an issue.</div><div dir="auto"><br></div><div dir="auto">John</div></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
_______________________________________________<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>