internal-vs-external behaviors

Chris Goad ([email protected])
Mon, 24 Apr 95 09:56 PDT

A top level issue about how behavior is to be addressed in VRML 2.0
is the internal-vs-external question:
whether behavior should come from outside via
binding to external scripts, byte code executables, or binary executables,
or whether behavior should be described by an extension to the format itself.
The mail on this list has been running at least two well-argued posts
to one for the external approach. Here's an argument for an internal representation.
(This is not, however, an argument against having
the ability to import external represenations as well. An internal representaion
can provide a framework for coordinating imported behaviors.)

If we forget for the moment about our background as programmers, then it is
natural to think of behaviors as integral properties of objects.
How a bicycle works or a tree in a breeze behaves is intimately
entwined with the physical attributes of the object in question.
Further, the part-whole hierarchy which structures
much of the world is reflected directly in the behavioral realm.
So, I would think, our initial impulse given a blank slate and the
problem of devising complete representations of objects would be to take
the internal approach - to attempt to put the
behaviors into the representation rather than to start from the premise
that behaviors must be given a different treatment, and then imported.

Even if the external approach is taken, the reality of the intimacy between
behavior and object must be dealt with. In particular, if scripts are bound
to VRML nodes, mechanisms must be available for blending the behaviors
induced by the various active scripts, for providing the right
kind of access to the VRML scene for the scripts, and for managing
communications between the scripts. These problems might collectively
be referred to as the "assembly problem for behavior".
If you have systems A and B, and you wish to assemble them together,
and get the interaction between them right, how do you do it?
In the internal approach, at least some of the burden of assembly
falls on the format itself, whereas these issues are externalized
by the other approach.


So, I'd say, the internal approach has a certain natural appeal. However, this
appeal is combatted by several factors.

(1)A belief that object-embedded
representations of behavior are bound to be specialized or lack expressiveness.

(2) The observation that behavior overflows the realm of the physical.
Concretely, it is just as natural to inject behaviors into
HTML documents as into VRML worlds; it should be possible
have behaviors in a single simulated world reflected simultaneously in
both VRML and in other modalities, including documents and sounds.
The conclusion: behavior is orthogonal to other kinds of content,
and should be represented separately.

(3)The feeling that behavior is already adequately covered by existing programming technology.
If C++ (resp Java, SmallTalk, Dylan ScriptX ... etc etc) was good enough for X, it should be
good enough for VRML.

I've spent the last few years doing my best to refute (1) by building a counter-example.
(BTW, as of today there's a new chunk of technical detail at our site:
see http://www.besoft.com/new/xobs.html)


As for (2), behavior does indeed have just as much relevance to documents as to 3D.
However, this doesn't mean that the behavior representation must be
exiled from both VRML and HTML. I think the preferred solution is to view
VRML and HTML as differing syntax for object models that can be unified, and
then to formulate behavior in the object model so that it can
be rendered in either syntax. (A related suggestion concerning a possible
SGML presentation of VRML was made a few weeks ago on the VRML list).

Finally, in my view,
the idea that behavior is already adequately covered by existing programming technology
is convincing only if attention is restricted to small or simple examples. In fact, simulation
of complex environments remains such a difficult task that the state of the art is effectively
stuck at a rather low level of complexity. A big part of the problem, it seems to me, is
that traditional computing architectures do a bad job of supporting the assembly
of complex systems from parts, and they do a bad job of this because they split behavior
out into a separate realm. The territory on which VRML is advancing is uncharted, and
some new technology might actually be needed!

Chris Goad
BE Software
[email protected]
http://www.besoft.com