Re: Inlining, name scoping, defining

Gavin Bell (
Wed, 12 Oct 1994 13:38:45 -0700

On Oct 11, 6:53pm, Linas Vepstas wrote:
> WWWInline
> -- inline the indicated http address
> There is a name scoping issue here that no one touched on. Suppose
> that the indicated http address is a VRML, and that it has a bunch
> DEF's in it. Are we free to USE these newly defined DEF's in the
> current document? What if the owner of the remote document changed
> and blew away a DEF we were depending on? What if they recently
> added a DEF that overrides a DEF that we were using?
> Is this something that should be protected against, or is this
> a caveat emptor situation?

DEF/USE (as currently implemented in Inventor) is restricted in scope
to a single file. It is impossible to DEF an object in one file and
USE it in another.

If you allow objects to refer to objects in other files, it is possible
for a user to:
--- read in a scene
--- interactively edit it in memory
--- be unable to write the scene back out

For example, imagine that a user reads in this scene:
Separator {
File { name "CoolMaterials.vrml" } # Contains DEF Gold
USE Gold
Cube { }

The user interactively rearranges the scene so that the gold cube comes
before the File { } node. That is no problem for an in-memory scene,
since the USE Gold is really just a pointer to the gold Material. But
Inventor will write out the scene as:

Separator {
DEF Gold Material { .... } # First use of gold material
Cube { }
File { name "CoolMaterials.vrml" } # hmm....

Either "CoolMaterials.vrml" has been rewritten with a USE Gold in it
(very bad), or the user has unknowingly stopped using the version of
Gold in CoolMaterials (bad). There are several variations on this, the
worst being when you construct an in-memory scene graph with two File
nodes that share nodes.

We ran into these same issues with Inventor's File node. Designing
around them gets really really really messy (I'll dig up the Inventor
naming design document and make the PostScript available if you're
interested in the gory details).

I like your extendo-URL syntax better:
> --------------------
> In fact, is WWWInline or WWWFile really needed? Why not just support
> the syntax
> where we assume that skulls.vrml has a DEF one_eyed_skull ... {...}
> in it?

There are a couple of other replies along this thread; I'll save my
comments until I've read them.