<div dir="auto"><div>Thanks much for the review and revision effort.</div><div dir="auto"><br></div><div dir="auto">The recursive case brings up circular dependencies. Proto A may use an instance of Proto B, but Proto B in turn may use an instance of Proto A unless some initial condition occurs, so that in theory a result can be resolved.</div><div dir="auto"><br></div><div dir="auto">The recursive clause in a way covers this in my view but perhaps circular definitions could be made explicitly illegal.</div><div dir="auto"><br></div><div dir="auto">Just a thought,</div><div dir="auto"><br></div><div dir="auto">Andreas</div><div dir="auto"><br><div data-smartmail="gmail_signature" dir="auto">---on the phone---</div><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, Apr 28, 2022, 8:45 PM Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word"><div class="m_2634123305886060252WordSection1"><p class="MsoNormal">We reviewed closely.  Prose definitions are correct.  Slight editorial changes (essentially re-ordering sentences) hopefully make things clearer.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><ul style="margin-top:0in" type="disc"><li class="m_2634123305886060252MsoListParagraph" style="margin-left:0in">Mantis 1395: improve clarity of prototype scoping rules<u></u><u></u></li><li class="m_2634123305886060252MsoListParagraph" style="margin-left:0in"><a href="https://www.web3d.org/member-only/mantis/view.php?id=1395" target="_blank" rel="noreferrer">https://www.web3d.org/member-only/mantis/view.php?id=1395</a><u></u><u></u></li></ul><ul style="margin-top:0in" type="disc"><li class="m_2634123305886060252MsoListParagraph" style="margin-left:0in">- <u></u><u></u></li></ul><ul style="margin-top:0in" type="disc"><li class="m_2634123305886060252MsoListParagraph" style="margin-left:0in">4.4.4.4 Prototype scoping rules<u></u><u></u></li><li class="m_2634123305886060252MsoListParagraph" style="margin-left:0in"><a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/concepts.html#Prototypescopingrules" target="_blank" rel="noreferrer">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/concepts.html#Prototypescopingrules</a><u></u><u></u></li></ul><ul style="margin-top:0in" type="disc"><li class="m_2634123305886060252MsoListParagraph" style="margin-left:0in">-<u></u><u></u></li></ul><p class="MsoNormal" style="margin-left:.25in"><span class="m_2634123305886060252proposed">A prototype may be instantiated in a file anywhere after the completion of the prototype definition.</span> Prototype definitions appearing inside a prototype definition (<i>i.e.</i>, nested) <span class="m_2634123305886060252proposed">have scope</span> local to the enclosing prototype. IS statements inside a nested prototype's implementation may refer to the prototype declarations of the innermost prototype. <span class="m_2634123305886060252proposed">A prototype may not be instantiated inside its own implementation <i>(i.e.</i>, recursive prototypes are illegal).</span> <u></u><u></u></p><p class="MsoNormal" style="margin-left:.25in"><u></u> <u></u></p><p class="MsoNormal" style="margin-left:.25in">A PROTO statement establishes a DEF/USE name scope separate from the rest of the scene and separate from any nested PROTO statements. Nodes given a name by a DEF construct inside the prototype may not be referenced in a USE construct outside of the prototype's scope. Nodes given a name by a DEF construct outside the prototype scope may not be referenced in a USE construct inside the prototype scope.<u></u><u></u></p><ul style="margin-top:0in" type="disc"><li class="m_2634123305886060252MsoListParagraph" style="margin-left:0in">- <u></u><u></u></li></ul><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Again thanks for all efforts to make the X3D4 specification clear and consistently repeatable.<u></u><u></u></p><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">all the best, Don<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">-- <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">Don Brutzman  Naval Postgraduate School, Code USW/Br        <a href="mailto:brutzman@nps.edu" target="_blank" rel="noreferrer">brutzman@nps.edu</a><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA    +1.831.656.2149<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">X3D graphics, virtual worlds, Navy robotics https://</span> <span style="font-size:10.0pt;font-family:"Courier New""><a href="http://faculty.nps.edu/brutzman" target="_blank" rel="noreferrer">faculty.nps.edu/brutzman</a><u></u><u></u></span></p></div><p class="MsoNormal"><u></u> <u></u></p><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b>From:</b> Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu" target="_blank" rel="noreferrer">brutzman@nps.edu</a>> <br><b>Sent:</b> Wednesday, April 27, 2022 9:23 PM<br><b>To:</b> GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank" rel="noreferrer">gpugroup@gmail.com</a>>; Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank" rel="noreferrer">andreasplesch@gmail.com</a>>; Richard F. Puk (<a href="mailto:puk@igraphics.com" target="_blank" rel="noreferrer">puk@igraphics.com</a>) <<a href="mailto:puk@igraphics.com" target="_blank" rel="noreferrer">puk@igraphics.com</a>><br><b>Cc:</b> X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank" rel="noreferrer">x3d-public@web3d.org</a>>; Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu" target="_blank" rel="noreferrer">brutzman@nps.edu</a>><br><b>Subject:</b> RE: [x3d-public] ProtoBody completeness in nested Protos<u></u><u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Thanks for your precision and thoroughness Doug.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Seems clear and unambiguous that it is scoped, as previously described.  We’ll double check on phraseology.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Dick can we please discuss in tomorrow’s meeting, TIA.<u></u><u></u></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">all the best, Don<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">-- <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">Don Brutzman  Naval Postgraduate School, Code USW/Br        <a href="mailto:brutzman@nps.edu" target="_blank" rel="noreferrer">brutzman@nps.edu</a><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA    +1.831.656.2149<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">X3D graphics, virtual worlds, Navy robotics https://</span> <span style="font-size:10.0pt;font-family:"Courier New""><a href="http://faculty.nps.edu/brutzman" target="_blank" rel="noreferrer">faculty.nps.edu/brutzman</a><u></u><u></u></span></p><p class="MsoNormal"><u></u> <u></u></p><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b>From:</b> x3d-public <<a href="mailto:x3d-public-bounces@web3d.org" target="_blank" rel="noreferrer">x3d-public-bounces@web3d.org</a>> <b>On Behalf Of </b>GPU Group<br><b>Sent:</b> Tuesday, April 26, 2022 9:57 AM<br><b>To:</b> X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank" rel="noreferrer">x3d-public@web3d.org</a>><br><b>Subject:</b> Re: [x3d-public] ProtoBody completeness in nested Protos<u></u><u></u></p></div><p class="MsoNormal"><u></u> <u></u></p><div><div><div><div><div><p class="MsoNormal"><a href="https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/concepts.html#Prototypescopingrules" target="_blank" rel="noreferrer">https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/concepts.html#Prototypescopingrules</a><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">"A prototype may be instantiated in a file anywhere after the completion of the prototype definition."<u></u><u></u></p></div><div><div><p class="MsoNormal">If the specs meant what you are suggesting --protos are self contained including proto definitions-- then it would have said "context" rather than "file"<u></u><u></u></p></div></div><div><div><p class="MsoNormal">"Prototype definitions appearing inside a prototype definition ( i.e., nested) are local to the enclosing prototype. "<u></u><u></u></p></div><div><p class="MsoNormal">- refinement of the above file order rule.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Tue, Apr 26, 2022 at 9:51 AM GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank" rel="noreferrer">gpugroup@gmail.com</a>> wrote:<u></u><u></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt"><div><div><p class="MsoNormal">"I really do<br>not think that proto declarations should be required to inherit<br>existing declarations from parent execution contexts"<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">If C++ required each class definition to be self-contained --to redefine all the types it depends on-- it would be a very messy and onerous system. If you want a system that can build up types - types on top of types to make more complex types - then you need a way for a type to use previously defined types.<u></u><u></u></p></div><div><p class="MsoNormal">In x3d -a prototyping language- that looks like a new type being able to use a type defined previously in the file. Extern ProtoDeclares are stored in scene files as ProtoDeclares. As such they should be able to use type defined previously in their host file.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Tue, Apr 26, 2022 at 9:37 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank" rel="noreferrer">andreasplesch@gmail.com</a>> wrote:<u></u><u></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt"><p class="MsoNormal">> Date: Tue, 26 Apr 2022 07:56:47 -0600<br>> From: GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank" rel="noreferrer">gpugroup@gmail.com</a>><br>> To: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank" rel="noreferrer">x3d-public@web3d.org</a>><br><br>> When I started with freewrl around 2009, it had a text-based system for<br>> protos:<br>> - when parsing a scene, if it found a proto declare, it would scrape the<br>> text into a buffer. Then as it continued parsing, when it hit a proto<br>> instance it pasted, and continued parsing over the pasted text as though it<br>> had been there all along. Extern protos similar, it would pause parsing, go<br>> to the file referenced, look for the proto declare by name, and scrape out<br>> the text of the ProtoDeclare, for pasting in-scene.<br>> And it worked a bit. But especially extern protos weren't working reliably.<br>> As a casual volunteer I decided to fix the bugs. How hard could it be? A<br>> little debugging and presto, I'd be a hero. As I got into it and saw more<br>> scene failure examples there were several emotional stages like grieving<br>> denial, shock, sadness, resistance etc. And a slow dawning realization the<br>> whole system needed a rework.<br>> And I didn't have support from others -just silence, perhaps they knew it<br>> was a mess and wanted to stay clear.<br>> It was a sickening feeling, and I needed to think for a few weeks whether I<br>> even wanted to be a volunteer programmer if the system was rotten from the<br>> core.<br>> So it can not only be a monster task, but precisely because it's a monster<br>> there's little support for those brave enough to tackle it.<br>> (After a few weeks I got to the Acceptance stage of grieving, and spent 6<br>> months of hobby time building the new proto system).<br><br>Thanks for the story, and for engaging. To me, I became interested<br>when I realized that x3dom is probably flexible enough to allow for<br>parameterized definition and registration of new nodes dynamically<br>which behave then exactly like native nodes. This is different from<br>filling in templates. For example, there is no performance penalty<br>during tree traversal and it enables instancing using xml nodes with<br>the new names, just as in x3dv.<br><br>I am pretty happy with how it came out. An additional complication is<br>asynchronous loading of remote resources which is standard on the web.<br>X3D should rely less on how nodes or statements are ordered in a<br>scene.<br><br>It is just frustrating that there are ill defined corners. I really do<br>not think that proto declarations should be required to inherit<br>existing declarations from parent execution contexts ( DEF/USE name<br>scopes are different but there is still a separated execution context<br>). That means the protos array of a new execution context should be<br>empty initially. The SAI spec. actually says so.<br><br>Best, Andreas<br><br>_______________________________________________<br>x3d-public mailing list<br><a href="mailto:x3d-public@web3d.org" target="_blank" rel="noreferrer">x3d-public@web3d.org</a><br><a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank" rel="noreferrer">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><u></u><u></u></p></blockquote></div></blockquote></div></div></div></blockquote></div></div></div>