[x3d-public] ProtoBody completeness in nested Protos

Thu Apr 28 17:45:20 PDT 2022

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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto:andreasplesch at gmail.com> > wrote:

> Date: Tue, 26 Apr 2022 07:56:47 -0600
> From: GPU Group <gpugroup at gmail.com <mailto:gpugroup at gmail.com> >
> To: X3D Graphics public mailing list <x3d-public at web3d.org
<mailto: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 <mailto:x3d-public at web3d.org> 
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220429/a2c51fc7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5353 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220429/a2c51fc7/attachment-0001.p7s>