[Resending. Seems not to have gotten theough yesterday.]
Mitra,
To check that I'm understanding you, by "model" do you mean individual
geometric models? The terminology is more 3D centric than ActiveVRML is,
but I can extrapolate your comments to the other ActiveVRML types.
Your decomposition below seems reasonable, but (if I understand your
intent) does not match ActiveVRML's design philosophy. The individual
geometric models and their compositions, which correspond to your 1 and 2
and ActiveVRML's "geometry" type, are not separate from the behavior
language. Rather, the "behavior language", which is all of ActiveVRML,
consists of geometry along all of the other types (sound, image,
transform3, point3, vector3, numbers, ...) and their type-specific
operations (e.g., "union"), plus a handful of type-generic operations for
constructing behaviors and events (e.g., "until").
In contrast to ActiveVRML, one might instead pursue a stratified design,
in which models and their compositions may be defined to depend on
behaviors, but are not themselves behaviors. But then I would wonder:
which types should be supported in the levels 1&2 statum and which at the
level 3 stratum? Also, what can serve as inputs/parameters to what?
Would it just be that the 3 stratum can serve as input to the 1&2 stratum?
I mope not, since all types of values are useful as parameters. To me,
it's simpler and more powerful to eliminate these questions by eliminating
the stratification.
In reply to your comment:
| I also find it hard to see us requiring all behaviors to be written using
| the functional model, it is not ideally suited for event driven programming,
| nor for programming in a world of objects, events and Applets.
With ActiveVRML, we're extending the domain of *modeling* to interactive
animation. Whenever you extend modeling, the result is that some things
that used to be "programmed", in the conventional sense of the word, get
to be modeled instead. It used to seem natural to program with
immediate-mode rendering APIs, and "modeling" geometry seemed unnatural at
first. I think the more you play with and internalize ActiveVRML's ideas,
the more natural it will feel to model animation and reactivity rather
than programming it in an imperative language like C, C++, Java, VB, etc.
There will always be a role for (imperative) programming languages, as
complementary to modeling languages. It's just that the boundary shifts
as modeling matures. We have a description of how ActiveVRML and
programming languages work together, but its release was delayed for some
word-smithing and internal coordination. Look for it in future versions
our docs.
- Conal
P.S. There's probably confusion over the system's name. Our management
changed it from "RBML" to "ActiveVRML" at the last minute.
| From: Mitra <[email protected]>
| To: <[email protected]>
| Subject: Re: ANNOUNCE: VRML 2.0 proposal from Microsoft graphics groups
| Date: Thursday, December 07, 1995 10:24AM
|
| In response to Microsoft's ActiveVRML proposal ...
|
| If I look at a system as having three main components,
|
| 1. The model
| 2. The scene composition
| 3. The behavior language
|
| Then it appears that VRML1.0 and current proposals for VRML2.0 cover
| components 1 and 2, with the language (e.g. Java) being component 3. RBML
| covers points 2 and 3.
|
| As *A* language, i.e. something to sit at layer 3 it makes perfect sense,
| some systems are best described in the functional model you propose, and it
| would work very well theough the kinds of API that are in my proposal.
|
| I can't see what we gain by putting RBML at layer 2, it gives a different
| way of describing the same compositing functions with no gain over existing
| VRML, and a substantial paradigm shift compared to what everyone has been
| building so far.
|
| I also find it hard to see us requiring all behaviors to be written using
| the functional model, it is not ideally suited for event driven programming,
| nor for programming in a world of objects, events and Applets.
|
| This obviously needs discussing more, but at the moment I would
| suggest that RBML be proposed for A language that is used to describe
| behaviors in a VRML2.0 environment rather than VRML2.0 itself.
|
| - Mitra