Re: WWWInline; include non-VRML data?

Gavin Bell (
Mon, 17 Oct 1994 18:00:16 -0700

On Oct 17, 5:13pm, Don Brutzman wrote:
> On 26 SEP I proposed that vrml links have three possibilities:
> - The link adds more .vrml nodes into the current scene
> - The link spawns a separate browser or browsers
> (gopher mosaic lynx www xv vrml et al. as specified by URLs &/or
> - The link replaces all nodes in the current scene

Paul Buchard suggested something similar in a previous thread in this
> Relationship Meaning
> -------------------------------------
> (default) teleport to new scene given by target
> Embed keep old scene, but include target in the
> hierarchy under the link node that retrieved it
> WorldEmbed keep old scene, but include target under the
> root node of the hierarchy
> (The "Embed" relationship is already officially recognized in HTML.)
> Link relationships would be specified using optional "rel" and "rev"
> fields of WWWButton.

So "Embed" is "add more .vrml nodes to the current scene"
And "WorldEmbed" is "replace all nodes".

I replied:

What happens if a WWWButton that Embed's a URL is picked twice?

Adding the same set of children again doesn't seem very useful; maybe
it should become "dead" and ignore picks after the first one?

Should there be some way to un-embed embedded objects?

The semantics of embedding seem pretty fuzzy-- you're performing an
"transient change" to a scene.

Lets say navigate to URL "foo.vrml", and then click on a WWWButton
that embeds "bar.vrml". What appears in my browser's "Current URL"
status? What if I decide I really like the way the scene looks with
this particular embedding and add it to my hotlist; when I go to visit
it later, is "bar.vrml" embedded?

You want a (fairly simple) behavior. I think we should let VRML 2.0
define mechansisms to let you get that behavior. For example, wire a
button to the whichChild field of a Switch node to make some part of
the scene appear (you can make it an arbitrary URL by making the
Switch's child a WWWFile node!) when the button is pressed. The
semantics are very clear-- part of the scene was hidden, and the user's
action caused it to become visible, but it is still the same scene.


As for whether or not a separate browser is invoked-- I think that
should be entirely up to the VRML browser. I don't think we can
guarantee that a VRML browser must support displaying both 3D graphics
and 2D stuff in the same window.

> If some image is to be used as a texture, it makes sense to use the
> Texture2 definition and let it recognize texture images via URL

Agreed, although I think this is a separate issue.

> Launching some other browser shouldn't be excessively difficulty
> there is a lot of client code freely available. Furthermore it is my
> understanding that we are looking at VRML as a superset of HTML
> functionality, e.g. we might be using VRML-compatible HTML-compatible
> (perhaps mosaic-like) viewers to navigate.

Also agreed, but I think the designers of HTML made the right decision
when they didn't specify exactly what happens when you click on (for
example) an external image reference (e.g. Mosaic brings up a separate
viewer, NetScape display it inline; I could imagine that being a
user-preference item...).