[x3d-public] ProtoBody completeness in nested Protos

Fri Apr 29 14:04:33 PDT 2022

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.

I believe that registration of PROTOs was intended to address this.

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.

There are features in X3DJSONLD to avoid running the ProtoExpander.js and
Script.js.

One can see this in the main X3DJSONLD app @

https://coderextreme.net/X3DJSONLD/

John

On Fri, Apr 29, 2022 at 2:46 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> On Fri, Apr 29, 2022 at 2:14 PM John Carlson <yottzumm at gmail.com> wrote:
> >
> > 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.
>
> Let's see hour serial processing would work:
>
> 1) Load ExternProto Declaration for B (but do not do anything with it
> since not instanced yet)
> 2) Define Proto Declaration for A
> 3) Try to Instance A
> 4) Expand A with ProtoBody for A (ok since it is defined)
> 5) ProtoBody for A tries to Instance B
> 6) Expand B with ProtoBody for B (ok since definition is loaded in
> step 1, eg. before instantiation)
> 7) Try to instance A
> 8) Expand A with ProtoBody for A (ok since A is defined in file B
> which is loaded)
> and so on.
>
> So I think instantiation never occurs before definition, even in
> serial processing. Probably I overlooked something ?
>
> >  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.
>
> 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).
>
>
>
> > Thanks!
> >
> > John
> >
> > On Fri, Apr 29, 2022 at 9:52 AM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
> >>
> >> Hi John,
> >>
> >> Here is a draft of an example of a circular definition:
> >>
> >> file A.x3d:
> >>
> >> ExternProtoDeclare name='B' url=' "B.x3d" '
> >> ProtoDeclare name='A'
> >>  ProtoBody
> >>   ProtoInstance name='B'
> >>   Shape DEF='sphere'
> >>  /ProtoBody
> >> /ProtoDeclare
> >> ProtoInstance name='A'
> >>
> >> file B.x3d:
> >>
> >> ExternProtoDeclare name='A' url=' "A.x3d" '
> >> ProtoDeclare name='B'
> >>  ProtoBody
> >>   ProtoInstance name='A'
> >>   Shape DEF='box'
> >>  /ProtoBody
> >> /ProtoDeclare
> >>
> >> ProtoInterfaces are omitted (and not used here).
> >>
> >> Note that Proto A does not use an instance (directly) of itself, and
> >> Proto B also does not use an instance of itself.
> >>
> >> Browser tries to display A.x3d .
> >>
> >> This case is not realistic since it cannot be resolved. But, like
> >> recursive cases, there are situations which could render in theory, if
> >> the circle is eventually broken for certain conditions. Since such a
> >> circular definition is also recursive, albeit indirectly, the existing
> >> recursive clause in the spec. may cover this as well. Such circular
> >> definitions leading to infinite loops would be hard to detect for a
> >> browser (perhaps by monitoring for stack overflows or by time outs).
> >>
> >> Andreas
> >>
> >> On Fri, Apr 29, 2022 at 12:00 AM John Carlson <yottzumm at gmail.com>
> wrote:
> >> >
> >> > One can’t instantiate until after definition.  I’m fairly sure that
> covers this case?  Maybe we can work with an example?
> >> >
> >> > Thanks,
> >> >
> >> > John
> >> >
> >> > On Thu, Apr 28, 2022 at 9:23 PM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> >> >>
> >> >> Thanks much for the review and revision effort.
> >> >>
> >> >> 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.
> >> >>
> >> >> The recursive clause in a way covers this in my view but perhaps
> circular definitions could be made explicitly illegal.
> >> >>
> >> >> Just a thought,
> >> >>
> >> >> Andreas
> >> >>
> >> >> ---on the phone---
> >> >>
> >> >> On Thu, Apr 28, 2022, 8:45 PM Brutzman, Donald (Don) (CIV) <
> brutzman at nps.edu> wrote:
> >> >>>
> >> >>> We reviewed closely.  Prose definitions are correct.  Slight
> editorial changes (essentially re-ordering sentences) hopefully make things
> clearer.
> >> >>>
> >> >>>
> >> >>>
> >> >>> Mantis 1395: improve clarity of prototype scoping rules
> >> >>> https://www.web3d.org/member-only/mantis/view.php?id=1395
> >> >>>
> >> >>> -
> >> >>>
> >> >>> 4.4.4.4 Prototype scoping rules
> >> >>>
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/concepts.html#Prototypescopingrules
> >> >>>
> >> >>> -
> >> >>>
> >> >>> 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).
> >> >>>
> >> >>>
> >> >>>
> >> >>> 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.
> >> >>>
> >> >>> -
> >> >>>
> >> >>>
> >> >>>
> >> >>> Again thanks for all efforts to make the X3D4 specification clear
> and consistently repeatable.
> >> >>>
> >> >>>
> >> >>>
> >> >>> all the best, Don
> >> >>>
> >> >>> --
> >> >>>
> >> >>> Don Brutzman  Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu
> >> >>>
> >> >>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
> +1.831.656.2149
> >> >>>
> >> >>> X3D graphics, virtual worlds, Navy robotics https://
> faculty.nps.edu/brutzman
> >> >>>
> >> >>>
> >> >>>
> >> >>> From: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> >> >>> Sent: Wednesday, April 27, 2022 9:23 PM
> >> >>> To: GPU Group <gpugroup at gmail.com>; Andreas Plesch <
> andreasplesch at gmail.com>; Richard F. Puk (puk at igraphics.com) <
> puk at igraphics.com>
> >> >>> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>;
> Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> >> >>> Subject: RE: [x3d-public] ProtoBody completeness in nested Protos
> >> >>>
> >> >>>
> >> >>>
> >> >>> Thanks for your precision and thoroughness Doug.
> >> >>>
> >> >>>
> >> >>>
> >> >>> Seems clear and unambiguous that it is scoped, as previously
> described.  We’ll double check on phraseology.
> >> >>>
> >> >>>
> >> >>>
> >> >>> Dick can we please discuss in tomorrow’s meeting, TIA.
> >> >>>
> >> >>>
> >> >>>
> >> >>> all the best, Don
> >> >>>
> >> >>> --
> >> >>>
> >> >>> Don Brutzman  Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu
> >> >>>
> >> >>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
> +1.831.656.2149
> >> >>>
> >> >>> X3D graphics, virtual worlds, Navy robotics https://
> faculty.nps.edu/brutzman
> >> >>>
> >> >>>
> >> >>>
> >> >>> From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of GPU
> Group
> >> >>> Sent: Tuesday, April 26, 2022 9:57 AM
> >> >>> To: X3D Graphics public mailing list <x3d-public at web3d.org>
> >> >>> Subject: Re: [x3d-public] ProtoBody completeness in nested Protos
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/concepts.html#Prototypescopingrules
> >> >>>
> >> >>>
> >> >>>
> >> >>> "A prototype may be instantiated in a file anywhere after the
> completion of the prototype definition."
> >> >>>
> >> >>> If the specs meant what you are suggesting --protos are self
> contained including proto definitions-- then it would have said "context"
> rather than "file"
> >> >>>
> >> >>> "Prototype definitions appearing inside a prototype definition (
> i.e., nested) are local to the enclosing prototype. "
> >> >>>
> >> >>> - refinement of the above file order rule.
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Tue, Apr 26, 2022 at 9:51 AM GPU Group <gpugroup at gmail.com>
> wrote:
> >> >>>
> >> >>> "I really do
> >> >>> not think that proto declarations should be required to inherit
> >> >>> existing declarations from parent execution contexts"
> >> >>>
> >> >>>
> >> >>>
> >> >>> 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.
> >> >>>
> >> >>> 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.
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Tue, Apr 26, 2022 at 9:37 AM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> >> >>>
> >> >>> > Date: Tue, 26 Apr 2022 07:56:47 -0600
> >> >>> > From: GPU Group <gpugroup at gmail.com>
> >> >>> > To: X3D Graphics public mailing list <x3d-public at web3d.org>
> >> >>>
> >> >>> > When I started with freewrl around 2009, it had a text-based
> system for
> >> >>> > protos:
> >> >>> > - when parsing a scene, if it found a proto declare, it would
> scrape the
> >> >>> > text into a buffer. Then as it continued parsing, when it hit a
> proto
> >> >>> > instance it pasted, and continued parsing over the pasted text as
> though it
> >> >>> > had been there all along. Extern protos similar, it would pause
> parsing, go
> >> >>> > to the file referenced, look for the proto declare by name, and
> scrape out
> >> >>> > the text of the ProtoDeclare, for pasting in-scene.
> >> >>> > And it worked a bit. But especially extern protos weren't working
> reliably.
> >> >>> > As a casual volunteer I decided to fix the bugs. How hard could
> it be? A
> >> >>> > little debugging and presto, I'd be a hero. As I got into it and
> saw more
> >> >>> > scene failure examples there were several emotional stages like
> grieving
> >> >>> > denial, shock, sadness, resistance etc. And a slow dawning
> realization the
> >> >>> > whole system needed a rework.
> >> >>> > And I didn't have support from others -just silence, perhaps they
> knew it
> >> >>> > was a mess and wanted to stay clear.
> >> >>> > It was a sickening feeling, and I needed to think for a few weeks
> whether I
> >> >>> > even wanted to be a volunteer programmer if the system was rotten
> from the
> >> >>> > core.
> >> >>> > So it can not only be a monster task, but precisely because it's
> a monster
> >> >>> > there's little support for those brave enough to tackle it.
> >> >>> > (After a few weeks I got to the Acceptance stage of grieving, and
> spent 6
> >> >>> > months of hobby time building the new proto system).
> >> >>>
> >> >>> Thanks for the story, and for engaging. To me, I became interested
> >> >>> when I realized that x3dom is probably flexible enough to allow for
> >> >>> parameterized definition and registration of new nodes dynamically
> >> >>> which behave then exactly like native nodes. This is different from
> >> >>> filling in templates. For example, there is no performance penalty
> >> >>> during tree traversal and it enables instancing using xml nodes with
> >> >>> the new names, just as in x3dv.
> >> >>>
> >> >>> I am pretty happy with how it came out. An additional complication
> is
> >> >>> asynchronous loading of remote resources which is standard on the
> web.
> >> >>> X3D should rely less on how nodes or statements are ordered in a
> >> >>> scene.
> >> >>>
> >> >>> It is just frustrating that there are ill defined corners. I really
> do
> >> >>> not think that proto declarations should be required to inherit
> >> >>> existing declarations from parent execution contexts ( DEF/USE name
> >> >>> scopes are different but there is still a separated execution
> context
> >> >>> ). That means the protos array of a new execution context should be
> >> >>> empty initially. The SAI spec. actually says so.
> >> >>>
> >> >>> Best, Andreas
> >> >>>
> >> >>> _______________________________________________
> >> >>> x3d-public mailing list
> >> >>> x3d-public at web3d.org
> >> >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >> >>
> >> >> _______________________________________________
> >> >> x3d-public mailing list
> >> >> x3d-public at web3d.org
> >> >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >>
> >>
> >>
> >> --
> >> Andreas Plesch
> >> Waltham, MA 02453
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220429/7c3b1bb0/attachment-0001.html>