<div dir="auto">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.  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.</div><div dir="auto"><br></div><div dir="auto">Thanks!</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, Apr 29, 2022 at 9:52 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@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)">Hi John,<br>
<br>
Here is a draft of an example of a circular definition:<br>
<br>
file A.x3d:<br>
<br>
ExternProtoDeclare name='B' url=' "B.x3d" '<br>
ProtoDeclare name='A'<br>
 ProtoBody<br>
  ProtoInstance name='B'<br>
  Shape DEF='sphere'<br>
 /ProtoBody<br>
/ProtoDeclare<br>
ProtoInstance name='A'<br>
<br>
file B.x3d:<br>
<br>
ExternProtoDeclare name='A' url=' "A.x3d" '<br>
ProtoDeclare name='B'<br>
 ProtoBody<br>
  ProtoInstance name='A'<br>
  Shape DEF='box'<br>
 /ProtoBody<br>
/ProtoDeclare<br>
<br>
ProtoInterfaces are omitted (and not used here).<br>
<br>
Note that Proto A does not use an instance (directly) of itself, and<br>
Proto B also does not use an instance of itself.<br>
<br>
Browser tries to display A.x3d .<br>
<br>
This case is not realistic since it cannot be resolved. But, like<br>
recursive cases, there are situations which could render in theory, if<br>
the circle is eventually broken for certain conditions. Since such a<br>
circular definition is also recursive, albeit indirectly, the existing<br>
recursive clause in the spec. may cover this as well. Such circular<br>
definitions leading to infinite loops would be hard to detect for a<br>
browser (perhaps by monitoring for stack overflows or by time outs).<br>
<br>
Andreas<br>
<br>
On Fri, Apr 29, 2022 at 12:00 AM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
><br>
> One can’t instantiate until after definition.  I’m fairly sure that covers this case?  Maybe we can work with an example?<br>
><br>
> Thanks,<br>
><br>
> John<br>
><br>
> On Thu, Apr 28, 2022 at 9:23 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>><br>
>> Thanks much for the review and revision effort.<br>
>><br>
>> 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.<br>
>><br>
>> The recursive clause in a way covers this in my view but perhaps circular definitions could be made explicitly illegal.<br>
>><br>
>> Just a thought,<br>
>><br>
>> Andreas<br>
>><br>
>> ---on the phone---<br>
>><br>
>> On Thu, Apr 28, 2022, 8:45 PM Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br>
>>><br>
>>> We reviewed closely.  Prose definitions are correct.  Slight editorial changes (essentially re-ordering sentences) hopefully make things clearer.<br>
>>><br>
>>><br>
>>><br>
>>> Mantis 1395: improve clarity of prototype scoping rules<br>
>>> <a href="https://www.web3d.org/member-only/mantis/view.php?id=1395" rel="noreferrer" target="_blank">https://www.web3d.org/member-only/mantis/view.php?id=1395</a><br>
>>><br>
>>> -<br>
>>><br>
>>> 4.4.4.4 Prototype scoping rules<br>
>>> <a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/concepts.html#Prototypescopingrules" rel="noreferrer" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/concepts.html#Prototypescopingrules</a><br>
>>><br>
>>> -<br>
>>><br>
>>> 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).<br>
>>><br>
>>><br>
>>><br>
>>> 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.<br>
>>><br>
>>> -<br>
>>><br>
>>><br>
>>><br>
>>> Again thanks for all efforts to make the X3D4 specification clear and consistently repeatable.<br>
>>><br>
>>><br>
>>><br>
>>> all the best, Don<br>
>>><br>
>>> --<br>
>>><br>
>>> Don Brutzman  Naval Postgraduate School, Code USW/Br        <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
>>><br>
>>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA    +1.831.656.2149<br>
>>><br>
>>> X3D graphics, virtual worlds, Navy robotics https:// <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">faculty.nps.edu/brutzman</a><br>
>>><br>
>>><br>
>>><br>
>>> From: Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>><br>
>>> Sent: Wednesday, April 27, 2022 9:23 PM<br>
>>> To: GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>>; Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>>; Richard F. Puk (<a href="mailto:puk@igraphics.com" target="_blank">puk@igraphics.com</a>) <<a href="mailto:puk@igraphics.com" target="_blank">puk@igraphics.com</a>><br>
>>> Cc: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>>; Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>><br>
>>> Subject: RE: [x3d-public] ProtoBody completeness in nested Protos<br>
>>><br>
>>><br>
>>><br>
>>> Thanks for your precision and thoroughness Doug.<br>
>>><br>
>>><br>
>>><br>
>>> Seems clear and unambiguous that it is scoped, as previously described.  We’ll double check on phraseology.<br>
>>><br>
>>><br>
>>><br>
>>> Dick can we please discuss in tomorrow’s meeting, TIA.<br>
>>><br>
>>><br>
>>><br>
>>> all the best, Don<br>
>>><br>
>>> --<br>
>>><br>
>>> Don Brutzman  Naval Postgraduate School, Code USW/Br        <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
>>><br>
>>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA    +1.831.656.2149<br>
>>><br>
>>> X3D graphics, virtual worlds, Navy robotics https:// <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">faculty.nps.edu/brutzman</a><br>
>>><br>
>>><br>
>>><br>
>>> From: x3d-public <<a href="mailto:x3d-public-bounces@web3d.org" target="_blank">x3d-public-bounces@web3d.org</a>> On Behalf Of GPU Group<br>
>>> Sent: Tuesday, April 26, 2022 9:57 AM<br>
>>> To: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
>>> Subject: Re: [x3d-public] ProtoBody completeness in nested Protos<br>
>>><br>
>>><br>
>>><br>
>>> <a href="https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/concepts.html#Prototypescopingrules" rel="noreferrer" target="_blank">https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/concepts.html#Prototypescopingrules</a><br>
>>><br>
>>><br>
>>><br>
>>> "A prototype may be instantiated in a file anywhere after the completion of the prototype definition."<br>
>>><br>
>>> If the specs meant what you are suggesting --protos are self contained including proto definitions-- then it would have said "context" rather than "file"<br>
>>><br>
>>> "Prototype definitions appearing inside a prototype definition ( i.e., nested) are local to the enclosing prototype. "<br>
>>><br>
>>> - refinement of the above file order rule.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On Tue, Apr 26, 2022 at 9:51 AM GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>> wrote:<br>
>>><br>
>>> "I really do<br>
>>> not think that proto declarations should be required to inherit<br>
>>> existing declarations from parent execution contexts"<br>
>>><br>
>>><br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On Tue, Apr 26, 2022 at 9:37 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>>><br>
>>> > Date: Tue, 26 Apr 2022 07:56:47 -0600<br>
>>> > From: GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>><br>
>>> > To: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">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">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>
>><br>
>> _______________________________________________<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>
<br>
<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
</blockquote></div></div>