<div dir="auto">I think the gist is, an X3D file is processed serially.   We may need to further clarify things in the standard if more that one file is being processed concurrently.</div><div dir="auto"><br></div><div dir="auto">I believe that registration of PROTOs was intended to address this.</div><div dir="auto"><br></div><div dir="auto">In my code, I have not addressed registration, except that provided by whatever is processing the DOM tree that I produce.   I hope to remove to ProtoExpander.js and Script.js from my code base in the future, relying on features of X3DOM and X_ITE.</div><div dir="auto"><br></div><div dir="auto">There are features in X3DJSONLD to avoid running the ProtoExpander.js and Script.js.  </div><div dir="auto"><br></div><div dir="auto">One can see this in the main X3DJSONLD app @</div><div dir="auto"><br></div><div dir="auto"><a href="https://coderextreme.net/X3DJSONLD/">https://coderextreme.net/X3DJSONLD/</a></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 2:46 PM 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)">On Fri, Apr 29, 2022 at 2:14 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
><br>
> 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.<br>
<br>
Let's see hour serial processing would work:<br>
<br>
1) Load ExternProto Declaration for B (but do not do anything with it<br>
since not instanced yet)<br>
2) Define Proto Declaration for A<br>
3) Try to Instance A<br>
4) Expand A with ProtoBody for A (ok since it is defined)<br>
5) ProtoBody for A tries to Instance B<br>
6) Expand B with ProtoBody for B (ok since definition is loaded in<br>
step 1, eg. before instantiation)<br>
7) Try to instance A<br>
8) Expand A with ProtoBody for A (ok since A is defined in file B<br>
which is loaded)<br>
and so on.<br>
<br>
So I think instantiation never occurs before definition, even in<br>
serial processing. Probably I overlooked something ?<br>
<br>
>  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.<br>
<br>
It would probably be helpful to make circular definitions explicitly<br>
illegal. They may crop up more commonly by accident than single file<br>
recursive Protos which are explicitly illegal. But a browser<br>
implementer could already point at the spec. and argue that circular<br>
definitions are a covered case of recursion (and treat accordingly).<br>
<br>
<br>
<br>
> Thanks!<br>
><br>
> John<br>
><br>
> On Fri, Apr 29, 2022 at 9:52 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>><br>
>> 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>
<br>
<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
</blockquote></div></div>