[x3d-public] scoping for proto names ?

[Don Brutzman]

Looks like this example has prototype Leg defined, scoped and instanced solely within prototype declaration for Table, which has global scope.

Next comes a few instances of Table.

Next comes prototype declaration Leg2 which has global scope.

Next comes prototype declaration Table2 which has global scope, and which can utilize prototype instances of Leg2 because Leg2 was defined previously (and not hidden within nested scope).

Then comes a few instances of Table2.

It would have been illegal for Table2 to try to instance the earlier prototype Leg because of hidden scope.

This is similar but a bit more complex than the specification example, and perhaps should be added to X3D4 spec examples.

* X3D Example Archives: Basic, X3D Specifications, Prototype
   https://www.web3d.org/x3d/content/examples/Basic/X3dSpecifications/PrototypeIndex.html

* X3D XML encoding, Annex C, ExamplesC.4 Prototype example
   https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/examples.html#PrototypeExample

As you know, scoping rules are at

===================================================
* X3D Architecture, 4.4.4.4 Prototype scoping rules
   https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#Prototypescopingrules

"4.4.4.4 Prototype scoping rules
Prototype definitions appearing inside a prototype definition (i.e., nested) are local to the enclosing prototype. IS statements inside a nested prototype's implementation may refer to the prototype declarations of the innermost prototype.

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.

A prototype may be instantiated in a file anywhere after the completion of the prototype definition. A prototype may not be instantiated inside its own implementation (i.e., recursive prototypes are illegal)."
===================================================

As the specification indicates, since each prototype declaration encapsulates its own name and child DEF/USE nodes, it is erroneous to break scoping rules.  X3D Schematron has rules for this which provide helpful diagnostics if violated.

Meanwhile, although it is legal from an X3D perspective, duplicative DEF and prototype names within a single mode will fail validation in XML and likely thwart other tools as well.  Good practice: DRY.

* Don't repeat yourself (DRY)
   https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Similar scoping issues for a player can of course occur with Inline, and ExternProtoDeclare, so a browser has to keep track of name scope throughout each of these mechanisms.  This is especially important since authors may be composing diverse models via Inline and ExternProtoDeclare without any knowledge of each others DEF and prototype names.

So prototype scoping may seem complex, but actually it is quite similar to Inline scoping so common approaches are likely OK to be used similarly.  Authors can also think of them in the same way.  Good luck!

v/r Don


On 6/7/2020 1:40 PM, Andreas Plesch wrote:
> Let's see if I can explain this question clearly.
> 
> First the example:
> 
> https://github.com/andreasplesch/x3dom/blob/gh-pages/test/functional/proto/castle/proto_nested.x3d
> 
> The table2 ProtoBody uses an instance of the leg2 proto. The leg2 proto declaration is defined outside of the table2 proto declaration name scope.
> 
> The expected result is that the table2 proto declaration is able to use the name 'leg2' to find the leg2 proto definition.
> 
> This does not work in my x3dom proto exploration and it took me a while to realize that the reason is (too?) strict scoping. The leg2 proto definition occurs outside of the execution context and name scope of the table2 proto. Therefore it is not visible to the table2 proto.
> 
> At first glance this strictness seems not unreasonable, however, all tested browsers display the scene as expected.
> 
> So I am somewhat puzzled. I think what it means is that name scoping does not apply to the name of Protos given by the name attribute, since the name of Proto is the name of a node definition. Proto names are possibly global.
> 
> One consequence is that two Protos in a scene cannot have the same name. And I recall that this case is spec'ed to lead to undefined behaviour.
> 
> Would it be correct to treat Proto names as global ? To be clear, by Proto name I refer to the name given by the name attribute, not a DEF name of an instance.
> 
> Thanks for any insight, or pointers to relevant spec. sections, -Andreas
> 
> -- 
> Andreas Plesch
> Waltham, MA 02453
> 
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> 

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 http://faculty.nps.edu/brutzman