Paul Buchard suggested something similar in a previous thread in this
list:
> 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
filenames.
Agreed, although I think this is a separate issue.
> Launching some other browser shouldn't be excessively difficulty
since
> 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...).