<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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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 */
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
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.proposed
{mso-style-name:proposed;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:733626287;
mso-list-type:hybrid;
mso-list-template-ids:130156144 -1380837644 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:4;
mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1
{mso-list-id:1315837647;
mso-list-type:hybrid;
mso-list-template-ids:326414094 352866914 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-start-at:4;
mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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-US link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoPlainText>Good catch about circular definitions getting disallowed Andreas. Besides bad practice and illogical, it is also a security vulnerability.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>We have such a statement for Inline nodes.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><ul style='margin-top:0in' type=disc><li class=MsoPlainText style='mso-list:l0 level1 lfo2'>X3D4 Architecture, clause 9 Networking component, 9.4.2 Inline<o:p></o:p></li><li class=MsoPlainText style='mso-list:l0 level1 lfo2'>https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/networking.html#Inline<o:p></o:p></li></ul><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>"Security precaution: it is an error for a model to Inline itself, directly or indirectly, in order to avoid nonterminating recursion loops. X3D players browsers SHALL NOT honor self-referential loading of model loops in order to avoid security vulnerabilities."<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Now checking prototypes... There is one simpler statement found as follows, added by Mantis 1395.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>“<span class=proposed>A prototype may not be instantiated inside its own implementation <i>(i.e.</i>, recursive prototypes are illegal).”</span><o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><ul style='margin-top:0in' type=disc><li class=MsoPlainText style='mso-list:l1 level1 lfo1'>X3D4 Architecture, clause 4 Concepts, 4.4.4.4 Prototype scoping rules<o:p></o:p></li><li class=MsoPlainText style='mso-list:l1 level1 lfo1'>https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/concepts.html#PROTOdefinitionsemantics<o:p></o:p></li></ul><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>This is such an important point that I think we should repeat a similar Security precaution, proposed as follows.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><ul style='margin-top:0in' type=disc><li class=MsoPlainText style='mso-list:l1 level1 lfo1'>X3D4 Architecture, clause 4 Concepts, 4.4.4.3 PROTO definition semantics<o:p></o:p></li><li class=MsoPlainText style='mso-list:l1 level1 lfo1'>https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/concepts.html#PROTOdefinitionsemantics<o:p></o:p></li></ul><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>"<span style='background:yellow;mso-highlight:yellow'>Security precaution: it is an error for a prototype to reference an instance or repeated declaration of itself, directly or indirectly, in order to avoid nonterminating recursion loops. This error might occur with either local or external (PROTO or EXTERNPROTO) declarations. X3D players browsers SHALL NOT honor self-referential loading of prototype declaration loops in order to avoid security vulnerabilities</span>."<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Have re-opened Mantis 1395 and applied this proposed change. As ever, review and feedback welcome.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>all the best, Don<o:p></o:p></p><p class=MsoPlainText>-- <o:p></o:p></p><p class=MsoPlainText>Don Brutzman Naval Postgraduate School, Code USW/Br brutzman@nps.edu<o:p></o:p></p><p class=MsoPlainText>Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<o:p></o:p></p><p class=MsoPlainText>X3D graphics, virtual worlds, Navy robotics https:// faculty.nps.edu/brutzman<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>-----Original Message-----<br>From: Andreas Plesch <andreasplesch@gmail.com> <br>Sent: Friday, April 29, 2022 12:46 PM<br>To: John Carlson <yottzumm@gmail.com><br>Cc: Brutzman, Donald (Don) (CIV) <brutzman@nps.edu>; X3D Graphics public mailing list <x3d-public@web3d.org><br>Subject: Re: [x3d-public] ProtoBody completeness in nested Protos</p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>On Fri, Apr 29, 2022 at 2:14 PM John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:<o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>> What I’m trying to get at is, as the browser is processing the files (serially), in one case, either A or B is instanced before it’s definition.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Let's see hour serial processing would work:<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>1) Load ExternProto Declaration for B (but do not do anything with it since not instanced yet)<o:p></o:p></p><p class=MsoPlainText>2) Define Proto Declaration for A<o:p></o:p></p><p class=MsoPlainText>3) Try to Instance A<o:p></o:p></p><p class=MsoPlainText>4) Expand A with ProtoBody for A (ok since it is defined)<o:p></o:p></p><p class=MsoPlainText>5) ProtoBody for A tries to Instance B<o:p></o:p></p><p class=MsoPlainText>6) Expand B with ProtoBody for B (ok since definition is loaded in step 1, eg. before instantiation)<o:p></o:p></p><p class=MsoPlainText>7) Try to instance A<o:p></o:p></p><p class=MsoPlainText>8) Expand A with ProtoBody for A (ok since A is defined in file B which is loaded) and so on.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>So I think instantiation never occurs before definition, even in serial processing. Probably I overlooked something ?<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>> I think your extra clause should be added for parallel loading. In particular, I don’t think that extern PROTOs should be allowed to reference each other in a circular way (ignoring regular PROTO definitions and instances to be clear). I thought we were talking about PROTO instances, not extern PROTOs. Hopefully everyone will agree to add Andreas’ clarification.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>It would probably be helpful to make circular definitions explicitly illegal. They may crop up more commonly by accident than single file recursive Protos which are explicitly illegal. But a browser implementer could already point at the spec. and argue that circular definitions are a covered case of recursion (and treat accordingly).<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>> Thanks!<o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>> John<o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>> On Fri, Apr 29, 2022 at 9:52 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com"><span style='color:windowtext;text-decoration:none'>andreasplesch@gmail.com</span></a>> wrote:<o:p></o:p></p><p class=MsoPlainText>>><o:p> </o:p></p><p class=MsoPlainText>>> Hi John,<o:p></o:p></p><p class=MsoPlainText>>><o:p> </o:p></p><p class=MsoPlainText>>> Here is a draft of an example of a circular definition:<o:p></o:p></p><p class=MsoPlainText>>><o:p> </o:p></p><p class=MsoPlainText>>> file A.x3d:<o:p></o:p></p><p class=MsoPlainText>>><o:p> </o:p></p><p class=MsoPlainText>>> ExternProtoDeclare name='B' url=' "B.x3d" '<o:p></o:p></p><p class=MsoPlainText>>> ProtoDeclare name='A'<o:p></o:p></p><p class=MsoPlainText>>> ProtoBody<o:p></o:p></p><p class=MsoPlainText>>> ProtoInstance name='B'<o:p></o:p></p><p class=MsoPlainText>>> Shape DEF='sphere'<o:p></o:p></p><p class=MsoPlainText>>> /ProtoBody<o:p></o:p></p><p class=MsoPlainText>>> /ProtoDeclare<o:p></o:p></p><p class=MsoPlainText>>> ProtoInstance name='A'<o:p></o:p></p><p class=MsoPlainText>>><o:p> </o:p></p><p class=MsoPlainText>>> file B.x3d:<o:p></o:p></p><p class=MsoPlainText>>><o:p> </o:p></p><p class=MsoPlainText>>> ExternProtoDeclare name='A' url=' "A.x3d" '<o:p></o:p></p><p class=MsoPlainText>>> ProtoDeclare name='B'<o:p></o:p></p><p class=MsoPlainText>>> ProtoBody<o:p></o:p></p><p class=MsoPlainText>>> ProtoInstance name='A'<o:p></o:p></p><p class=MsoPlainText>>> Shape DEF='box'<o:p></o:p></p><p class=MsoPlainText>>> /ProtoBody<o:p></o:p></p><p class=MsoPlainText>>> /ProtoDeclare<o:p></o:p></p><p class=MsoPlainText>>><o:p> </o:p></p><p class=MsoPlainText>>> ProtoInterfaces are omitted (and not used here).<o:p></o:p></p><p class=MsoPlainText>>><o:p> </o:p></p><p class=MsoPlainText>>> Note that Proto A does not use an instance (directly) of itself, and <o:p></o:p></p><p class=MsoPlainText>>> Proto B also does not use an instance of itself.<o:p></o:p></p><p class=MsoPlainText>>><o:p> </o:p></p><p class=MsoPlainText>>> Browser tries to display A.x3d .<o:p></o:p></p><p class=MsoPlainText>>><o:p> </o:p></p><p class=MsoPlainText>>> This case is not realistic since it cannot be resolved. But, like <o:p></o:p></p><p class=MsoPlainText>>> recursive cases, there are situations which could render in theory, <o:p></o:p></p><p class=MsoPlainText>>> if the circle is eventually broken for certain conditions. Since such <o:p></o:p></p><p class=MsoPlainText>>> a circular definition is also recursive, albeit indirectly, the <o:p></o:p></p><p class=MsoPlainText>>> existing recursive clause in the spec. may cover this as well. Such <o:p></o:p></p><p class=MsoPlainText>>> circular definitions leading to infinite loops would be hard to <o:p></o:p></p><p class=MsoPlainText>>> detect for a browser (perhaps by monitoring for stack overflows or by time outs).<o:p></o:p></p><p class=MsoPlainText>>><o:p> </o:p></p><p class=MsoPlainText>>> Andreas<o:p></o:p></p><p class=MsoPlainText>>><o:p> </o:p></p><p class=MsoPlainText>>> On Fri, Apr 29, 2022 at 12:00 AM John Carlson <<a href="mailto:yottzumm@gmail.com"><span style='color:windowtext;text-decoration:none'>yottzumm@gmail.com</span></a>> wrote:<o:p></o:p></p><p class=MsoPlainText>>> ><o:p></o:p></p><p class=MsoPlainText>>> > One can’t instantiate until after definition. I’m fairly sure that covers this case? Maybe we can work with an example?<o:p></o:p></p><p class=MsoPlainText>>> ><o:p></o:p></p><p class=MsoPlainText>>> > Thanks,<o:p></o:p></p><p class=MsoPlainText>>> ><o:p></o:p></p><p class=MsoPlainText>>> > John<o:p></o:p></p><p class=MsoPlainText>>> ><o:p></o:p></p><p class=MsoPlainText>>> > On Thu, Apr 28, 2022 at 9:23 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com"><span style='color:windowtext;text-decoration:none'>andreasplesch@gmail.com</span></a>> wrote:<o:p></o:p></p><p class=MsoPlainText>>> >><o:p></o:p></p><p class=MsoPlainText>>> >> Thanks much for the review and revision effort.<o:p></o:p></p><p class=MsoPlainText>>> >><o:p></o:p></p><p class=MsoPlainText>>> >> 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.<o:p></o:p></p><p class=MsoPlainText>>> >><o:p></o:p></p><p class=MsoPlainText>>> >> The recursive clause in a way covers this in my view but perhaps circular definitions could be made explicitly illegal.<o:p></o:p></p><p class=MsoPlainText>>> >><o:p></o:p></p><p class=MsoPlainText>>> >> Just a thought,<o:p></o:p></p><p class=MsoPlainText>>> >><o:p></o:p></p><p class=MsoPlainText>>> >> Andreas<o:p></o:p></p><p class=MsoPlainText>>> >><o:p></o:p></p><p class=MsoPlainText>>> >> ---on the phone---<o:p></o:p></p><p class=MsoPlainText>>> >><o:p></o:p></p><p class=MsoPlainText>>> >> On Thu, Apr 28, 2022, 8:45 PM Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu"><span style='color:windowtext;text-decoration:none'>brutzman@nps.edu</span></a>> wrote:<o:p></o:p></p><p class=MsoPlainText>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>> We reviewed closely. Prose definitions are correct. Slight editorial changes (essentially re-ordering sentences) hopefully make things clearer.<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>>> >>> Mantis 1395: improve clarity of prototype scoping rules<o:p></o:p></p><p class=MsoPlainText>>> >>> <a href="https://www.web3d.org/member-only/mantis/view.php?id=1395"><span style='color:windowtext;text-decoration:none'>https://www.web3d.org/member-only/mantis/view.php?id=1395</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>>> >>> 4.4.4.4 Prototype scoping rules<o:p></o:p></p><p class=MsoPlainText>>> >>> <a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-"><span style='color:windowtext;text-decoration:none'>https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-</span></a><o:p></o:p></p><p class=MsoPlainText>>> >>> CD1/Part01/concepts.html#Prototypescopingrules<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>>> >>> A prototype may be instantiated in a file anywhere after the completion of the prototype definition. Prototype definitions appearing inside a prototype definition (i.e., nested) have scope local to the enclosing prototype. IS statements inside a nested prototype's implementation may refer to the prototype declarations of the innermost prototype. A prototype may not be instantiated inside its own implementation (i.e., recursive prototypes are illegal).<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>>> >>> 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.<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>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>> Again thanks for all efforts to make the X3D4 specification clear and consistently repeatable.<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>>> >>> all the best, Don<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>>> >>> Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu"><span style='color:windowtext;text-decoration:none'>brutzman@nps.edu</span></a><o:p></o:p></p><p class=MsoPlainText>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<o:p></o:p></p><p class=MsoPlainText>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>> X3D graphics, virtual worlds, Navy robotics https:// <o:p></o:p></p><p class=MsoPlainText>>> >>> faculty.nps.edu/brutzman<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>>> >>> From: Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu"><span style='color:windowtext;text-decoration:none'>brutzman@nps.edu</span></a>><o:p></o:p></p><p class=MsoPlainText>>> >>> Sent: Wednesday, April 27, 2022 9:23 PM<o:p></o:p></p><p class=MsoPlainText>>> >>> To: GPU Group <<a href="mailto:gpugroup@gmail.com"><span style='color:windowtext;text-decoration:none'>gpugroup@gmail.com</span></a>>; Andreas Plesch <o:p></o:p></p><p class=MsoPlainText>>> >>> <<a href="mailto:andreasplesch@gmail.com"><span style='color:windowtext;text-decoration:none'>andreasplesch@gmail.com</span></a>>; Richard F. Puk (<a href="mailto:puk@igraphics.com"><span style='color:windowtext;text-decoration:none'>puk@igraphics.com</span></a>) <o:p></o:p></p><p class=MsoPlainText>>> >>> <<a href="mailto:puk@igraphics.com"><span style='color:windowtext;text-decoration:none'>puk@igraphics.com</span></a>><o:p></o:p></p><p class=MsoPlainText>>> >>> Cc: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org"><span style='color:windowtext;text-decoration:none'>x3d-public@web3d.org</span></a>>; <o:p></o:p></p><p class=MsoPlainText>>> >>> Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu"><span style='color:windowtext;text-decoration:none'>brutzman@nps.edu</span></a>><o:p></o:p></p><p class=MsoPlainText>>> >>> Subject: RE: [x3d-public] ProtoBody completeness in nested Protos<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>>> >>> Thanks for your precision and thoroughness Doug.<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>>> >>> Seems clear and unambiguous that it is scoped, as previously described. We’ll double check on phraseology.<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>>> >>> Dick can we please discuss in tomorrow’s meeting, TIA.<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>>> >>> all the best, Don<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>>> >>> Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu"><span style='color:windowtext;text-decoration:none'>brutzman@nps.edu</span></a><o:p></o:p></p><p class=MsoPlainText>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<o:p></o:p></p><p class=MsoPlainText>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>> X3D graphics, virtual worlds, Navy robotics https:// <o:p></o:p></p><p class=MsoPlainText>>> >>> faculty.nps.edu/brutzman<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>>> >>> From: x3d-public <<a href="mailto:x3d-public-bounces@web3d.org"><span style='color:windowtext;text-decoration:none'>x3d-public-bounces@web3d.org</span></a>> On Behalf Of GPU <o:p></o:p></p><p class=MsoPlainText>>> >>> Group<o:p></o:p></p><p class=MsoPlainText>>> >>> Sent: Tuesday, April 26, 2022 9:57 AM<o:p></o:p></p><p class=MsoPlainText>>> >>> To: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org"><span style='color:windowtext;text-decoration:none'>x3d-public@web3d.org</span></a>><o:p></o:p></p><p class=MsoPlainText>>> >>> Subject: Re: [x3d-public] ProtoBody completeness in nested Protos<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>>> >>> <a href="https://www.web3d.org/documents/specifications/19775-1/V4.0/Part0"><span style='color:windowtext;text-decoration:none'>https://www.web3d.org/documents/specifications/19775-1/V4.0/Part0</span></a><o:p></o:p></p><p class=MsoPlainText>>> >>> 1/concepts.html#Prototypescopingrules<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>>> >>> "A prototype may be instantiated in a file anywhere after the completion of the prototype definition."<o:p></o:p></p><p class=MsoPlainText>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>> If the specs meant what you are suggesting --protos are self contained including proto definitions-- then it would have said "context" rather than "file"<o:p></o:p></p><p class=MsoPlainText>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>> "Prototype definitions appearing inside a prototype definition ( i.e., nested) are local to the enclosing prototype. "<o:p></o:p></p><p class=MsoPlainText>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>> - refinement of the above file order rule.<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>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>> On Tue, Apr 26, 2022 at 9:51 AM GPU Group <<a href="mailto:gpugroup@gmail.com"><span style='color:windowtext;text-decoration:none'>gpugroup@gmail.com</span></a>> wrote:<o:p></o:p></p><p class=MsoPlainText>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>> "I really do<o:p></o:p></p><p class=MsoPlainText>>> >>> not think that proto declarations should be required to inherit <o:p></o:p></p><p class=MsoPlainText>>> >>> existing declarations from parent execution contexts"<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>>> >>> 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.<o:p></o:p></p><p class=MsoPlainText>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>> 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.<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>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>> On Tue, Apr 26, 2022 at 9:37 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com"><span style='color:windowtext;text-decoration:none'>andreasplesch@gmail.com</span></a>> wrote:<o:p></o:p></p><p class=MsoPlainText>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>> > Date: Tue, 26 Apr 2022 07:56:47 -0600<o:p></o:p></p><p class=MsoPlainText>>> >>> > From: GPU Group <<a href="mailto:gpugroup@gmail.com"><span style='color:windowtext;text-decoration:none'>gpugroup@gmail.com</span></a>><o:p></o:p></p><p class=MsoPlainText>>> >>> > To: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org"><span style='color:windowtext;text-decoration:none'>x3d-public@web3d.org</span></a>><o:p></o:p></p><p class=MsoPlainText>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>> > When I started with freewrl around 2009, it had a text-based <o:p></o:p></p><p class=MsoPlainText>>> >>> > system for<o:p></o:p></p><p class=MsoPlainText>>> >>> > protos:<o:p></o:p></p><p class=MsoPlainText>>> >>> > - when parsing a scene, if it found a proto declare, it would <o:p></o:p></p><p class=MsoPlainText>>> >>> > scrape the text into a buffer. Then as it continued parsing, <o:p></o:p></p><p class=MsoPlainText>>> >>> > when it hit a proto instance it pasted, and continued parsing <o:p></o:p></p><p class=MsoPlainText>>> >>> > over the pasted text as though it had been there all along. <o:p></o:p></p><p class=MsoPlainText>>> >>> > Extern protos similar, it would pause parsing, go to the file <o:p></o:p></p><p class=MsoPlainText>>> >>> > referenced, look for the proto declare by name, and scrape out the text of the ProtoDeclare, for pasting in-scene.<o:p></o:p></p><p class=MsoPlainText>>> >>> > And it worked a bit. But especially extern protos weren't working reliably.<o:p></o:p></p><p class=MsoPlainText>>> >>> > As a casual volunteer I decided to fix the bugs. How hard could <o:p></o:p></p><p class=MsoPlainText>>> >>> > it be? A little debugging and presto, I'd be a hero. As I got <o:p></o:p></p><p class=MsoPlainText>>> >>> > into it and saw more scene failure examples there were several <o:p></o:p></p><p class=MsoPlainText>>> >>> > emotional stages like grieving denial, shock, sadness, <o:p></o:p></p><p class=MsoPlainText>>> >>> > resistance etc. And a slow dawning realization the whole system needed a rework.<o:p></o:p></p><p class=MsoPlainText>>> >>> > And I didn't have support from others -just silence, perhaps <o:p></o:p></p><p class=MsoPlainText>>> >>> > they knew it was a mess and wanted to stay clear.<o:p></o:p></p><p class=MsoPlainText>>> >>> > It was a sickening feeling, and I needed to think for a few <o:p></o:p></p><p class=MsoPlainText>>> >>> > weeks whether I even wanted to be a volunteer programmer if the <o:p></o:p></p><p class=MsoPlainText>>> >>> > system was rotten from the core.<o:p></o:p></p><p class=MsoPlainText>>> >>> > So it can not only be a monster task, but precisely because <o:p></o:p></p><p class=MsoPlainText>>> >>> > it's a monster there's little support for those brave enough to tackle it.<o:p></o:p></p><p class=MsoPlainText>>> >>> > (After a few weeks I got to the Acceptance stage of grieving, <o:p></o:p></p><p class=MsoPlainText>>> >>> > and spent 6 months of hobby time building the new proto system).<o:p></o:p></p><p class=MsoPlainText>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>> Thanks for the story, and for engaging. To me, I became <o:p></o:p></p><p class=MsoPlainText>>> >>> interested when I realized that x3dom is probably flexible enough <o:p></o:p></p><p class=MsoPlainText>>> >>> to allow for parameterized definition and registration of new <o:p></o:p></p><p class=MsoPlainText>>> >>> nodes dynamically which behave then exactly like native nodes. <o:p></o:p></p><p class=MsoPlainText>>> >>> This is different from filling in templates. For example, there <o:p></o:p></p><p class=MsoPlainText>>> >>> is no performance penalty during tree traversal and it enables <o:p></o:p></p><p class=MsoPlainText>>> >>> instancing using xml nodes with the new names, just as in x3dv.<o:p></o:p></p><p class=MsoPlainText>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>> I am pretty happy with how it came out. An additional <o:p></o:p></p><p class=MsoPlainText>>> >>> complication is asynchronous loading of remote resources which is standard on the web.<o:p></o:p></p><p class=MsoPlainText>>> >>> X3D should rely less on how nodes or statements are ordered in a <o:p></o:p></p><p class=MsoPlainText>>> >>> scene.<o:p></o:p></p><p class=MsoPlainText>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>> It is just frustrating that there are ill defined corners. I <o:p></o:p></p><p class=MsoPlainText>>> >>> really do not think that proto declarations should be required to <o:p></o:p></p><p class=MsoPlainText>>> >>> inherit existing declarations from parent execution contexts ( <o:p></o:p></p><p class=MsoPlainText>>> >>> DEF/USE name scopes are different but there is still a separated <o:p></o:p></p><p class=MsoPlainText>>> >>> execution context ). That means the protos array of a new <o:p></o:p></p><p class=MsoPlainText>>> >>> execution context should be empty initially. The SAI spec. actually says so.<o:p></o:p></p><p class=MsoPlainText>>> >>><o:p></o:p></p><p class=MsoPlainText>>> >>> Best, Andreas<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-public mailing list<o:p></o:p></p><p class=MsoPlainText>>> >>> <a href="mailto:x3d-public@web3d.org"><span style='color:windowtext;text-decoration:none'>x3d-public@web3d.org</span></a><o:p></o:p></p><p class=MsoPlainText>>> >>> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org"><span style='color:windowtext;text-decoration:none'>http://web3d.org/mailman/listinfo/x3d-public_web3d.org</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>>> >> x3d-public mailing list<o:p></o:p></p><p class=MsoPlainText>>> >> <a href="mailto:x3d-public@web3d.org"><span style='color:windowtext;text-decoration:none'>x3d-public@web3d.org</span></a><o:p></o:p></p><p class=MsoPlainText>>> >> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org"><span style='color:windowtext;text-decoration:none'>http://web3d.org/mailman/listinfo/x3d-public_web3d.org</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>>> --<o:p></o:p></p><p class=MsoPlainText>>> Andreas Plesch<o:p></o:p></p><p class=MsoPlainText>>> Waltham, MA 02453<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>--<o:p></o:p></p><p class=MsoPlainText>Andreas Plesch<o:p></o:p></p><p class=MsoPlainText>Waltham, MA 02453<o:p></o:p></p></div></body></html>